#klhztrader. Часть -1. Метрики.

Небольшая заметка на полях о прометеусе. Оставлю тут, чтобы не утратить обретенные знания.

Раньше я многократно пользовался Прометеусом для отображения метрик приложения. Рантайм шарпа по дефолту экспортирует достаточно информативный набор метрик, в т.ч. потребляемая приложением память, в т.ч. с разбивкой по поколениям сборки мусора. Добавлять кастомные метрики, позволяющие мониторить различные аспекты разрабатываемого приложения - более менее стандартная практика. И тут я задался вопросом, а как разделить метрики на группы (смапленные на разные пути: /metrics, /metrics/critical и т.д.), чтобы можно было опрашивать более критичные метрики с большей периодичностью.

Промучавшись некоторое время, я пришёл к следующему решению:
1. Основную группу метрик маппить стандартным способом, дефолтным .MapMetrics() в Program.cs
2. Для своих метрик создать свой CollectorRegistry, дальше методом Metrics.WithCustomRegistry создать экзмепляр фабрики MetricFactory, который заинжектить в приложение.
3. В местах, где требуются нестандартные метрики забирать MetricFactory и с его помощью создавать экземпляры метрик в нужных местах.
4. Отдачу своих метрик в прометеус осуществлять через самописный контроллер, в который инжектится CollectorRegistry. Дальше метрики в качестве text/plain отдаются контроллером.

#prometheus

#klhztrader. Часть 0. Автодеплой проекта.

Запишу инструкцию по настройке основы самого простого автодеплоя с помощью gitea actions. Она основана на документации, но обходит несколько подводных камней на которые я наткнулся в процессе.

Цель: исполнять bash - команды на удаленном сервере по коммиту в репозиторий, раннер крутится как демон, не в контейнере. При этом, для деплоя нам скорее всего потребуется установленный на сервер докер. Работу без докера я не проверял.

1. Качаем бинарник gitea actions runner с сайта на сервер (для совместимости с доступной мне версией gitea я взял раннер двухлетней давности).

wget https://dl.gitea.com/act_runner/0.2.3/act_runner-0.2.3-linux-amd64

2. Переименовываем скачанный файл в act_runner и разрешаем ему исполняться: chmod +x act_runner

3. Добавляем пользователя act_runner, я выдал ему sudo привилегии.

4. Запускаем ./act_runner register и идём по шагам, вставляя по запросу url gitea, registration token из настроек gitea (settings => actions => runners => Create new Runner), как-то называем раннер, затем нас спрашивают добавить labels для активации. Добавляем my_project_deploy_cmd:host
Это указывает runner-у выполнять джобы, помеченные как my_project_deploy_cmd непосредственно на сервере, а не внутри контейнера.

5. Убеждаемся в интерфейсе gitea - появился ли там созданный раннер.

6. Настраиваем запуск раннера в качестве демона как указано в документации. Ниже приведу мой вариант .service файла, в котором убрано использование конфига и перебиты пути на домашнюю директорию моего пользователя:

[Unit]
Description=Gitea Actions runner
Documentation=https://gitea.com/gitea/act_runner
After=docker.service

[Service]
ExecStart=/home/my_user/act_runner daemon
ExecReload=/bin/kill -s HUP $MAINPID
WorkingDirectory=/home/my_user
TimeoutSec=0
RestartSec=10
Restart=always
User=act_runner

[Install]
WantedBy=multi-user.target

Дальше как в инструкции:

sudo systemctl daemon-reload

```shell
sudo systemctl enable act_runner --now

7. Включаем enable actions в настройках репозитория.
8. Добавляем в корень репозитория папку .gitea, в неё - папку workflows, в нее - файл test.yaml со следующим содержимым:

name: test
on:
- push

jobs:
test:
runs-on: my_project_deploy_cmd
name: test action
steps:
- name: test
run: echo "Hello from Gitea Action11s!" && docker ps -a`

Важно, чтобы в runs-on был указан label, который мы задали в конце шага 4. Будет выполнен вывод текста в командную строку, а затем - запрос вывода статусов всех докер-контейнеров на сервере.

9. Имея в распоряжении командную строку, мы можем проделать любые манипуляции с сервером и завести деплой в том виде, в котором нам удобно.

