11 commits

Author	SHA1	Message	Date
bot-backend	192fdbfbf6	fix(ops/metrics): тема «метрики» задаётся дефолтом, а не ручным заведением секрета ... Разделение тем из #3163 зависело от шага «завести секрет руками». Шаг отказал сразу же: 27.08 два прогона деплоя подряд отработали зелёными, напечатали строку про откат — и тема «метрики» осталась пустой, а весь инфраструктурный поток продолжил идти в тему клиентских инцидентов. Номер темы форума секретом не является: в репозитории уже лежат домены, пути на хостах, имена контейнеров и внешние адреса. Ставим 245 значением по умолчанию прямо в деплое; переменная окружения по-прежнему перекрывает — переезд темы или другой чат решается ею, без правки кода. Откат на METRICS_TELEGRAM_TOPIC_ID убран намеренно и запрещён тестом. Он возвращал ровно то состояние, ради ухода от которого всё затевалось, и сообщал об этом строкой в логе прогона, которую никто не читает. Молчаливое «почти правильно» хуже явной поломки. Прогнано в обе стороны: с переменной — тема из окружения, без неё — 245. backend/tests/ops — 86 passed.	2026-08-27 22:28:52 +03:00
bot-backend	b90872b5d7	feat(ops/metrics): инфра-алерты уезжают в тему «метрики», клиенты остаются в «алертах» ... Форумная группа имеет три темы, но тема «метрики» была пуста: оба прямых получателя Alertmanager — telegram и telegram-heartbeat — брали топик из той же переменной METRICS_TELEGRAM_TOPIC_ID, что и сервис alert-ack. Развести их было нечем, и heartbeat вместе со всем инфраструктурным шумом падал в ленту клиентских инцидентов. Смешанные в одной теме, инфраструктура и клиентский инцидент не равны по срочности и приучают пролистывать обе. Вводится METRICS_TELEGRAM_INFRA_TOPIC_ID для прямых получателей Alertmanager. alert-ack и вебхук GlitchTip остаются на прежней переменной, тема поддержки не тронута. Пока новая переменная не задана, берётся старая — до этого момента поведение ровно прежнее, а не сломанное. Клиентская METRICS_TELEGRAM_TOPIC_LINE убрана целиком: после переезда обоих получателей на инфраструктурную строку шаблон её не содержит, а деплой продолжал бы её собирать и объявлять в envsubst. Тест, закрепляющий сборку такой строки, зеленел бы вечно и мешал бы её убрать. Проверено рендером, а не чтением: при заданной теме telegram и telegram-heartbeat дают 245, telegram-clients уходит вебхуком без темы; при незаданной — поля message_thread_id нет вовсе (пустое значение уронило бы Alertmanager целиком). Логика отката прогнана во всех трёх состояниях переменных. backend/tests/ops — 86 passed. Closes #3163	2026-08-27 21:50:51 +03: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	5ea05cffa6	fix(ops/metrics): правки конфига Alertmanager молча не доезжали до контейнера ... Пойман на проде 27.08 сразу после мержа #3136. На диске лежал новый конфиг — `webhook_configs` на сервис кнопки подтверждения, — `amtool check-config` его одобрил, деплой зелёный. А контейнер продолжал слать алерты напрямую: на диске: webhook_configs: url http://alert-ack:8080/alertmanager в контейнере: telegram_configs: Конфиг подключён бинд-маунтом ФАЙЛА, а рендер делает `rm` и создаёт файл заново — иначе не перезаписать: после chown он принадлежит 65534 с правами 600, а каталог принадлежит деплой-пользователю. `rm` + создание даёт НОВЫЙ инод, тогда как открытый дескриптор внутри работающего контейнера продолжает смотреть на прежний, уже удалённый. `up -d` контейнер не трогает: он сравнивает описание сервиса, а содержимое бинд-маунта в сравнение не входит. Отказ беззвучный — ни одного красного признака нигде. Значит и все прежние правки маршрутизации применялись лишь тогда, когда контейнер пересоздавался по совпадению. Перезагрузка по SIGHUP/API не лечит: она перечитывает тот же открытый инод. Лечит только пересоздание контейнера — его и добавляю, под флагом, который выставляется ПОСЛЕ успешной проверки конфига. Порядок важен: при обратном битый конфиг убивал бы работающий Alertmanager вместо того, чтобы оставить прежний работать. Прод уже приведён в соответствие вручную — контейнер пересоздан, маршрут клиентских инцидентов теперь идёт через кнопку. Эта правка нужна, чтобы следующая правка конфига доехала сама. Три теста: пересоздание есть, оно закрыто проверкой флага (безусловное рвало бы доставку на каждом деплое метрик), флаг выставляется после проверки. Прогон: 78 ops-тестов зелёные, ruff чист.	2026-08-27 15:10:23 +03:00
bot-backend	6f120c6605	feat(observability): клиентский инцидент зовёт дежурного поимённо + чинит сломанное продолжение команды (#3078) ... Две вещи, вторая — исправление собственной ошибки из #3127. ## Дежурного зовут по имени 27.08 продукты лежали 10 часов, и в канале «диск занят на 86 %» и «клиенты не могут открыть сайт» выглядели одинаково. Появился отдельный маршрут: severity=critical И host=apps, то есть критично на ПРОДУКТОВОЙ машине — значит людям недоступна МЕРА и Site Finder, а не «где-то в инфраструктуре тесно». У такого сообщения другой текст (🚨 КЛИЕНТЫ ЗАТРОНУТЫ), упоминание дежурного и repeat_interval 30 минут против 3 часов у прочего критичного: пока инцидент не погашен, напоминание должно быть неудобным. Сужение по host=apps существенно. Без него дежурного звали бы на каждую инфраструктурную мелочь, и тег перестал бы что-либо значить за неделю. Сам аккаунт в репозиторий не попадает — берётся из METRICS_TELEGRAM_ONCALL. Дежурный меняется, конфиг в git — нет. Пустая переменная = сообщение без тега, поведение не ломается. ## Починка: комментарий внутри продолжения команды В #3127 блок rm -f вместе с комментарием встал МЕЖДУ строками, каждая из которых заканчивалась обратным слешем. Строки склеиваются, и весь вызов envsubst уехал в комментарий — конфиг Alertmanager перестал бы рендериться вовсе, при полностью зелёном деплое. Синтаксически это корректный шелл, bash -n такое не ловит, а в диффе не видно: строки выглядят как отдельные. Поэтому проверка структурная и применяется ко ВСЕМ shell-блокам workflow, а не только к месту ожога.	2026-08-27 13:05:32 +03:00
bot-backend	630f3e6e76	fix(observability): конфиг Alertmanager читается контейнером — гейт падал на своих же правах (#3078) ... Как только канал алертов реально включился (#3126), профиль alerts впервые дошёл до проверки конфига — и деплой встал: amtool: error: failed to validate 1 file(s) Checking '/tmp/am.yml' FAILED: open /tmp/am.yml: permission denied Отрендеренный конфиг пишется с правами 600 и принадлежит деплой-пользователю, а и amtool, и сам Alertmanager в образе prom/alertmanager работают под nobody (65534). Прочитать чужой файл 600 они не могут. Проверка падала не на содержимом конфига, а на доступе к нему — и контейнер после подъёма упал бы ровно там же. Дефект не поймали раньше по понятной причине: без токена профиль alerts не включался, и эта ветка не исполнялась НИ РАЗУ с момента появления гейта в #3111. Проверка, которая никогда не запускалась, ничем не отличается от отсутствующей — это ровно тот класс тихой поломки, ради которого весь стек и заводится. Права не ослабляем: в файле лежит токен бота. Вместо chmod 644 (который внёс бы токен в список файлов, читаемых любым локальным пользователем машины) отдаём файл во владение 65534 одноразовым контейнером от root — passwordless sudo на хосте нет, а бинд-маунт правит host-инод напрямую. Доступ остаётся ровно у того, кто конфиг читает. Следствие, которое легко проглядеть: после смены владельца `>` в этот файл на следующем деплое уже не запишет, поэтому добавлен rm перед рендером — каталог принадлежит деплой-пользователю, пересоздать файл он может.	2026-08-27 12:58:15 +03:00
bot-backend	30a21abfa7	feat(observability): токен алертов приходит из секретов Actions, а не только с машины (#3078) ... Стек наблюдаемости был готов ещё вчера, но Alertmanager не поднимался: профиль alerts включается, только когда заданы METRICS_TELEGRAM_BOT_TOKEN и METRICS_TELEGRAM_CHAT_ID, а читались они ИСКЛЮЧИТЕЛЬНО из файла окружения на инфраструктурной машине. То есть включить алерты можно было только правкой прод-файла руками по ssh — в обход репозитория, без следа в истории и без возможности сделать это из CI. Именно это и держало задачу открытой дольше нужного. Цена промедления измерена: 27.08 продукты лежали 10 часов, и ни одно звено оповещения не сработало (#3119); в тот же день сутки не доезжал деплой, и об этом тоже никто не узнал (#3029). Теперь три переменные форвардятся в ssh-шаг из секретов Actions. Порядок разрешения сохранён осознанно: инжектированные значения ставятся ДО того, как скрипт подхватит окружение машины, поэтому хост, если ключи заданы на нём, переопределяет секреты — последнее слово остаётся за машиной, а секреты работают как разумный дефолт. Канал проверен вживую: бот MERAsupport_bot, форум «МЕРА», тема «алерты» (message_thread_id=158) — пробное сообщение доставлено.	2026-08-27 12:52:25 +03:00
bot-backend	5b7ef161e3	feat(observability): алерты адресуются в топик форумной группы (#3078) ... Бот, которым шлются тревоги, — тот же, что пересылает сообщения поддержки, а его чат форумный. Без message_thread_id Alertmanager кладёт тревоги в общую тему, вперемешку с клиентской перепиской. Поле поддерживается: проверено amtool check-config на том же образе, что поднимается в проде (prom/alertmanager:v0.28.0). Схема Alertmanager строгая и неизвестные поля отвергает, так что успешная проверка означает именно поддержку, а не молчаливое игнорирование. Подставляется ЦЕЛАЯ СТРОКА, а не значение: envsubst не умеет условий, и при шаблоне вида `message_thread_id: ${TOPIC_ID}` незаданный топик дал бы `message_thread_id:` без значения. Это не деградация - Alertmanager с таким конфигом не стартует вовсе, то есть алертинг исчезает целиком. Деплой формирует либо всю строку с отступом, либо пустую. Топик необязателен: без него поле отсутствует, алерты уходят в общую тему, поведение прежнее. Попутно добавлена проверка конфига через amtool ДО подъёма стека - по образцу `caddy validate` ниже в этом же файле. amtool берётся из того же образа, что и сам Alertmanager, иначе проверялась бы не та версия схемы. Битый конфиг теперь роняет деплой громко, а не выключает алертинг тихо. Тесты (4) рендерят шаблон обоими способами и разбирают результат как YAML - проверяется фактический конфиг, а не наличие нужных слов в тексте. Отдельно проверено, что переменная объявлена в списке envsubst: забыть её - значит оставить в конфиге литерал плейсхолдера. Фальсификация: на исходных файлах краснеют 3 из 4; проходит только тест, фиксирующий сохранённое поведение при незаданном топике. tests/ops целиком - 35 passed.	2026-08-26 14:10:56 +03:00
bot-backend	beafe6925b	fix(observability): агент не падает из-за переменной чужой роли (#3078) ... Джоба agent-apps упала целиком: error while interpolating services.postgres-exporter-infra.environment. DATA_SOURCE_NAME: required variable INFRA_EXPORTER_DSN is missing a value INFRA_EXPORTER_DSN нужен экспортеру с profiles: ["infra"], который на продуктовом хосте не поднимается вовсе. Но compose интерполирует ВЕСЬ файл до фильтрации по профилям, поэтому `${VAR:?}` роняет команду из-за чужой переменной. Вместе с агентом не поднялись alloy, node-exporter и cadvisor, которым никакой DSN не нужен. Симметрично упал бы и инфраструктурный агент - на двух продуктовых переменных. Второй дефект в той же цепочке: GENDESIGN_EXPORTER_DSN тоже отсутствовал. setup-metrics-exporter-dsn.sh читает только runtime-файл окружения бэкенда, а DATABASE_URL и TRADEIN_DATABASE_URL живут в основном. Значит подстановка всегда была пустой, add_key печатал "нечем заполнить" и выходил с кодом 0 - мягкий пропуск встречался с жёстким требованием compose. Стало: - compose: `:-` вместо `:?` у трёх DSN. Интерполяция больше не может упасть. - deploy-metrics.yml: профиль экспортеров включается, только если нужные ЭТОЙ роли DSN заполнены; иначе ::warning и агент поднимается без экспортера. Громкость не убрана, а перенесена туда, где роль известна. Тот же приём, что уже применён к Alertmanager в джобе server. - setup-metrics-exporter-dsn.sh: читает оба файла окружения (базовый, затем runtime - он перекрывает). Пишет по-прежнему только в runtime, лишних копий пароля не заводит. Почему `:-` не ослабление: пустой DATA_SOURCE_NAME поднял бы экспортер, который молча не отдаёт метрик, - ровно тот тихий отказ, ради которого весь стек и заводится. Поэтому пустой DSN теперь означает "профиль не включаем", а не "поднимаем пустым". Известное следствие, отмеченное в коде: INFRA_EXPORTER_DSN не собирает никто - скрипт знает только про GENDESIGN_/TRADEIN_ и работает на продуктовом хосте. Пока это так, инфраструктурный агент будет честно предупреждать, что метрик Postgres инфры нет, вместо того чтобы падать целиком. Тесты (3) структурные, проверяют оба конца инварианта: обязательности не вернулись в compose; каждая DSN-переменная проверяется в деплое; профили не захардкожены. Фальсификация: на исходных файлах краснеют все три.	2026-08-26 12:45:31 +03:00
bot-backend	33bc7e4acf	fix(observability): привилегированную роль спрашиваем у контейнера, а не угадываем (#3078) ... Стек наблюдаемости не поднялся ни на одном хосте после мержа #3099: джоба server упала, agent-apps и agent-infra пропустились как зависимые. Причина (задача 23657, 26.08 08:55): err: ОШИБКА: не нашёл роль с правом CREATE ROLE в gendesign-infra-postgres setup-metrics-grafana-role.sh искал привилегированную роль перебором трёх имён - glitchtip, forgejo, postgres. Ни одно не совпадает ни с одним реальным кластером проекта: infra-postgres -> infra, gendesign-postgres-1 -> gendesign, tradein-postgres -> tradein. Комментарий над перебором сам предупреждал, что "угадывать postgres неверно", и дальше шло угадывание. Замер на живом контейнере 26.08 (read-only, ничего не создавалось): POSTGRES_USER изнутри контейнера: infra glitchtip - отказ, forgejo - отказ, postgres - отказ, infra - 1 Стало: имя берём из POSTGRES_USER самого контейнера - это та переменная, которой роль и создана при initdb, то есть источник истины. Прежний список оставлен ПОСЛЕ него запасным путём для кластера не из образа postgres. Попутно - глоб в paths деплоя. Воркфлоу запускает ТРИ setup-скрипта, а в триггере стоял только setup-metrics-secrets.sh: правка двух остальных не заводила выкат, и на хосте молча оставалась старая версия. Тот же класс, что #2203 закрыл глобом ops/*.sh. Добавлен тест, который сверяет запускаемые скрипты с шаблонами paths - на исходном воркфлоу он краснеет, указывая на setup-metrics-exporter-dsn.sh. Тесты (6) исполняют РЕАЛЬНЫЙ скрипт с подставным docker и проверяют фактический выбор роли, а не наличие правильных слов в комментарии. Фальсификация: на исходном коде краснеют 3 из 5 ролевых тестов; проходят только те два, что фиксируют сохранённое поведение (запасной перебор и громкая ошибка при отсутствии привилегий). tests/ops целиком - 28 passed.	2026-08-26 12:08:37 +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