Telegram-парсер ослеп на проде: как Active Pull спасает лиды

Андрей Отинов -

Разработчик написал парсер для сбора заявок из тематических чатов. В тестовой группе всё работало мгновенно. На реальных 26 чатах — ноль сообщений за сутки. Аккаунт не забанен, код не падает, но парсер не видит ни одного лида.

Источник: Habr

Проблема оказалась не в коде, а в том, как серверы отключают Push-уведомления для пассивных аккаунтов. Решение — перейти на Active Pull: не ждать уведомлений, а самостоятельно забирать историю сообщений по расписанию.

Если вы используете парсеры для мониторинга чатов, лидогенерации или сбора данных — проверьте, не работает ли ваша система в режиме Push, который может быть отключён без предупреждения.

Что случилось: стандартный слушатель перестал получать события

Автор статьи на Habr собрал двухконтурную систему для поиска клиентов. Стек: Python (Telethon) на сервере → Webhook → n8n → LLM (OpenAI) → Google Таблицы + уведомления.

Логика: скрипт берёт список целевых чатов, стоп-слов и интентов из Google Таблицы, слушает чаты, фильтрует мусор и отправляет потенциальные лиды в n8n, где нейросеть делает финальную квалификацию (Lead / Not Lead).

В тестовой группе парсер ловил сообщения мгновенно. На 26 реальных чатах — полная тишина. Аккаунт состоял в этих группах, но ни одного события NewMessage не прилетало.

Почему Push-подход отказал: архитектурная оптимизация серверов

Причина — не баг, а архитектурное решение. Аккаунт состоял примерно в 3000 чатах (закешировано 2889 диалогов). Серверы отключают Push-события для аккаунтов, которые:

  • Состоят в огромном количестве супергрупп.
  • Являются «пассивными» (не пишут сообщения, не скроллят ленту с официального клиента).
  • Держат чаты в Муте или Архиве.

Telegram экономит ресурсы своих серверов и перестаёт пушить обновления в Telethon. В тестовой группе автор сам писал сообщения — чат был «горячим», пуши шли. В чужих чатах он был пассивным наблюдателем, и сервер перекрыл поток.

Три типичные ошибки первого слоя

Прежде чем автор добрался до архитектурной проблемы, он выгреб пачку локальных граблей. Каждая из них могла убить продакшен сама по себе.

Ошибка Симптом Фикс
Float из Excel n8n отдавал ID чатов в формате -100123456789.0, Telethon ждёт строгий int. Сравнение строк давало False, парсер молча отбрасывал сообщения. Функция clean_id(), отрезающая .0 и приводящая к целому числу.
DDoS самого себя (FloodWait) На каждое входящее событие (до проверки текста) вызывался await event.get_chat(). В высоконагруженных чатах — сотни запросов в минуту. Telegram кидал FloodWaitError или тихо рвал сокет. Тяжёлые API-запросы — строго внутрь блока if has_keyword and has_intent. Сначала локальная фильтрация текста, потом вызов API.
Тихие зависания сокетов Telethon подвержен silent disconnect. Процесс висит в ОС, ошибок в логах нет, но пакеты не идут. Асинхронный connection_watchdog: раз в 60 секунд await client.get_me(). Если ответа нет — жёсткий реконнект.

Решение: Active Pull вместо Push

Автор перевёл архитектуру на Active Pull. Вместо того чтобы ждать уведомления, скрипт по расписанию забирает историю сообщений из целевых чатов через client.iter_messages.

Преимущества: - Не зависит от Push-уведомлений сервера. - Работает для любого количества чатов. - Не требует активности аккаунта в чате.

Недостатки: - Выше нагрузка на API (нужно контролировать частоту запросов). - Выше задержка между появлением сообщения и его обработкой (зависит от интервала опроса). - Нужна локальная фильтрация, чтобы не гонять весь трафик через LLM.

Как локальная фильтрация экономит сотни долларов на токенах

Ключевой элемент системы — двухконтурная фильтрация. Первый контур: локальная проверка по ключевым словам и интентам. Второй контур: LLM-квалификация (Lead / Not Lead).

Локальная фильтрация отсеивает заведомо нерелевантные сообщения до того, как они попадут в OpenAI. Это снижает расход токенов на 80–90% по сравнению с отправкой всего трафика в LLM.

Автор утверждает, что грамотная локальная фильтрация экономит «сотни долларов на токенах OpenAI». Цифра зависит от объёма чатов, но логика верна: каждый запрос к LLM стоит денег, и чем меньше мусора вы в него отправляете, тем ниже счёт.

Что проверить на этой неделе

Если вы используете парсеры для мониторинга чатов, лидогенерации или сбора данных:

  1. Проверьте, работает ли ваша система в режиме Push. Если парсер слушает события через events.NewMessage или аналоги — он может перестать получать данные при большом количестве чатов или пассивном аккаунте.
  2. Сделайте тест: выкачайте историю за последние 24 часа через iter_messages. Если в истории есть сообщения, которых не было в Push — проблема в отключении уведомлений.
  3. Проверьте типы данных. Если вы передаёте ID чатов через Excel/Google Таблицы — убедитесь, что они не превращаются в float.
  4. Добавьте watchdog для сокетов. Silent disconnect может убить парсер без единой ошибки в логах.
  5. Оцените стоимость LLM-запросов. Если вы отправляете весь трафик в нейросеть — посчитайте, сколько можно сэкономить на локальной фильтрации.

Источники

Дополнительные материалы

Для тех, кто хочет углубиться в тему, вот несколько полезных ресурсов:

Заключение

Проблема с пропуском лидов в Telegram-парсерах — это не единичный случай, а типичная архитектурная ловушка, с которой сталкиваются многие разработчики. Переход на Active Pull не только решает проблему с отключением Push-уведомлений, но и даёт более предсказуемое поведение системы в условиях высокой нагрузки.

Главный вывод: не полагайтесь слепо на Push-уведомления в мессенджерах, особенно если ваш аккаунт пассивен или состоит в большом количестве чатов. Всегда предусматривайте fallback-механизм в виде периодического опроса истории сообщений.

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

Генерация изображения

  • Модель: flux-schnell
  • Провайдер: replicate

Темы журнала

Что почитать дальше