#gitea
#devops

#klhztrader, Часть 1. Анонс.

Последние два месяца я все свободное от работы время занимался новым проектом: ботом для торговли на Мосбирже. Предыдущие два поста про метрики и gitea были написаны на этапе подготовки к деплою mvp бота. Все дальнейшие посты, касающиеся торгового бота будут под тегом #klhztrader.

Как родился проект. Я давно хотел познакомиться с темой инвестиций, торговли на бирже и т.д., но не хватало когнитивных ресурсов. И тут за время отпуска я внезапно отдохнул так, что снова захотелось думать. В доступе есть доменный эксперт - друг много лет успешно торгует на Мосбирже. Было принято решение изучить возможности, представляемые биржей.

Немного поторговав руками я понял, что слишком азартен, надо много работать над собой. Зато при просмотре графиков котировок у меня возникают флешбеки из универа и с первой работы в IT: там мне довольно много приходилось иметь дело с временными рядами.

Обычно такие вещи пишут на питоне, но я в гробу его видал, а под c# нашлось отличное api от T-Bank-а, поставляемое в качестве пакета, подключаемого в проект. Указываешь токен доступа - и можно торговать.

Дальше будет длинный конспект процесса разработки и результаты экспериментов. Работы все ещё активно ведутся, не переключайтесь. Код пока не выкладываю, возможно выложу потом.

#klhztrader. Часть 2. Визуализация данных.

При работе с временными рядами требуется периодически визуализировать то, с чем ты работаешь, с нанесенными на график промежуточными результатами. В питоне для этих целей есть прекрасна библиотека matplotlib, с её помощью можно в пару строк сделать график.

В шарпе все несколько сложнее. Изначально я хотел вкрячить какую-то визуализацию прямо в бота по принципу server-side rendering. Я потыкал несколько библиотек для построения графиков. Все они предназначены для серьезной разработки, но ведь моя цель - торговый бот, а не классный визуализатор данных!

Сунулся в React.js, с которым я капельку знаком - за два года там чего-то навертели в гайдах по быстрому старту, старт нифига не быстрый. Vue.js оказался сильно дружелюбнее. Но добрый человек @vekhden_speak посоветовал попробовать для визуализации графану (при попытке сложить данные в прометеус, так, чтобы было удобно, и родился один из прошлых постов). В графане я и остался.

В итоге я пришел к тому, что локально на ноуте кручу данные, укладываю результаты экспериментов в таблицу в постгресе и отсматриваю результаты работы на нескольких дашбордах в графане.

#klhztrader. Часть 3. Инфраструктура.

Бот хостится на виртуалке, 4 х 2.2ГГц, 4Гб оперативки и HDD на 80 Гб, хостер - ruvds. Пока таких ресурсов хватает с головой.

На сервере в докер композе живут шарповый сервис бота, Prometheus, Loki, Graphana, и PostgreSQL. Для мониторинга состояния сервера в качестве обычного демона установлен прометеусовский node_exporter.

Для автодеплоя используется сервер gitea, на которой меня любезно пустил @ssleg. О моих сражениях с настройкой раннера я писал ранее.

Так как проектом занимаюсь я один, было решено в плане мониторинга и обработки логов остановиться на прометеусовском стеке. Я не очень люблю Loki, но для небольшого проекта он оказался идеальным: диск и оперативку потребляет по минимуму, без проблем стыкуется с графаной. Логов у меня не много: 4-5 записей в секунду, во основном меня интересуют ошибки, при том сортировать/фильтровать их не нужно. А тот же ELK съел бы у меня все ресурсы сервера, не дав ничего нового.

В итоге я собрал симпатичный дашборд для мониторинга состояния сервера. На нем четыре графика:
1. Оперативная память. Два графика - доступная память и потребление моего сервиса.
2. Утилизация CPU. По графику на каждое из ядер + отдельно график доли моего сервиса в общем потреблении.
3. Свободное место на диске.
4. Нагрузка на сеть.

Для экстренного управления сделан тетеграм бот. Он позволяет ребутнуть бота (Environment.Exit), бот вырубается, а затем средствами докера автоматически запускается. Ещё можно включить/выключить реальные покупки и продажи, а также докупить или сбросить активы на бирже.