Мониторинг торгового бота: 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 лет — это десятки настроенных ботов, которые работают без сбоев. Закажите надёжный мониторинг сегодня и получите консультацию до начала работ.