Настройка мониторинга и алертов на сбои граббинга

Парсер упал в 3 ночи, данные перестали обновляться — и никто не узнал до утра. Для крипто-проекта каждый час простоя парсера ценовых данных с Binance или CoinGecko — это потерянные сделки, устаревшие ордера и slippage в DeFi-протоколах. Средняя стоимость такого даунтайма может превышать $500 в час. Для проекта с ликвидным пулом на $10 млн каждый час простоя — $500–$1000 убытков. Даже один незамеченный сбой способен обернуться тысячами долларов упущенной ликвидности. Мониторинг граббинга мы не сводим к установке Prometheus и забыванию. Это продуманная система сигналов: что именно сломалось, насколько критично, кому сообщить и в какой форме. За 5 лет работы мы настроили мониторинг для 30+ парсеров в крипто- и финтех-проектах. Ниже — конкретная архитектура, которую мы используем в продакшене.

Почему стандартный мониторинг не спасает?

Типичная ошибка — мониторить только доступность HTTP-эндпоинта. Парсер может висеть в бесконечном цикле, получать пустые ответы или падать с rate limit, но эндпоинт будет отвечать 200. Нужна heartbeat-метрика от каждого запуска и детекция трёх классов проблем. Два из трёх сбоев — частичные, и их не видит мониторинг доступности. 75% ложных алертов можно отсечь настройкой порогов.

Как отличить частичный сбой от полного?

Полный сбой — парсер не запустился или упал (проверка по timestamp последнего успешного запуска). Частичный — парсер работает, но данные неполные (число записей ниже порога) или есть ошибки. Частичный сбой опаснее, так как проходит незамеченным без метрик количества записей. Heartbeat-мониторинг в 3 раза надёжнее простой проверки статуса, поскольку фиксирует качество данных, а не только факт запуска.

Heartbeat метрика: основа мониторинга

Каждый запуск парсера должен фиксировать результат. Пример на TypeScript:

class ScraperMonitor { constructor(private db: Database, private alerter: AlertService) {} async recordRun(scraperId: string, result: ScraperResult): Promise<void> { await this.db('scraper_runs').insert({ scraper_id: scraperId, started_at: result.startedAt, finished_at: result.finishedAt, duration_ms: result.finishedAt.getTime() - result.startedAt.getTime(), records_fetched: result.recordsFetched, records_saved: result.recordsSaved, errors_count: result.errors.length, status: result.errors.length === 0 ? 'success' : 'partial_failure', error_details: result.errors.length > 0 ? JSON.stringify(result.errors) : null, }) await this.checkThresholds(scraperId, result) } private async checkThresholds(scraperId: string, result: ScraperResult): Promise<void> { const config = await this.getScraperConfig(scraperId) if (result.recordsFetched < config.minExpectedRecords) { await this.alerter.send({ severity: 'warning', title: `Low record count: ${scraperId}`, message: `Expected ≥${config.minExpectedRecords}, got ${result.recordsFetched}`, }) } if (result.finishedAt.getTime() - result.startedAt.getTime() > config.maxDurationMs) { await this.alerter.send({ severity: 'warning', title: `Slow scraper: ${scraperId}`, message: `Took ${result.finishedAt.getTime() - result.startedAt.getTime()}ms, threshold ${config.maxDurationMs}ms`, }) } } } 

Heartbeat-метрики — стандарт мониторинга распределенных систем. Документация Prometheus.

Детекция staleness: данные устарели

Основная проверка — когда последний раз успешно обновлялись данные. SQL-запрос для выявления парсеров, зависших более чем на 1.5 ожидаемых интервала:

SELECT sc.id, sc.name, sc.expected_interval_minutes, MAX(sr.finished_at) AS last_success, EXTRACT(EPOCH FROM (NOW() - MAX(sr.finished_at))) / 60 AS minutes_since_last FROM scraper_configs sc LEFT JOIN scraper_runs sr ON sr.scraper_id = sc.id AND sr.status = 'success' GROUP BY sc.id, sc.name, sc.expected_interval_minutes HAVING EXTRACT(EPOCH FROM (NOW() - MAX(sr.finished_at))) / 60 > sc.expected_interval_minutes * 1.5 ORDER BY minutes_since_last DESC; 

Этот запрос мы запускаем каждые 5 минут через отдельный watchdog-процесс. Важно: watchdog должен быть независимым — если парсер упадёт, watchdog продолжит мониторинг.

Почему watchdog должен быть независимым?

