Алерти при збоях парсингу: 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%.

Послуги бекенд-розробки: production-grade надійність

На production-сервері о 3:14 ночі черга Laravel Jobs перестала оброблятися — 40 000 необроблених завдань у Redis. Причина: worker упав через memory leak у статичній змінній Eloquent observer, supervisor не перезапустив через misconfigured stopwaitsecs. Ми розбирали такий інцидент на проекті з 500 RPS: діагностика 4 години, фікс — 20 хвилин. Щоб ви не втрачали гроші, пропонуємо послуги бекенд-розробки з акцентом на production-grade надійність — 10+ років досвіду, 50+ проектів, 5 років на ринку. Оцінимо ваш проект за 2 дні.

Які проблеми вирішуємо

N+1 запити: головний вбивця швидкості

N+1 — найпоширеніша причина повільних сторінок у Laravel-додатках. Стандартна історія: сторінка працювала нормально на dev з 10 записами, на production з 10 000 — 8-секундне завантаження.

Laravel Debugbar у dev-оточенні показує кількість запитів. Більше 20 — сигнал для audit.

Model::preventLazyLoading(! app()->isProduction());

Telescope для профілювання: логує всі запити, jobs, mail, notifications з деталізацією. Після впровадження eager loading час завантаження сторінки падає з 8 с до 0.3 с — у 27 разів.

Memory leak у статичних змінних

У Laravel Octane або Swoole додаток тримається в пам’яті між запитами. Статичні змінні не скидаються — призводять до неконтрольованого росту пам’яті. Використовуємо defer-функції та контейнерні біндинги для коректного скидання стану.

Неправильний connection pool

Rails, Laravel, Django відкривають нове з'єднання PostgreSQL на кожен PHP/Python процес. 100 воркерів — 100 з'єднань. PostgreSQL деградує від 200+ активних з'єднань через overhead на управління.

PgBouncer у transaction pooling: 1000 воркерів → 20–50 реальних з'єднань. Це знижує latency на 40% та зменшує витрати на хостинг на 30% — при середній вартості хостингу $2,000/міс економить $600/міс. GIN-індекс для JSONB до 100 разів швидший за B-tree при пошуку.

Як Octane справляється з високим навантаженням?

Laravel Octane (RoadRunner або Swoole) прибирає overhead bootstrap на кожен HTTP-запит. Приріст: 3–8x на синтетичних бенчмарках, 2–4x на реальних додатках. Важливо: не зберігати стан у статичних змінних — застосовуємо це на проектах >1000 RPS.

Як PostgreSQL допомагає уникнути повільних запитів?

Використовуємо composite indexes для WHERE + ORDER BY, partial indexes для фільтрів з високою селективністю, GIN-індекси для JSONB та full-text search. to_tsvector + GIN замість LIKE '%query%' — запобігає seq scan навіть на мільйонах записів. Аналізуємо плани через EXPLAIN ANALYZE та pg_stat_statements.

Як обрати стек для вашого проекту?

Node.js виправданий для realtime: Laravel публікує події в Redis Pub/Sub, Node.js підписується та транслює клієнтам. Go — для goroutines (10k з'єднань на сервер — норма), але розробка повільніша, ніж Laravel.

Чому Redis критичний для продуктивності?

Redis виконує кілька ролей:

Redis Cluster для горизонтального масштабування, Sentinel для автоматичного failover. Замовте консультацію щодо оптимізації Redis для вашого проекту.

Що входить в роботу під ключ

• Архітектурне проектування (документація API, схема БД, діаграма сервісів)
• Реалізація за узгодженим ТЗ з code review
• Налаштування CI/CD (GitHub Actions, Docker), моніторингу (Sentry, Grafana), алертингу
• Навантажувальне тестування (k6, wrk) зі звітом
• Передача вихідних кодів, доступів, інструкція з деплою
• Навчання команди замовника (2–3 сесії)
• Гарантійна підтримка 1 місяць після здачі

Орієнтири по термінах

Вартість розраховується індивідуально після аналізу вимог до навантаження, інтеграцій та бізнес-логіки. Зв'яжіться з нами для безкоштовного аудиту вашого поточного backend — отримайте план оптимізації за 2 дні. Замовте консультацію та дізнайтеся, як знизити витрати на інфраструктуру на 30% без втрати продуктивності.