6 commits

Author	SHA1	Message	Date
bot-backend	62a560387c	feat(ops): измеряем очередь Celery и Redis, до сих пор слепая зона ... Prometheus не видел ни одной серии celery_*/redis_* — переполнение очереди Site Finder и залипший воркер снаружи выглядели одинаково, тишиной (issue #3471). Добавлено (только на продуктовом хосте, профиль apps): - redis-exporter (oliver006/redis_exporter) — здоровье общего Redis (db0 celery-брокер Site Finder, db1 SearchCache trade-in, db2 glitchtip), адрес через alias gendesign-redis на сети shared, без нового сетевого доступа. - celery-exporter (danihodovic/celery-exporter) — глубина очереди, число живых воркеров, счётчик неуспешных задач. Выбран вместо redis-exporter --check-keys, потому что дефолтная очередь "celery" дала бы только глубину, но не воркеров и не failures. - Скрейп обоих в alloy-apps.alloy. - Алерты в infra.yml: RedisDown, NoActiveCeleryWorkers, CeleryQueueGrowing (порог 150 предварительный — реальных данных по глубине очереди ещё нет, пересмотр через неделю наблюдений). Имена метрик celery-exporter (celery_queue_length, celery_worker_up, celery_task_failed_total) — по документации проекта, без прогона на реальном брокере; сверить после первого деплоя, см. комментарий у сервиса. promtool check rules — 23 правила, SUCCESS. Refs #3471	2026-09-12 14:16:24 +03:00
bot-backend	655652ae1c	feat(ops): алерты уровня приложения и три слепые зоны мониторинга ... - AppHighErrorRate / AppHighLatencyP95 (job="app", severity=critical, host="apps") — доля 5xx и p95 задержки по http_requests_total / http_request_duration_seconds_bucket теперь ловятся Prometheus'ом, а не только постфактум в GlitchTip. Пара critical+apps обязательна для маршрута telegram-clients в alertmanager.yml.tmpl. - Inhibit по HostAgentDown больше не гасит critical того же хоста — target_matchers сужен до severity="warning" (падение node-exporter раньше молча забирало с собой PostgresLongTransactionCritical и critical-алерты cAdvisor). - cAdvisor: keep-фильтр в alloy-infra.alloy резал у него `up` наравне с container_*-мусором — job "cadvisor" не публиковал свою же серию `up`. Пропущены up/scrape_samples_scraped, добавлен CadvisorDown. - TradeInBackgroundContainerMissing по absent(container_last_seen) на tradein-tgbot/tradein-scraper — эти контейнеры не HTTP-сервисы и в up{} не участвуют вовсе; крэш без рестарта раньше не алертился. Не закрыто: живой, но зависший процесс tgbot/scraper (container_last_seen не про внутренний прогресс, а про то, что Docker видит контейнер running). Refs #3471	2026-09-12 13:57:54 +03:00
bot-backend	33714e464e	fix(alerts): в тексте тревоги печаталась не та величина, которую текст называет ... Боевые сообщения в Telegram 12.09: «apps / tradein-browser: 2.684e+11% от mem_limit. Дальше OOM-kill.» «apps / listings: доля HOT 75.21%.» — при пороге срабатывания «доля < 20%» Причина общая и она про ФОРМУ выражения, а не про условие: в PromQL `A and B` возвращает ЗНАЧЕНИЯ ЛЕВОЙ части, отфильтрованные правой. В `$value` попадало A: - ContainerNearMemoryLimit: слева стоял `container_spec_memory_limit_bytes` — в сообщение уходил лимит в байтах (2 684 354 560), отрендеренный как процент. Замер 12.09: настоящее потребление того контейнера — 1.2 % лимита. - PostgresLowHotUpdateRatio: слева стоял `rate(tup_upd[6h])` — апдейтов в секунду. Это опаснее: 0.7521 превращалось в «75.21%», попадало в правдоподобный диапазон и противоречило собственному порогу, но выглядело настоящим числом. Замер 12.09 по listings: rate(tup_upd[6h]) = 0.0411 → сообщение сказало бы «4.11%», настоящая доля HOT = 0.00%. Условия срабатывания в обоих случаях были ВЕРНЫ — врал только текст, поэтому дефект и прожил незамеченным. Правка: отношение вынесено влево, а побочное условие — внутрь знаменателя (`X / (Y > 0)`), где оно и фильтрует серии, и защищает от деления на ноль. Проверено на живом Prometheus (только чтение): новое выражение памяти отдаёт доли 0.35–0.71 (топ — gendesign-infra-postgres 70.8 %), новое выражение HOT — доли 0.00–1.00. `promtool check rules` — SUCCESS, 16 rules. Третье правило того же семейства (PostgresDeadTuplesHigh) верно, но верно случайно: печатаемая величина совпала с левым операндом. Помечено комментарием, чтобы его не «причесали» по образцу двух других. Гейт: backend/tests/ops/test_alert_value_is_the_described_quantity.py — если описание рендерит `$value` как долю (`humanizePercentage`), левая часть выражения обязана содержать деление. Фальсификация: вернул файл правил с origin/main → красные test_percentage_annotations_come_from_a_ratio и test_known_two_rules_are_fixed; с правкой — 3 passed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-12 14:27:02 +05:00
bot-backend	99125b8093	fix(ops/metrics): Prometheus не видел ни одного Alertmanager — цель file_sd осталась пустой ... Профиль alerts включили, а файл целей `alertmanager_targets.yml` остался плейсхолдером `[]`. Снаружи всё зелёное: alertmanager и alert-ack Up/healthy, деплой зелёный, в логах ни одной ошибки — при этом `activeAlertmanagers: []` и 1568 уведомлений в `prometheus_notifications_dropped_total`. Горящий с 26.08 `Watchdog` не доехал никуда, как и HostAgentDown с RemoteWriteStalled. Причина в том, что включатель профиля и цель для Prometheus лежали в разных местах: профиль поднимает deploy-metrics.yml по наличию токена и чата, а файл целей правился руками. Разъезд не ловится ничем — `[]` штатен при выключенном профиле, поэтому ни валидация, ни healthcheck, ни лог на него не реагируют. Файл становится производным (`alertmanager_targets.gen.yml`, в .gitignore) и рендерится деплоем тем же условием, что включает профиль: цель при включённых алертах, `[]` при выключенных. Рендер идёт до `up` и пишет усечением на месте, поэтому инод сохраняется и работающий Prometheus подхватывает цель сам — та же ловушка одиночного бинд-маунта, что уже описана в этом workflow у Alertmanager. Пустой список пишется явно, а не удалением файла: несуществующий путь docker подменяет каталогом, и Prometheus не стартует вовсе. Closes #3155	2026-08-27 21:10:25 +03:00
bot-backend	c6e15954ba	fix(observability): контейнерные метрики терялись целиком + два хвоста стека ... Три независимых дефекта, найденных на живом проде после подъёма стека метрик. 1. cAdvisor-метрики не доезжали ВООБЩЕ. В Prometheus ноль имён container_* при 2034 именах всего, хотя cAdvisor отдаёт 880 рядов, scrape-таргет в alloy health=up с последним скрейпом 10 мс назад, а remote_write рабочий (node/postgres идут через него же и доезжают). Методом исключения — потери в prometheus.relabel.cadvisor_trim, во втором правиле: rule { source_labels = ["name"], regex = "", action = "drop" } Замысел был выкинуть безымянные cgroup-ряды (id="/"). Но regex в Alloy документированно дефолтится в (.*), и пустая строка неотличима от незаданного значения — такой drop рискует выкидывать вообще всё, что и наблюдалось. Заменено на однозначное keep regex=".+" — тот же замысел, без зависимости от того, как трактуется пустой regex. 2. healthcheck alloy не мог пройти никогда: дёргал wget, которого в образе grafana/alloy нет (как и curl, и nc). Контейнер вечно unhealthy при полностью исправном alloy — ложная тревога, маскирующая настоящие сбои. Заменено на сырой HTTP через bash /dev/tcp, без внешних утилит. 3. Prometheus раз в минуту писал "lookup alertmanager: no such host" и держал up{job="alertmanager"}=0. Alertmanager намеренно за профилем alerts до решения #3078 — дефект не в профиле, а в безусловной ссылке на сервис. Оба места (alerting.alertmanagers и job_name: alertmanager) переведены на file_sd_configs с файлом целей, по умолчанию пустым: целей нет — ошибок тоже нет. Prometheus перечитывает file_sd на лету, поэтому включение профиля сведётся к наполнению файла, без рестарта и правки конфига. Файл целей смонтирован в сервис prometheus явным volume. Проверено на живом хосте, не на глаз: - alloy fmt обоих .alloy в одноразовом контейнере grafana/alloy:v1.6.1 - exit 0 - promtool check config в prom/prometheus:v3.1.0 - valid, 16 rules found - механизм нового healthcheck выполнен внутри работающего gendesign-alloy: первая строка ответа "HTTP/1.0 200 OK", grep матчится, RESULT=HEALTHY - наличие bash/head/grep/printf в образе alloy подтверждено command -v	2026-08-26 13:14:28 +03:00
bot-backend	309d273f3f	feat(observability): стек метрик и логов — Prometheus, Loki, Grafana, агенты на обоих хостах ... Метрик в проекте не было ни одной: ни экспортеров, ни /metrics в бэкендах, единственный канал наблюдения — journald, единственный сигнал об аварии — исключение в GlitchTip. Из-за этого целый класс отказов невидим в принципе: задача рапортует done, строк ноль, исключения нет. Так протухли данные на семь месяцев (#2998), 34 дня был мёртв house_imv_backfill (#2698), 8 суток писал ноль newbuilding_enrich (#2767), 91 день копилось раздутие listings (#2992). Grafana не заменяет GlitchTip: ошибки остаются там. Grafana OSS не принимает Sentry DSN ни одним компонентом, а скрубберы в before_send — требование 152-ФЗ. Здесь появляется другой класс данных: ряды и алерты по трендам. Наблюдатель поставлен у ДРУГОГО провайдера, чем наблюдаемое: серверная сторона на Beget, рядом с GlitchTip. Если ляжет Poincare, мониторинг должен об этом сказать, а не лечь вместе с ним. Транспорт push, а не pull: агент на Poincare шлёт remote_write и логи исходящим HTTPS, поэтому там не открывается ни одного входящего порта сверх 22/80/443. При обрыве канала Alloy копит в WAL и досылает — pull-скрейп в той же ситуации терял бы точки именно в аварии, ради которой мониторинг и нужен. Два контура доступа с разными учётками. Пароль приёмника по построению лежит открытым на продуктовом хосте, значит его компрометация неизбежна вместе с хостом; будь это учётка витрины, утёк бы и доступ к дашбордам. GlitchTip читается прямым SQL, а не Sentry-плагином: у плагина на 6.1.6 stats_v2 отдаёт 500 (баг GlitchTip #381), Events/Discover — 404 (#416), а в grafana/sentry-datasource слово glitchtip не встречается ни разу. Схема сверена на живой базе: колонка времени называется timestamp, а не received, и отдельной таблицы IssueIndex не существует — агрегаты лежат на самой issue_events_issue. Алерты за профилем alerts: канал доставки — открытый вопрос #3078, и стек не должен на нём стоять. Деплой предупреждает, что уведомлять пока некому. Каждая настройка, способная отказать молча, закрыта явно: ретенция Prometheus задана и по времени и по размеру, retention_enabled у компактора Loki (без него retention_period не работает вовсе), путь к журналу и запуск Alloy от root (иначе агент читает ноль записей без ошибки), проверка Caddy до перезагрузки (на этом хосте тот же Caddy держит git, errors и obsidian). Refs #3078	2026-08-26 10:45:54 +03:00