Мера: тревога, когда бэкенд лёг, а лэндинг ещё открывается из кэша #3553
No reviewers
Labels
No labels
Fable 5 ревью
GG-форсайт
admin
analytics
auth
automation
bug
business
chore
ci
compliance
data
data-moat
docs
duplicate
dx
enhancement
feedback/max
generative
needs-discussion
needs-human
observability
pause-bots
performance
priority/p0
priority/p1
priority/p2
priority/p3
scope/backend
scope/db
scope/devops
scope/frontend
scope/qa
scrapers
security
site-finder
stage/1
stage/2
status/blocked
status/done
status/needs-analysis
status/needs-fix
status/qa
status/ready
status/review
status/wip
tech-debt
tradein
ux
week ревью 1
wontfix
ИРД
вторичка
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: lekss361/gendesign#3553
Loading…
Add table
Reference in a new issue
No description provided.
Delete branch "fix/mera-observability"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Часть #2214 (эпик #2200). Issue этим PR не закрывается: остались два шага, которые делаются не кодом (см. ниже).
#2214: мёртвый бэкенд Меры не поднимал тревоги вне Poincare
Что было. Из четырёх пунктов приёмки три уже выполнены раньше и перепроверены 17.09:
deploy-tradein.yml, после цикла стоитexit 1(PR #2231);Открытым оставался пункт «внешняя проба на публичные эндпоинты Меры + алерт». Проверил 17.09, только чтение:
select … from uptime_monitor). Из них к Мере относится один: id=6,https://meraocenka.ru/. Лэндинг отдаёт tradein-frontend из пререндер-кэша (x-nextjs-prerender: 1,x-nextjs-cache: HIT), поэтому при мёртвом бэкенде он всё равно отвечает 200.gendsgn.ru/healthпроверяет бэкенд Птицы: в apps.caddyhandle /healthведёт наbackend:8000.AppHighErrorRateиAppHighLatencyP95считаются по метрикам, которые отдаёт сам бэкенд. Когда бэкенд мёртв, метрик нет, и оба правила молчат.TradeInBackgroundContainerMissingследит только за tgbot и scraper.up{job="app",app="mera",instance="tradein-backend:8000",host="apps"}в Prometheus на Beget есть, но правила на неё не было.Итог: если хост и фронт живы, а бэкенд Меры упал или завис, вне Poincare не срабатывало ничего.
Что сделано. В
ops/metrics/prometheus/rules/infra.yml, группаapp, добавлено правилоMeraBackendDown:critical+appsотправляет тревогу по маршрутуtelegram-clients: alert-ack на Beget, затем тема 158 в Telegram. Правило вычисляется и доставляется на Beget.up=0.absent()срабатывает, когда цель тихо пропала изalloy-apps.alloy.Почему
for: 5m. Выгрузил сырые точкиup{app="mera"}за 26.08–17.09 (61 857 точек). Нулей было 140 серий, все короткие, это окна деплоя. Самая длинная серия: 4 нулевые точки подряд, около 2 минут до восстановления. 5 минут дают запас в 2.5 раза. Ни один из 140 провалов тревогу бы не поднял.Чего правило не видит. Публичный путь до бэкенда (DNS, TLS, Caddy на meraocenka.ru) оно не проверяет, скрейп идёт изнутри docker-сети. Для лэндинга этот путь проверяет монитор 6.
Тесты
Добавлены три случая
promtool test rulesвops/metrics/prometheus/tests/infra_test.yml. Деплой метрик прогоняет их перед reload.app=mera, instance=tradein-backend:8000.Прогон тем же образом, что на проде (
prom/prometheus:v3.1.0):promtool check rules rules/infra.yml:SUCCESS: 25 rules found, rc=0;promtool test rules tests/infra_test.yml:SUCCESS, rc=0. Прежние случаи из #3493 тоже зелёные.Проверки в CI для PR нет:
deploy-metrics.ymlгоняет promtool только на push в main.Фальсификация
Каждый раз портил копию
infra.yml, затем восстанавливал из копии (diff -qбез различий) и получал зелёный прогон.absent():for: 1mвместо5m:got:[], rc=1.Что остаётся в #2214 (делается не кодом)
GET https://meraocenka.ru/trade-in/api/public/mera/stats, ожидать 200, интервал 60 с. Эта ручка уже проксируется на meraocenka.ru и ходит в tradein-backend и БД: 17.09 ответила 200 за 0.2 с. Лимит 30 запросов в минуту с одного IP, минутный монитор в него укладывается. Caddy для этого менять не нужно.MeraBackendDown.Эпик #2200 закрывать рано: его последняя открытая дочерняя задача — #2214.
Приёмка на проде после мержа (дата проверки: не позже 19.09.2026)
Prometheus: конфиг и правила проверены, reload подтверждён.docker exec gendesign-prometheus wget -qO- 'http://localhost:9090/api/v1/rules?rule_name[]=MeraBackendDown'показывает правило сhealth: "ok"иstate: "inactive".ALERTS{alertname="MeraBackendDown",alertstate="firing"}пуст.Деплой: правка в
ops/metrics/**запускаетdeploy-metrics.yml. Он делает штатный reload Prometheus и по своему обычному сценарию пересоздаёт alertmanager, alert-ack и tg-relay на Beget, а также alloy на обоих хостах. Контейнеры Меры (backend, scraper, browser, postgres) не трогаются, поэтому гейт поscrape_runsне нужен. Миграций нет.🤖 Generated with Claude Code
Мёртвый или зависший tradein-backend не давал ни одного сигнала вне Poincare. GlitchTip-монитор 6 смотрит на лэндинг meraocenka.ru, а его отдаёт фронт из пререндер-кэша (x-nextjs-cache: HIT) — при мёртвом бэкенде там 200. Монитор 2 (gendsgn.ru/health) проверяет бэкенд Птицы. AppHighErrorRate и AppHighLatencyP95 считают метрики самого бэкенда и при его смерти молчат. Новое правило MeraBackendDown: up{job="app",app="mera"} == 0 или серия пропала, 5 минут, severity critical + host apps — маршрут telegram-clients, тема 158. Считается и доставляется на Beget. Порог 5 минут откалиброван по истории up за 26.08–17.09: 140 провалов, самый длинный — 4 нулевые точки (~2 минуты, окна деплоя). Юнит-тесты promtool: мёртвый бэкенд — тревога; окно деплоя и упавшая Птица — тишина; цель пропала из скрейпа — тревога. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>