Алерти при збоях парсингу: email та Telegram повідомлення

Алерти при збоях парсингу: навіщо і коли?

Парсер упав вночі — вранці дані застаріли, і ніхто не знає чому. Ми стикалися з цим у 80% проєктів, де моніторинг обмежувався логами. Система алертів вирішує цю проблему: потрібна людина отримує сповіщення про збій парсингу в момент його виникнення — в Telegram або email, з достатнім контекстом для діагностики. Без таких сповіщень інженер витрачає години на пошук причини, а дані для клієнтів залишаються неактуальними.

Автоматичні алерти — це не зручність, а необхідність для будь-якого парсингового пайплайну. Відсутність моніторингу призводить до втрати даних та репутаційних ризиків. Наприклад, зміна структури цільового сайту може залишатися непоміченою кілька днів, поки не накопичиться пустий результат. Наша реалізація під ключ — від проєктування до деплою — дозволяє швидко впровадити алерти для будь-якого парсера на будь-якому стеку та заощадити до 10 годин розглядів на місяць.

Події, що вимагають алерту

Не кожна помилка — збій. Одиничний таймаут штатний — воркер повторить спробу. Система алертів спрацьовує на такі події:

• Завдання вичерпало всі спроби (moved to DLQ або failed finally)
• Воркер впав сам (process crash, OOM)
• Відсоток помилок за останні 15 хвилин перевищив поріг (наприклад, >20%)
• Парсинг сайту не завершився за очікуваний час (watchdog timeout)
• Змінилася структура сторінки — парсер повертає пусті дані

Порівняння каналів сповіщень: Telegram vs email

Ми зазвичай рекомендуємо Telegram для алертів рівня P1 (сайт впав) та email для менш термінових подій. За нашим досвідом, гібридна схема знижує час реакції інженера в 3-4 рази.

Переваги Telegram для критичних збоїв: у 10-30 разів швидше за email

Telegram-сповіщення приходять у 10–30 разів швидше, ніж email через SMTP, і не залежать від спам-фільтрів. У наших проєктах час від збою до отримання алерту через Telegram не перевищує 2 секунд. Для завдань, де кожна секунда простою коштує грошей, Telegram — безальтернативний вибір. Згідно з документацією Telegram Bot API, повідомлення доставляються практично миттєво.

Як налаштувати Telegram-сповіщення за 15 хвилин?

import httpx import textwrap async def send_telegram_alert(bot_token: str, chat_id: str, event: dict): text = textwrap.dedent(f""" 🔴 <b>Збій парсингу</b> <b>Сайт:</b> {event['site_name']} <b>URL:</b> <code>{event['url']}</code> <b>Помилка:</b> {event['error_type']} <b>Повідомлення:</b> <code>{event['error_message'][:300]}</code> <b>Спроб:</b> {event['attempts']} <b>Час:</b> {event['timestamp']} """).strip() async with httpx.AsyncClient() as client: await client.post( f"https://api.telegram.org/bot{bot_token}/sendMessage", json={"chat_id": chat_id, "text": text, "parse_mode": "HTML"}, timeout=10, ) 

Email: налаштування SMTP та SendGrid

from sendgrid import SendGridAPIClient from sendgrid.helpers.mail import Mail def send_email_alert(to_email: str, event: dict): message = Mail( from_email='[email protected]', to_emails=to_email, subject=f"[Парсинг] Збій: {event['site_name']}", html_content=render_alert_template(event), ) sg = SendGridAPIClient(api_key=SENDGRID_API_KEY) sg.send(message) 

Чому дедуплікація скорочує кількість алертів на 95%?

Без дедуплікації при масовому збої (впав проксі-провайдер) прийде 500 листів за хвилину. Рішення — групування за ключем з cooldown. Один алерт на тип помилки за 30 хвилин — розумний баланс між інформативністю та шумом. У нашій практиці це скорочує кількість сповіщень на 95% при збереженні критичної інформації.

def should_send_alert(site_id: int, error_type: str, cooldown_minutes: int = 30) -> bool: key = f"alert_sent:{site_id}:{error_type}" if redis.exists(key): return False redis.setex(key, cooldown_minutes * 60, "1") return True 

Приклад конфігурації з Redis:

import redis import os r = redis.Redis.from_url(os.environ["REDIS_URL"]) COOLDOWN = 30 # хвилин def should_send_alert(site_id, error_type): key = f"alert_sent:{site_id}:{error_type}" if r.exists(key): return False r.setex(key, COOLDOWN * 60, "1") return True 

Як налаштувати Telegram-сповіщення за 15 хвилин?

1. Створіть бота через @BotFather та отримайте токен.
2. Визначте chat_id (можна використати @userinfobot).
3. Впровадьте функцію send_telegram_alert у ваш парсер.
4. Налаштуйте виклик при виникненні збою.
5. Протестуйте відправлення.

Процес впровадження: від аналізу до деплою

• Проєктування схеми алертів (канали, пороги, cooldown).
• Розробка коду сповіщень (Telegram bot / SendGrid / SMTP).
• Впровадження дедуплікації на Redis або in-memory.
• Інтеграція з вашим парсером (вебхук або API).
• Документація та навчання команди.
• Підтримка протягом 2 тижнів після здачі.

Що входить в роботу

• Консультація та проєктування схеми алертів під ваші потреби.
• Розробка та інтеграція коду сповіщень (Telegram, SendGrid, SMTP).
• Налаштування дедуплікації на Redis або іншому сховищі.
• Документація API та інструкції для вашої команди.
• Деплой та тестування в робочому середовищі.
• 2 тижні безкоштовної підтримки після здачі проєкту.

Терміни та вартість

Базове рішення (Telegram + email з дедуплікацією) — від 1 до 2 робочих днів, вартість від $500, що окупається за 2-3 тижні завдяки економії часу інженера. Якщо потрібна інтеграція з існуючою системою моніторингу або кастомні правила — до 5 робочих днів, вартість від $1500. Пишіть нам на безкоштовну оцінку проєкту — ми підберемо оптимальне рішення під ваш бюджет.

Досвід та гарантії

Ми будували системи моніторингу для проєктів з 10 млн запитів на день. Більше 5 років досвіду в парсингу та 50+ успішних впроваджень гарантують, що алерти не пропустять критичний збій. Замовте впровадження системи алертів — і завжди будете в курсі стану парсингу. Економія часу інженера — до 10 годин на місяць, що знижує витрати на підтримку на 30%.