From 790691d0b4d80b0d3c784fcf7ef04df95abbfe6d Mon Sep 17 00:00:00 2001 From: bot-backend Date: Thu, 27 Aug 2026 21:16:06 +0300 Subject: [PATCH] =?UTF-8?q?fix(ops/metrics):=20Alertmanager=20=D0=BE=D1=82?= =?UTF-8?q?=D0=B2=D0=B5=D1=87=D0=B0=D0=BB=20404=20=D0=BD=D0=B0=20/api/v2/a?= =?UTF-8?q?lerts=20=E2=80=94=20Prometheus=20=D0=BF=D0=B8=D1=81=D0=B0=D0=BB?= =?UTF-8?q?=20=D0=BC=D0=B8=D0=BC=D0=BE?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Приёмочная проверка #3155 показала второй отказ на том же пути. Prometheus нашёл приёмник (`activeAlertmanagers` непуст), отправил уведомление — и получил 404: `alertmanager_alerts_received_total 0` при `prometheus_notifications_errors_total 1` и `dropped_total 1`. `--web.external-url=…/alertmanager` без `--web.route-prefix=/` заставляет Alertmanager обслуживать ВСЁ под этим префиксом. Проверено прямой пробой из контейнера Prometheus: `/api/v2/status` → 404, `/alertmanager/api/v2/status` → 200. Снаружи префикс при этом никому не нужен: маршрута `/alertmanager` в Caddy нет вовсе, внешний адрес используется только для ссылок в сообщениях. Симптом этого же префикса уже ловили 27.08 на healthcheck — и вылечили на стороне проверки, прописав ей путь с префиксом. Из-за этого причина осталась жива и продолжила ломать то, что чинить куда важнее. Возвращаю обычный путь healthcheck вместе с флагом. Заодно оживает датасорс Alertmanager в Grafana (`ops/metrics/grafana/provisioning/datasources/datasources.yml:37`) — он настроен на корень и до сих пор упирался в тот же 404. Closes #3161 --- docker-compose.metrics.yml | 31 ++++++++++++++++--------------- 1 file changed, 16 insertions(+), 15 deletions(-) diff --git a/docker-compose.metrics.yml b/docker-compose.metrics.yml index 381d517d..723a4f03 100644 --- a/docker-compose.metrics.yml +++ b/docker-compose.metrics.yml @@ -115,6 +115,14 @@ services: - "--config.file=/etc/alertmanager/alertmanager.yml" - "--storage.path=/alertmanager" - "--web.external-url=https://metrics.gendsgn.ru/alertmanager" + # Внешний адрес — ТОЛЬКО для ссылок в сообщениях; обслуживать всё под + # этим префиксом Alertmanager не должен. Без этой строки он отвечает + # 404 на `/api/v2/alerts`, а Prometheus именно туда и пишет: 27.08 + # Prometheus нашёл приёмник (`activeAlertmanagers` непуст), послал + # уведомление и получил 404 — `alertmanager_alerts_received_total 0` + # при `prometheus_notifications_errors_total 1`. Тот же флаг и по той + # же причине стоит у Prometheus выше. + - "--web.route-prefix=/" env_file: - path: ./backend/.env.runtime required: false @@ -136,22 +144,15 @@ services: mem_limit: 256m logging: *default-logging healthcheck: - # Путь С ПРЕФИКСОМ. `--web.external-url=…/alertmanager` выше заставляет - # Alertmanager обслуживать ВСЁ под этим префиксом, включая служебные - # ручки: `/-/healthy` отдаёт 404, а `/alertmanager/-/healthy` — OK. + # Путь БЕЗ ПРЕФИКСА — вместе с `--web.route-prefix=/` выше. # - # Прод 27.08: контейнер работал и рассылал алерты, но docker держал его - # `unhealthy` бессрочно. Само по себе безобидно, но приучает не смотреть - # на статус — а любая автоматика «перезапусти нездоровое» устроила бы из - # этого вечный перезапуск канала оповещений. - test: - [ - "CMD", - "wget", - "-q", - "--spider", - "http://localhost:9093/alertmanager/-/healthy", - ] + # Раньше здесь стоял `/alertmanager/-/healthy`: внешний адрес заставлял + # Alertmanager обслуживать под префиксом всё, включая служебные ручки, и + # `/-/healthy` отдавал 404 (прод 27.08 — контейнер работал, а docker + # держал его `unhealthy` бессрочно). Лечили симптом на стороне проверки, + # и потому не заметили, что тот же префикс ломает `/api/v2/alerts`, куда + # пишет Prometheus. Теперь причина убрана, и путь снова обычный. + test: ["CMD", "wget", "-q", "--spider", "http://localhost:9093/-/healthy"] interval: 30s timeout: 10s retries: 5 -- 2.45.3