fix(observability): healthcheck Alertmanager стучится по правильному пути — контейнер был вечно unhealthy #3134

Merged

lekss361 merged 1 commit from fix/3078-alertmanager-healthcheck-prefix into main

2026-08-27 10:53:27 +00:00

lekss361 commented

2026-08-27 10:49:15 +00:00

Owner

Найдено при сквозной проверке прода после включения алертов.

Замер

--web.external-url=https://metrics.gendsgn.ru/alertmanager заставляет Alertmanager обслуживать всё под этим префиксом, включая служебные ручки. Проверено внутри контейнера:

wget http://localhost:9093/-/healthy               → 404 Not Found
wget http://localhost:9093/alertmanager/-/healthy  → OK

Контейнер при этом работал и рассылал алерты — 45 минут аптайма, конфиг загружен, кластер собрался. Но docker держал его unhealthy бессрочно.

Почему это стоит чинить, а не игнорировать

Само по себе безобидно — и ровно поэтому вредно. Статус, который всегда красный, приучают не смотреть; когда он покраснеет по делу, разницы никто не заметит.

Плюс прямой риск: любая автоматика вида «перезапусти нездоровый контейнер» — а такие правила заводят рано или поздно — устроила бы из этого вечный перезапуск канала оповещений. То есть выбивала бы именно то, что обязано работать в аварию.

Refs #3078

Найдено при сквозной проверке прода после включения алертов. ## Замер `--web.external-url=https://metrics.gendsgn.ru/alertmanager` заставляет Alertmanager обслуживать **всё** под этим префиксом, включая служебные ручки. Проверено внутри контейнера: ``` wget http://localhost:9093/-/healthy → 404 Not Found wget http://localhost:9093/alertmanager/-/healthy → OK ``` Контейнер при этом **работал и рассылал алерты** — 45 минут аптайма, конфиг загружен, кластер собрался. Но docker держал его `unhealthy` бессрочно. ## Почему это стоит чинить, а не игнорировать Само по себе безобидно — и ровно поэтому вредно. Статус, который всегда красный, приучают не смотреть; когда он покраснеет по делу, разницы никто не заметит. Плюс прямой риск: любая автоматика вида «перезапусти нездоровый контейнер» — а такие правила заводят рано или поздно — устроила бы из этого вечный перезапуск канала оповещений. То есть выбивала бы именно то, что обязано работать в аварию. Refs #3078

lekss361 added 1 commit 2026-08-27 10:49:15 +00:00

fix(observability): healthcheck Alertmanager стучится по правильному пути — контейнер был вечно unhealthy

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

Details

CI / changes (pull_request) Successful in 15s

Details

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

Details

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

Details

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

Details

CI / backend-tests (pull_request) Has been skipped

Details

CI / frontend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Has been skipped

Details

ede45f2a31

--web.external-url=…/alertmanager заставляет Alertmanager обслуживать ВСЁ
под этим префиксом, включая служебные ручки. Проверено на проде:

    /-/healthy               → 404 Not Found
    /alertmanager/-/healthy  → OK

Контейнер при этом работал и рассылал алерты, но docker держал его
unhealthy бессрочно. Само по себе безобидно — и ровно поэтому вредно:
статус, который всегда красный, приучают не смотреть. А любая автоматика
вида «перезапусти нездоровое» устроила бы из этого вечный перезапуск
канала оповещений — то есть выбивала бы именно то, что должно работать
в аварию.