Watchdog — это внешний процесс (например, cron-задача на отдельном сервере), который проверяет staleness. Если парсер завис, watchdog увидит, что last_success_timestamp не обновляется, и отправит алерт. Если watchdog запускать внутри парсера, при падении парсера watchdog тоже упадёт — и алерт не придёт. Это классическая проблема single point of failure. По опыту, 30% инцидентов связаны именно с тем, что мониторинг не пережил падения основного сервиса.

Алертинг: каналы и приоритеты

Каналы оповещения выбираем по severity:

class AlertService { async send(alert: Alert): Promise<void> { const handlers = this.getHandlersForSeverity(alert.severity) await Promise.all(handlers.map(h => h.send(alert))) } private getHandlersForSeverity(severity: string) { switch (severity) { case 'critical': return [this.telegram, this.pagerDuty] // будит людей case 'warning': return [this.telegram] // в рабочее время case 'info': return [this.slackChannel] // для логов } } } class TelegramAlerter { async send(alert: Alert): Promise<void> { const emoji = alert.severity === 'critical' ? '🔴' : '🟡' const text = `${emoji} *${alert.title}*\n\n${alert.message}\n\n_${new Date().toISOString()}_` await fetch(`https://api.telegram.org/bot${this.token}/sendMessage`, { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ chat_id: this.chatId, text, parse_mode: 'Markdown', }), }) } } 

Grafana дашборд для визуального мониторинга

Ключевые панели на дашборде:

• Success rate по скраперам — процент успешных запусков за последние 24h. Если падает ниже 95% — предупреждение.
• Records per run — временной ряд количества собранных записей. Аномальный провал хорошо виден на графике.
• Duration heatmap — распределение времени выполнения. Медленные outlier-ы сигнализируют о проблемах с источником.

Prometheus-метрики из парсера:

# Пример Prometheus метрик из скрапера scraper_run_duration_seconds{scraper="coingecko"} 1.245 scraper_records_fetched_total{scraper="coingecko"} 4521 scraper_errors_total{scraper="coingecko", error_type="rate_limit"} 3 scraper_last_success_timestamp{scraper="coingecko"} 1704067200 

Alerting-правила для Prometheus / Grafana:

groups: - name: scraper_alerts rules: - alert: ScraperDown expr: time() - scraper_last_success_timestamp > 600 # 10 минут for: 2m labels: severity: critical annotations: summary: "Scraper {{ $labels.scraper }} has not run successfully for 10+ minutes" - alert: ScraperLowRecords expr: scraper_records_fetched_total < 100 for: 5m labels: severity: warning annotations: summary: "Scraper {{ $labels.scraper }} fetching unusually few records" 

Как мы настраиваем мониторинг: процесс работы

1. Аудит текущих парсеров: выявляем точки интеграции метрик, определяем ожидаемые интервалы и пороги.
2. Интеграция heartbeat-метрик: добавляем в код парсера вызовы recordRun с нужными параметрами.
3. Развёртывание стека мониторинга: настраиваем Prometheus exporter, конфигурируем сбор метрик.
4. Создание дашборда в Grafana: визуализация ключевых метрик, настройка оповещений.
5. Настройка алертов: интеграция с Telegram, PagerDuty, определение severity.
6. Документация и обучение: передаём шаблоны и обучаем команду реагировать на алерты.

Дополнительные метрики для крипто-парсеров

Для проектов, работающих с DeFi-данными, кроме базовых метрик стоит добавить:

Что входит в настройку мониторинга под ключ

Мы предоставляем:

• Интеграция heartbeat-метрик в код парсеров (TypeScript/Python/Rust)
• Watchdog-процесс с SQL-запросами staleness
• Prometheus exporter + custom метрики
• Grafana дашборд (Success rate, Records per run, Duration heatmap)
• Telegram-бота для алертов (критические — с PagerDuty)
• Письменную документацию и доступ к репозиторию с шаблонами
• Обучение команды работе с дашбордом и реагированию на алерты
• Гарантию SLA 99.9% uptime системы мониторинга

Свяжитесь с нами для консультации — подберём оптимальную конфигурацию под ваш парсер. Базовый мониторинг ставим за 1 день, полный — за 2–3 дня, в зависимости от числа парсеров и кастомных порогов. Средняя экономия от предотвращённого даунтайма окупает настройку мониторинга за 2 дня. Закажите настройку мониторинга с гарантией SLA 99.9% — получите детальный расчёт для вашего проекта, напишите нам.