Моніторинг торгового бота: healthcheck, алерти, watchdog у продакшені

Торговий бот, який впав о 3 ночі — це не просто пропущені угоди. Це відкриті позиції без управління, пропущені стоп-лоси та збитки в десятки відсотків капіталу. Уявіть: ваш бот заробляє 2% на день, і раптом сервер вимикається на 2 години. Втрата — 4% від депозиту. Для рахунку в $100k це $4k, які могли б бути врятовані простим healthcheck'ом. Кожна година простою може коштувати дорого — налаштування моніторингу окупається за одну збиткову угоду, яку ви запобігли. Моніторинг uptime — не Grafana заради красивих графіків, а система, яка розбудить вас раніше, ніж ринок зробить це болючіше. Ми налаштовуємо моніторинг за 1-2 дні, і він працює роками без збоїв. На нашому рахунку понад 50 проєктів з автоматизації моніторингу — досвід, який дозволяє передбачити типові помилки.

Що потрібно моніторити

Uptime бота — це не просто «процес запущений». Процес може бути живий, але бот не торгує. Три рівні перевірок:

• Process alive — процес запущений, не завис.
• Application alive — бот обробляє дані та регулярно пише timestamp останньої активності. Якщо timestamp не оновлювався N хвилин — щось не так.
• Trading alive — бот не просто працює, але й торгує: кількість ордерів за період, P&L, відкриті позиції відповідають стратегії.

Як налаштувати healthcheck endpoint?

Найпростіший і надійний підхід — додати HTTP endpoint прямо в бота. Використовуємо FastAPI:

from fastapi import FastAPI import asyncio import time app = FastAPI() last_heartbeat = time.time() bot_state = {"status": "running", "last_trade": None, "open_positions": 0} @app.get("/health") async def health(): age = time.time() - last_heartbeat if age > 60: # не оновлювався більше хвилини return {"status": "stale", "heartbeat_age_seconds": age}, 503 return {"status": "ok", **bot_state} # В основному циклі бота async def bot_loop(): global last_heartbeat while True: last_heartbeat = time.time() await run_strategy() await asyncio.sleep(5) 

Endpoint відповідає статусом 200 при нормі та 503 при простроченні heartbeat. Зовнішній моніторинг ловить 503 і надсилає алерт.

Порівняння інструментів зовнішнього моніторингу

Uptime Kuma розгортається в 300 разів швидше, ніж Prometheus, і потребує в 10 разів менше ресурсів сервера. Для одиночного бота це оптимальний вибір.

Uptime Kuma — self-hosted аналог UptimeRobot. Перевіряє HTTP endpoint кожні N секунд, надсилає сповіщення при недоступності. Розгортається за 5 хвилин на Docker:

docker run -d --restart=always -p 3001:3001 \ -v uptime-kuma:/app/data louislam/uptime-kuma:1 

Для бота: Monitor Type = HTTP, URL = http://your-bot-host:8080/health, interval = 30 seconds, expected status = 200.

Better Uptime / PagerDuty — якщо потрібні SLA-гарантії та escalation політики. Підберемо варіант під ваш бюджет.

Чому потрібен watchdog?

Якщо сам бот не може надіслати алерт (процес мертвий) — потрібен зовнішній watchdog. Найпростіший варіант на bash з кронтабом:

#!/bin/bash # /usr/local/bin/bot-watchdog.sh HEALTH_URL="http://localhost:8080/health" TELEGRAM_TOKEN="..." CHAT_ID="..." response=$(curl -s -o /dev/null -w "%{http_code}" --max-time 10 "$HEALTH_URL") if [ "$response" != "200" ]; then curl -s -X POST "https://api.telegram.org/bot${TELEGRAM_TOKEN}/sendMessage" \ -d "chat_id=${CHAT_ID}" \ -d "text=ALERT: Trading bot health check failed (HTTP ${response})" fi 

Як визначити оптимальний інтервал heartbeat?

Інтервал залежить від волатильності ринку та часу реакції. Для високочастотної торгівлі — 10-30 секунд, для звичайних стратегій — 30-60 секунд. Головне правило: інтервал має бути меншим, ніж час, за який пропуск угоди стане критичним. Враховуйте також затримки мережі та час обробки healthcheck.

Поширені помилки та їх рішення

Одна з частих помилок — надто важкий healthcheck endpoint, який викликає таймаути та хибні тривоги. Рішення: робити endpoint максимально легким, перевіряючи лише наявність heartbeat без глибокої логіки. Інша помилка — надто часті перевірки (кожні 5 секунд), що створюють навантаження та шум. Оптимальний інтервал — 30-60 секунд. Третя — відсутність захисту від crash loop, коли бот нескінченно перезапускається. Використовуйте StartLimitBurst=3 у systemd або Restart policies Docker. Якщо ви не хочете розбиратися з цим самостійно, замовте готове рішення — ми налаштуємо моніторинг за 1 день.

Покрокова інструкція налаштування моніторингу за 1 день

1. Додайте healthcheck endpoint у код бота (приклад вище).
2. Розгорніть Uptime Kuma на сервері (docker run).
3. Налаштуйте моніторинг: URL = http://your-bot:8080/health, interval = 30s.
4. Підключіть Telegram-алерт (BotFather + ваш chat_id).
5. Встановіть watchdog скрипт у cron (кожну хвилину).
6. Налаштуйте systemd з Restart=on-failure та StartLimitBurst=3.
7. Протестуйте: зупиніть бота — через 30 секунд має прийти алерт.

Автоматичний перезапуск через systemd

Якщо бот запущений як systemd service, вкажіть:

[Unit] Description=Trading Bot After=network.target [Service] ExecStart=/usr/bin/python3 /opt/bot/main.py Restart=on-failure RestartSec=10 StartLimitIntervalSec=60 StartLimitBurst=3 [Install] WantedBy=multi-user.target 

Restart=on-failure — автоматичний перезапуск при падінні. StartLimitBurst=3 — не більше 3 перезапусків за 60 секунд (захист від crash loop).

Що входить у налаштування?

Ми пропонуємо комплексне налаштування моніторингу за 1-2 робочі дні:

• додавання healthcheck endpoint у бота (або адаптація існуючого)
• деплой Uptime Kuma / налаштування зовнішнього моніторингу
• налаштування Telegram-алертів
• watchdog скрипт
• автоматичний перезапуск через systemd/Docker
• базові Prometheus метрики, якщо потрібна аналітика за торговою активністю

Якщо у вас немає часу на самостійне налаштування, зв'яжіться з нами — ми оцінимо ваш проєкт і запропонуємо рішення під ключ. Ми займаємося автоматизацією моніторингу понад 5 років — це десятки налаштованих ботів, які працюють без збоїв. Замовте надійний моніторинг сьогодні та отримайте консультацію до початку робіт.