lekss361/gendesign

Fork 0

Инвентаризация проблем прода 12.09.2026: потерянный ответ клиенту, доставка алертов, слепые зоны мониторинга #3471

New issue

Open

opened 2026-09-12 10:39:16 +00:00 by lekss361 · 2 comments

lekss361 commented

2026-09-12 10:39:16 +00:00

Owner

Тикет-зонтик: каждый раздел ниже — кандидат в отдельный sub-issue. Здесь он для того, чтобы список был в одном месте и ничего не потерялось.

P0 — сделать руками, до любого кода

Ответ оператора клиенту `kopylov` не доставлен, клиент ждёт 12 дней

31.08.2026 16:34 МСК пользователь kopylov (Копылов, роль manager, активен — последнее событие 11.09) написал в веб-чат: «Здравствуйте! Нужна помощь с отчетом об оценке (ID: 6d9c268e…)». Зеркало ушло в тему группы, сообщение 440.

В 19:29 МСК оператор ответил реплаем на сообщение бота 461, и мост записал:

2026-08-31 16:29:12 WARNING app.services.tgbot.bridge: реплай на сообщение бота
(message_id=461) не найден ни в tg_support_messages, ни в web_support_messages
как зеркало — возможно, осиротевшее зеркало (крах между отправкой и commit'ом)
или шапка-идентификация; ответ оператора НЕ доставлен

В web_support_messages у треда 14 одно входящее и ноль исходящих. Клиент ответа не видел и не увидит: доставка в веб-чат — это строка в БД, а её нет.

Действие: открыть тему клиента в группе поддержки, найти сообщение 461, переслать текст клиенту вручную.

Масштаб потерь проверен отдельно:

Проверка	Результат
Входящие от клиентов в БД	14 из 14 имеют `topic_message_id` — все доставлены в тему
Ошибки 5xx на ручках поддержки за 30 дней	0
«обработка update_id … упала» и сбои БД в мосте	0
«ответ оператора НЕ доставлен» за 30 дней	1 — описанный выше
Отказы Telegram в логе бота	все 520 — входящий `getUpdates` (ConnectTimeout и 502), сообщений не теряют

Сообщения клиентов по дороге в Telegram не терялись. Потеря ровно одна, и она в обратную сторону.

Граница достоверности: логи в Loki живут 30 дней, то есть с 13.08. За более ранний период сужу по БД — там все входящие с идентификаторами тем, все шесть ответов оператора записаны.

Телеграм-чат поддержки

P0. Ответ оператора теряется навсегда при сбое БД

bridge.py: ветка except SQLAlchemyError делает rollback(), после чего безусловно идут save_offset(update_id) и commit(). Для веб-треда доставка клиенту — это и есть запись record_web_out_message. Откат записи плюс сдвинутый offset означают: Telegram апдейт больше не отдаст, ответ не попадёт никуда, оператор уверен, что ответил.

Сегодняшние PR #3456—#3459 чинили клиент, транспорт и ручки API. Эта ветка моста осталась как была.

Чинить: переигрывать веб-ветку с дедупом зеркала, либо на сбой БД уведомлять оператора реплаем в топик — так же, как это уже сделано для 403 и медиа.

P1. At-least-once ретраи дают дубль обращения и осиротевшее зеркало

Клиент ретраит httpx.TransportError, а topic_message_id сохраняется только от той попытки, которая ответила. Если доставились обе, реплай оператора на видимый дубль не маршрутизируется — это ровно тот случай, что выше, в P0 раздела «сделать руками».

Чинить: ключ идемпотентности на отправку, хранить идентификаторы всех попыток, резолвить реплай по любому из них.

P2. Не-реплай оператора и реплай на собственный ответ уходят в пустоту

Маршрутизация держится на reply_to_message_id, а у исходящих topic_message_id пуст. Оператор, написавший в топик без реплая, разговаривает со стеной.

Чинить: сохранять topic_message_id исходящих, на не-реплай отвечать оператору подсказкой. Плюс инструкция операторам.

P2. `TELEGRAM_SUPPORT_TOPIC_ID` не валидируется, нет лимита на группу

_bot_configured() не смотрит на topic_id (дефолт 0). Закрытая или удалённая тема даёт повторяющийся 502 без самолечения. Все лимитеры — per-user и per-IP, потолок Telegram на группу (~20 сообщений в минуту) не защищён ничем.

Маршрутизация алертов

P1. Prometheus не перечитывает правила после деплоя — уже заведено в #3467

Подтверждаю независимо: GET /api/v1/status/runtimeinfo отдаёт lastConfigTime = 2026-08-27T18:12:27Z, совпадающий со startTime. Конфиг не перечитывался 16 суток, при этом Deploy Metrics зелёный.

P1. Нет ни одного алерта уровня приложения

В infra.yml 16 правил, все про хост, контейнеры и Postgres. Доля 5xx и латентность API не покрыты ничем: ошибки продукта видны только постфактум в GlitchTip, порога срабатывания нет, дежурного никто не поднимет.

Чинить: группа правил по rate(http_requests_total{status=~"5.."}) и p95 латентности с severity=critical, host=apps. Маршрут telegram-clients для этого класса уже готов.

P2. Inhibit по `HostAgentDown` глушит critical того же хоста

alertmanager.yml.tmpl: target_matchers: [severity =~ "warning|critical"]. Умер node-exporter — замолчали и cAdvisor-алерты, и PostgresLongTransactionCritical. Сузить до severity=warning.

P2. Алерты GlitchTip идут единственным вебхуком в тот самый бэкенд, за которым следят

Три правила (backend, frontend, Trade-In) шлют в один URL /trade-in/ops/glitchtip-webhook. Упал tradein-backend или Caddy — ошибки приложения задержатся или пропадут. Инфра-алерты это не покрывает: они идут своим путём, Alertmanager → Telegram напрямую с хоста метрик, и это сознательное решение.

Доставка сейчас жива: контрольный POST с реальным секретом вернул 200 за 0.70 с.

P3. Grafana alerting пуст, SMTP не настроен — связано с #3158

Живой API 12.09: ноль правил, контакт-поинт — стоковый <example@email.com>. Правило, заведённое в UI, молча уйдёт в никуда.

GlitchTip

P2. Постоянный error-шум «payments are disabled»

TRADE-IN-3GG, 167 событий с 29.08 по 12.09. Источник — внутренний IP смоука, кнопки оплаты во фронте нет. Выключенный контур засоряет ленту уровнем error.

Чинить: не слать 503 из _require_enabled в Sentry через before_send, либо ignore-правило на группу. Код платежей не трогать.

P2. Отказ пересылки алерта в Telegram отдаёт 502 без сохранения

glitchtip.py:246 — HTTPException(502), GlitchTip не ретраит, алерт исчезает. Случай редкий: TRADE-IN-3F7, ровно одно событие 28.08 за всё время. Ежедневные ConnectTimeout к этому пути отношения не имеют, они из getUpdates.

Чинить: 502 не трогать (он задуман), а ставить алерт в очередь Celery перед ответом.

P3. Исход доставки уведомлений не наблюдаем — уже заведено в #3157

Слепые зоны мониторинга

P1. Данные протухли, и один источник сломан с конца июня

Проверено прямым запросом к прод-БД 12.09:

Источник	Последнее обновление	Возраст
`kn_scrape_runs`, последний успех	28.06.2026	76 дней
`cadastre_jobs`	19.06.2026	85 дней
`nspd_geo_jobs`	04.07.2026	70 дней
`nspd_scrape_runs`	30.04.2026	135 дней

Единственный прогон КН после июня — run 34 от 01.09 — упал: non-JSON response: status=200 ctype=text/html, то есть источник отдал HTML вместо данных (антибот или смена эндпоинта). Ежедневная тревога BACKEND-46O про freshness висит без реакции.

P1. Celery и Redis без метрик

Ни одной серии celery_* или redis_*. Глубина очереди, число воркеров и зависшие таски не измеряются. Переполнение очереди и залипший воркер снаружи не видны.

P2. Access-логи Caddy не попадают в Loki

За три часа в gendesign-caddy-1 ноль строк http.log.access, только ACME, TLS и warn от reverse_proxy. Статусы, латентность и RPS фронтового прокси не наблюдаемы, 5xx приходится искать в логе uvicorn.

P2. cAdvisor скрейпится, но серии `up` нет

alloy-infra.alloy режет всё, кроме container_*, вместе с up и scrape_*. Смерть cAdvisor молча отключит ContainerRestartLoop и ContainerNearMemoryLimit, и никто не узнает.

P2. Тихое зависание `tradein-tgbot` и `tradein-scraper` не детектируется

Это не HTTP-сервисы, в up{} их нет. Крэш и рестарт-луп алертятся, живой процесс с застрявшим циклом — нет. Нужен absent(container_last_seen{...}) или heartbeat из самого цикла.

P3. Панель «Запросы по классам ответов» стекирована

apps.json: stacking.mode=normal, 5xx сверху стека. 11.09 это дало ложную тревогу — верхняя линия читается как объём пятисоток, хотя их было шесть за окно.

Прочее

P1. Периодическое исчерпание пула прокси останавливает прогоны Trade-In

TRADE-IN-3HF (avito, 50 событий с 30.08) и TRADE-IN-38H (cian, 11 событий с 18.08), последние — 12.09. TRADE-IN-3P2: city-sweep встал на первом якоре из пяти. Fallback запрещён сознательно (#2616), так что пустой пул = стоп. Пул из 4 узлов при банах площадок вычерпывается несколько раз в сутки.

P2. `proxy_pool`: половина узлов не проходит healthcheck, и на каждый провал пишется полный traceback

checked=8 ok=4 failed=4, 184 строки httpx.ProxyError 407 за сутки из health-пробы.

P2. Зависший SSH-туннель разработчика засоряет journal инфра-хоста

connect_to 127.0.0.1 port 8000: failed — 2740 строк за сутки, самый частый error-паттерн в Loki. Это чужой шум поверх реальных отказов. Лечится снятием LocalForward 8000 на клиенте.

Замер, объясняющий часть отказов Telegram

Сделан 12.09 около 13:20 МСК, оба хоста опрошены в одни и те же минуты:

Замер	Результат
`getMe` из контейнера `tradein-tgbot` (Selectel), 12 попыток	9 ок, 3 ConnectTimeout
TCP :443 на 149.154.167.220 (адрес с Selectel), 6 попыток	5 ок, 1 таймаут
TCP :443 на 149.154.166.110 (адрес с Beget), 8 попыток	8 ок
`network error` в логе бота за 24 часа	508 строк

Хосты резолвят api.telegram.org в разные адреса, и путь с Selectel теряет примерно каждый четвёртый короткий запрос, а путь с Beget чист. Отсюда и 92 падения итерации poll loop за 30 дней, и разница в самочувствии двух каналов: Alertmanager живёт на Beget, бот поддержки и приёмник вебхуков GlitchTip — на Selectel.

Это фон, на котором любая правка ретраев даёт ограниченный эффект. Отдельный вопрос к решению: выпускать телеграм-трафик Selectel через Beget или через прокси.

Что осталось непроверенным

Реальный масштаб простоя сбора Trade-In на живой БД Selectel.
Фактическая частота сообщений в теме алертов — доходят ли они до человека.
Мониторы Uptime Kuma: конфиг лежит в volume, в git его нет.
Прод-значения переменных окружения на VM.

Отклонено проверкой

Восемь находок не подтвердились и в список не попали: среди них «Poincare отсутствует в Prometheus» (он есть под меткой host=apps), «#3154 секрет течёт в логи» (починено 05.09 в PR #3353), «status.gendsgn.ru не существует» (на него ничто и не ссылается), «137 SQL-ошибок в tradein-postgres» (одна секундная петля внешнего сканера).

Refs #3467, #3159, #3158, #3157, #2616.

Сводный разбор состояния прода на 12.09.2026. Восемь независимых источников (GlitchTip, Prometheus/Loki, конфиги алертинга, код телеграм-моста, открытые тикеты, волт, живые эндпойнты, прод-БД), 45 находок, 37 выжили после проверки скептиками, 8 отклонены как неверные или уже починенные. Тикет-зонтик: каждый раздел ниже — кандидат в отдельный sub-issue. Здесь он для того, чтобы список был в одном месте и ничего не потерялось. --- ## P0 — сделать руками, до любого кода ### Ответ оператора клиенту `kopylov` не доставлен, клиент ждёт 12 дней 31.08.2026 16:34 МСК пользователь `kopylov` (Копылов, роль manager, активен — последнее событие 11.09) написал в веб-чат: «Здравствуйте! Нужна помощь с отчетом об оценке (ID: 6d9c268e…)». Зеркало ушло в тему группы, сообщение 440. В 19:29 МСК оператор ответил реплаем на сообщение бота 461, и мост записал: ``` 2026-08-31 16:29:12 WARNING app.services.tgbot.bridge: реплай на сообщение бота (message_id=461) не найден ни в tg_support_messages, ни в web_support_messages как зеркало — возможно, осиротевшее зеркало (крах между отправкой и commit'ом) или шапка-идентификация; ответ оператора НЕ доставлен ``` В `web_support_messages` у треда 14 одно входящее и ноль исходящих. Клиент ответа не видел и не увидит: доставка в веб-чат — это строка в БД, а её нет. **Действие:** открыть тему клиента в группе поддержки, найти сообщение 461, переслать текст клиенту вручную. **Масштаб потерь проверен отдельно:** | Проверка | Результат | |---|---| | Входящие от клиентов в БД | 14 из 14 имеют `topic_message_id` — все доставлены в тему | | Ошибки 5xx на ручках поддержки за 30 дней | 0 | | «обработка update_id … упала» и сбои БД в мосте | 0 | | «ответ оператора НЕ доставлен» за 30 дней | 1 — описанный выше | | Отказы Telegram в логе бота | все 520 — входящий `getUpdates` (ConnectTimeout и 502), сообщений не теряют | Сообщения клиентов по дороге в Telegram не терялись. Потеря ровно одна, и она в обратную сторону. Граница достоверности: логи в Loki живут 30 дней, то есть с 13.08. За более ранний период сужу по БД — там все входящие с идентификаторами тем, все шесть ответов оператора записаны. --- ## Телеграм-чат поддержки ### P0. Ответ оператора теряется навсегда при сбое БД `bridge.py`: ветка `except SQLAlchemyError` делает `rollback()`, после чего безусловно идут `save_offset(update_id)` и `commit()`. Для веб-треда доставка клиенту — это и есть запись `record_web_out_message`. Откат записи плюс сдвинутый offset означают: Telegram апдейт больше не отдаст, ответ не попадёт никуда, оператор уверен, что ответил. Сегодняшние PR #3456—#3459 чинили клиент, транспорт и ручки API. Эта ветка моста осталась как была. Чинить: переигрывать веб-ветку с дедупом зеркала, либо на сбой БД уведомлять оператора реплаем в топик — так же, как это уже сделано для 403 и медиа. ### P1. At-least-once ретраи дают дубль обращения и осиротевшее зеркало Клиент ретраит `httpx.TransportError`, а `topic_message_id` сохраняется только от той попытки, которая ответила. Если доставились обе, реплай оператора на видимый дубль не маршрутизируется — это ровно тот случай, что выше, в P0 раздела «сделать руками». Чинить: ключ идемпотентности на отправку, хранить идентификаторы всех попыток, резолвить реплай по любому из них. ### P2. Не-реплай оператора и реплай на собственный ответ уходят в пустоту Маршрутизация держится на `reply_to_message_id`, а у исходящих `topic_message_id` пуст. Оператор, написавший в топик без реплая, разговаривает со стеной. Чинить: сохранять `topic_message_id` исходящих, на не-реплай отвечать оператору подсказкой. Плюс инструкция операторам. ### P2. `TELEGRAM_SUPPORT_TOPIC_ID` не валидируется, нет лимита на группу `_bot_configured()` не смотрит на topic_id (дефолт 0). Закрытая или удалённая тема даёт повторяющийся 502 без самолечения. Все лимитеры — per-user и per-IP, потолок Telegram на группу (~20 сообщений в минуту) не защищён ничем. --- ## Маршрутизация алертов ### P1. Prometheus не перечитывает правила после деплоя — **уже заведено в #3467** Подтверждаю независимо: `GET /api/v1/status/runtimeinfo` отдаёт `lastConfigTime = 2026-08-27T18:12:27Z`, совпадающий со `startTime`. Конфиг не перечитывался 16 суток, при этом Deploy Metrics зелёный. ### P1. Нет ни одного алерта уровня приложения В `infra.yml` 16 правил, все про хост, контейнеры и Postgres. Доля 5xx и латентность API не покрыты ничем: ошибки продукта видны только постфактум в GlitchTip, порога срабатывания нет, дежурного никто не поднимет. Чинить: группа правил по `rate(http_requests_total{status=~"5.."})` и p95 латентности с `severity=critical`, `host=apps`. Маршрут `telegram-clients` для этого класса уже готов. ### P2. Inhibit по `HostAgentDown` глушит critical того же хоста `alertmanager.yml.tmpl`: `target_matchers: [severity =~ "warning|critical"]`. Умер node-exporter — замолчали и cAdvisor-алерты, и `PostgresLongTransactionCritical`. Сузить до `severity=warning`. ### P2. Алерты GlitchTip идут единственным вебхуком в тот самый бэкенд, за которым следят Три правила (backend, frontend, Trade-In) шлют в один URL `/trade-in/ops/glitchtip-webhook`. Упал tradein-backend или Caddy — ошибки приложения задержатся или пропадут. Инфра-алерты это не покрывает: они идут своим путём, Alertmanager → Telegram напрямую с хоста метрик, и это сознательное решение. Доставка сейчас жива: контрольный POST с реальным секретом вернул 200 за 0.70 с. ### P3. Grafana alerting пуст, SMTP не настроен — **связано с #3158** Живой API 12.09: ноль правил, контакт-поинт — стоковый `<example@email.com>`. Правило, заведённое в UI, молча уйдёт в никуда. --- ## GlitchTip ### P2. Постоянный error-шум «payments are disabled» `TRADE-IN-3GG`, 167 событий с 29.08 по 12.09. Источник — внутренний IP смоука, кнопки оплаты во фронте нет. Выключенный контур засоряет ленту уровнем error. Чинить: не слать 503 из `_require_enabled` в Sentry через `before_send`, либо ignore-правило на группу. Код платежей не трогать. ### P2. Отказ пересылки алерта в Telegram отдаёт 502 без сохранения `glitchtip.py:246` — `HTTPException(502)`, GlitchTip не ретраит, алерт исчезает. Случай редкий: `TRADE-IN-3F7`, ровно одно событие 28.08 за всё время. Ежедневные ConnectTimeout к этому пути отношения не имеют, они из `getUpdates`. Чинить: 502 не трогать (он задуман), а ставить алерт в очередь Celery перед ответом. ### P3. Исход доставки уведомлений не наблюдаем — **уже заведено в #3157** --- ## Слепые зоны мониторинга ### P1. Данные протухли, и один источник сломан с конца июня Проверено прямым запросом к прод-БД 12.09: | Источник | Последнее обновление | Возраст | |---|---|---| | `kn_scrape_runs`, последний успех | 28.06.2026 | 76 дней | | `cadastre_jobs` | 19.06.2026 | 85 дней | | `nspd_geo_jobs` | 04.07.2026 | 70 дней | | `nspd_scrape_runs` | 30.04.2026 | 135 дней | Единственный прогон КН после июня — run 34 от 01.09 — упал: `non-JSON response: status=200 ctype=text/html`, то есть источник отдал HTML вместо данных (антибот или смена эндпоинта). Ежедневная тревога `BACKEND-46O` про freshness висит без реакции. ### P1. Celery и Redis без метрик Ни одной серии `celery_*` или `redis_*`. Глубина очереди, число воркеров и зависшие таски не измеряются. Переполнение очереди и залипший воркер снаружи не видны. ### P2. Access-логи Caddy не попадают в Loki За три часа в `gendesign-caddy-1` ноль строк `http.log.access`, только ACME, TLS и warn от reverse_proxy. Статусы, латентность и RPS фронтового прокси не наблюдаемы, 5xx приходится искать в логе uvicorn. ### P2. cAdvisor скрейпится, но серии `up` нет `alloy-infra.alloy` режет всё, кроме `container_*`, вместе с `up` и `scrape_*`. Смерть cAdvisor молча отключит `ContainerRestartLoop` и `ContainerNearMemoryLimit`, и никто не узнает. ### P2. Тихое зависание `tradein-tgbot` и `tradein-scraper` не детектируется Это не HTTP-сервисы, в `up{}` их нет. Крэш и рестарт-луп алертятся, живой процесс с застрявшим циклом — нет. Нужен `absent(container_last_seen{...})` или heartbeat из самого цикла. ### P3. Панель «Запросы по классам ответов» стекирована `apps.json`: `stacking.mode=normal`, 5xx сверху стека. 11.09 это дало ложную тревогу — верхняя линия читается как объём пятисоток, хотя их было шесть за окно. --- ## Прочее ### P1. Периодическое исчерпание пула прокси останавливает прогоны Trade-In `TRADE-IN-3HF` (avito, 50 событий с 30.08) и `TRADE-IN-38H` (cian, 11 событий с 18.08), последние — 12.09. `TRADE-IN-3P2`: city-sweep встал на первом якоре из пяти. Fallback запрещён сознательно (#2616), так что пустой пул = стоп. Пул из 4 узлов при банах площадок вычерпывается несколько раз в сутки. ### P2. `proxy_pool`: половина узлов не проходит healthcheck, и на каждый провал пишется полный traceback `checked=8 ok=4 failed=4`, 184 строки `httpx.ProxyError 407` за сутки из health-пробы. ### P2. Зависший SSH-туннель разработчика засоряет journal инфра-хоста `connect_to 127.0.0.1 port 8000: failed` — 2740 строк за сутки, самый частый error-паттерн в Loki. Это чужой шум поверх реальных отказов. Лечится снятием `LocalForward 8000` на клиенте. --- ## Замер, объясняющий часть отказов Telegram Сделан 12.09 около 13:20 МСК, оба хоста опрошены в одни и те же минуты: | Замер | Результат | |---|---| | `getMe` из контейнера `tradein-tgbot` (Selectel), 12 попыток | 9 ок, 3 ConnectTimeout | | TCP :443 на 149.154.167.220 (адрес с Selectel), 6 попыток | 5 ок, 1 таймаут | | TCP :443 на 149.154.166.110 (адрес с Beget), 8 попыток | 8 ок | | `network error` в логе бота за 24 часа | 508 строк | Хосты резолвят `api.telegram.org` в разные адреса, и путь с Selectel теряет примерно каждый четвёртый короткий запрос, а путь с Beget чист. Отсюда и 92 падения итерации poll loop за 30 дней, и разница в самочувствии двух каналов: Alertmanager живёт на Beget, бот поддержки и приёмник вебхуков GlitchTip — на Selectel. Это фон, на котором любая правка ретраев даёт ограниченный эффект. Отдельный вопрос к решению: выпускать телеграм-трафик Selectel через Beget или через прокси. --- ## Что осталось непроверенным - Реальный масштаб простоя сбора Trade-In на живой БД Selectel. - Фактическая частота сообщений в теме алертов — доходят ли они до человека. - Мониторы Uptime Kuma: конфиг лежит в volume, в git его нет. - Прод-значения переменных окружения на VM. ## Отклонено проверкой Восемь находок не подтвердились и в список не попали: среди них «Poincare отсутствует в Prometheus» (он есть под меткой `host=apps`), «#3154 секрет течёт в логи» (починено 05.09 в PR #3353), «`status.gendsgn.ru` не существует» (на него ничто и не ссылается), «137 SQL-ошибок в tradein-postgres» (одна секундная петля внешнего сканера). Refs #3467, #3159, #3158, #3157, #2616.

bot-backend referenced this issue from a commit

2026-09-12 10:49:52 +00:00

fix(ops): панель классов ответов больше не стекируется — красная линия и есть число 5xx

Rows
Columns