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 стоит денег, и чем меньше мусора вы в него отправляете, тем ниже счёт.
Что проверить на этой неделе
Если вы используете парсеры для мониторинга чатов, лидогенерации или сбора данных:
- Проверьте, работает ли ваша система в режиме Push. Если парсер слушает события через
events.NewMessageили аналоги — он может перестать получать данные при большом количестве чатов или пассивном аккаунте. - Сделайте тест: выкачайте историю за последние 24 часа через
iter_messages. Если в истории есть сообщения, которых не было в Push — проблема в отключении уведомлений. - Проверьте типы данных. Если вы передаёте ID чатов через Excel/Google Таблицы — убедитесь, что они не превращаются в float.
- Добавьте watchdog для сокетов. Silent disconnect может убить парсер без единой ошибки в логах.
- Оцените стоимость LLM-запросов. Если вы отправляете весь трафик в нейросеть — посчитайте, сколько можно сэкономить на локальной фильтрации.
Источники
Дополнительные материалы
Для тех, кто хочет углубиться в тему, вот несколько полезных ресурсов:
- Документация Telethon по работе с сообщениями
- Статья о FloodWaitError и способах его обработки
- Руководство по настройке n8n для вебхуков
- Примеры использования OpenAI API для классификации текста
Заключение
Проблема с пропуском лидов в Telegram-парсерах — это не единичный случай, а типичная архитектурная ловушка, с которой сталкиваются многие разработчики. Переход на Active Pull не только решает проблему с отключением Push-уведомлений, но и даёт более предсказуемое поведение системы в условиях высокой нагрузки.
Главный вывод: не полагайтесь слепо на Push-уведомления в мессенджерах, особенно если ваш аккаунт пассивен или состоит в большом количестве чатов. Всегда предусматривайте fallback-механизм в виде периодического опроса истории сообщений.
Если вы уже столкнулись с подобной проблемой или нашли другое решение — делитесь опытом в комментариях. Возможно, ваш кейс поможет другим разработчикам избежать тех же граблей.
Генерация изображения
- Модель:
flux-schnell - Провайдер:
replicate
Темы журнала
Что почитать дальше
- seotitle: Агентный ИИ вместо чата: что данные OpenAI о Codex значат для ваших процессов | metatitle: Отчёт OpenAI о
- AI-химик OpenAI: как нейросеть ускоряет подбор реакций
- OpenAI Jalapeño AI-чип 2026: характеристики, сравнение с NVIDIA H200 и влияние на рынок
- Европейский ИИ для бизнеса: три альтернативы OpenAI в 2026
- Симуляция развертывания ИИ: метод OpenAI для проверки модели до запуска
