Моніторинг парсерів: heartbeat-метрики та алерти для крипто-проектів

Парсер впав о 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% — отримайте детальний розрахунок для вашого проекту, напишіть нам.