Деплой метрик перечитывает конфиг Prometheus, а не только кладёт его на диск #3476

Merged

lekss361 merged 1 commit from fix/3467-metrics-deploy-reload into main

2026-09-12 11:18:29 +00:00

lekss361 commented

2026-09-12 10:57:02 +00:00

Owner

Закрывает #3467, пункт из #3471.

Что было

GET /api/v1/status/runtimeinfo у боевого Prometheus отдавал lastConfigTime = 2026-08-27T18:12:27Z, ровно равный startTime контейнера. Шестнадцать суток любая правка ops/metrics/prometheus/** доезжала до диска и не вступала в силу, при этом Deploy Metrics был зелёный. Это тот же класс, что #3448: объявлено не равно исполняется, и отрицательного признака у него нет.

Что сделано

Шаг после существующего ожидания здоровья Prometheus, по образцу того, как в этом же workflow уже сделано для Caddy:

promtool check config и promtool check rules внутри контейнера.
Только при успешной валидации — POST /-/reload, с чтением lastConfigTime до и после.
Приёмка: если lastConfigTime не изменился или пуст, шаг красный. Работающий Prometheus при этом не тронут.
Провал валидации означает, что reload не зовётся вовсе и шаг падает с внятным сообщением — старый конфиг остаётся жить, но деплой об этом честно сообщает.

Тест backend/tests/ops/test_3467_prometheus_reload.py, 6 проверок: валидация конфига и правил присутствует, reload идёт строго после неё и внутри её ветки, провал валидации не приводит к reload, приёмка сравнивает lastConfigTime до и после.

Соседи стека, проверено попутно

Alertmanager — в этой дыре не находится, у него отдельный механизм пересоздания контейнера по флагу ALERTMANAGER_RERENDERED (#3078, #3136), потому что SIGHUP и /-/reload там не помогают: переиспользуется инод открытого файла.
Loki — тот же паттерн: up -d не пересоздаёт контейнер при правке бинд-маунта, а полноценного reload у него нет, только частичный по SIGHUP. Не чинилось, вынесено в findings.
Grafana — provisioning читается при старте, датасорсы по таймеру не обновляются.
Alloy — свой HTTP-эндпоинт reload есть, в workflow не вызывается.

Три последних пункта — предмет отдельного тикета, в этот PR не тянул.

Приёмка на проде

После деплоя GET /api/v1/rules должен отдать ContainerNearMemoryLimit с выражением, начинающимся с container_memory_working_set_bytes — то есть правка #3464 наконец вступит в силу. Это же и доказательство, что шаг работает.

Закрывает #3467, пункт из #3471. ## Что было `GET /api/v1/status/runtimeinfo` у боевого Prometheus отдавал `lastConfigTime = 2026-08-27T18:12:27Z`, ровно равный `startTime` контейнера. Шестнадцать суток любая правка `ops/metrics/prometheus/**` доезжала до диска и не вступала в силу, при этом Deploy Metrics был зелёный. Это тот же класс, что #3448: объявлено не равно исполняется, и отрицательного признака у него нет. ## Что сделано Шаг после существующего ожидания здоровья Prometheus, по образцу того, как в этом же workflow уже сделано для Caddy: 1. `promtool check config` и `promtool check rules` внутри контейнера. 2. Только при успешной валидации — `POST /-/reload`, с чтением `lastConfigTime` до и после. 3. Приёмка: если `lastConfigTime` не изменился или пуст, шаг красный. Работающий Prometheus при этом не тронут. 4. Провал валидации означает, что reload не зовётся вовсе и шаг падает с внятным сообщением — старый конфиг остаётся жить, но деплой об этом честно сообщает. Тест `backend/tests/ops/test_3467_prometheus_reload.py`, 6 проверок: валидация конфига и правил присутствует, reload идёт строго после неё и внутри её ветки, провал валидации не приводит к reload, приёмка сравнивает `lastConfigTime` до и после. ## Соседи стека, проверено попутно - **Alertmanager** — в этой дыре не находится, у него отдельный механизм пересоздания контейнера по флагу `ALERTMANAGER_RERENDERED` (#3078, #3136), потому что SIGHUP и `/-/reload` там не помогают: переиспользуется инод открытого файла. - **Loki** — тот же паттерн: `up -d` не пересоздаёт контейнер при правке бинд-маунта, а полноценного reload у него нет, только частичный по SIGHUP. Не чинилось, вынесено в findings. - **Grafana** — provisioning читается при старте, датасорсы по таймеру не обновляются. - **Alloy** — свой HTTP-эндпоинт reload есть, в workflow не вызывается. Три последних пункта — предмет отдельного тикета, в этот PR не тянул. ## Приёмка на проде После деплоя `GET /api/v1/rules` должен отдать `ContainerNearMemoryLimit` с выражением, начинающимся с `container_memory_working_set_bytes` — то есть правка #3464 наконец вступит в силу. Это же и доказательство, что шаг работает.

lekss361 added 1 commit 2026-09-12 10:57:03 +00:00

fix(ops): деплой метрик перечитывает конфиг Prometheus, а не только кладёт его на диск

CI Trade-In / changes (pull_request) Successful in 8s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI / changes (pull_request) Successful in 11s

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Successful in 3m14s

Details

CI / backend-tests (pull_request) Successful in 19m15s

Details

6febb36afd

lastConfigTime у gendesign-prometheus совпадал со startTime контейнера 16
суток: docker compose up -d не пересоздаёт контейнер из-за изменения
содержимого бинд-маунта (сравнивается только описание сервиса), а
--web.enable-lifecycle был включён, но /-/reload никто не вызывал. Любая
правка ops/metrics/prometheus/** доезжала до диска и молча не вступала в
силу до случайного рестарта, при зелёном деплое.

Добавлен шаг по образцу уже работающей проверки Caddyfile в этом же
workflow: promtool check config + promtool check rules внутри контейнера,
reload только при успешной проверке, приёмка через сравнение
lastConfigTime до/после (обновляется на каждый успешный reload, поэтому
надёжно ловит и несостоявшийся вызов). Провал promtool теперь роняет шаг
и не трогает работающий Prometheus.

Alertmanager уже чинился отдельно (--force-recreate, #3078/#3136) — reload
для него намеренно не помогает из-за переиспользуемого инода, это не
regressed. Loki (/etc/loki/loki-config.yml), Grafana (provisioning) и Alloy
(config.alloy) в том же деплое лежат на дисковых бинд-маунтах без reload —
чинить их этим PR не стал, см. summary задачи.

Refs #3467, #3471