Резервный канал для алертов GlitchTip: приём на alert-ack, другой хост и другой провайдер #3482

Merged

lekss361 merged 1 commit from feat/3471-glitchtip-fallback-alert-ack into main

2026-09-12 11:08:27 +00:00

lekss361 commented

2026-09-12 11:04:34 +00:00

Owner

Пункт из #3471, раздел «Маршрутизация алертов». Владелец выбрал резервный канал через alert-ack.

Зачем

Все три alert-правила GlitchTip шлют в один URL — в продуктовый бэкенд на Selectel, то есть в тот самый сервис, за которым они следят. Упал бэкенд или Caddy — ошибки приложения задержатся или пропадут именно тогда, когда нужнее всего. Инфра-алерты эту дыру не закрывают, они про другое и идут своим путём.

alert-ack живёт на Beget, у другого провайдера, и путь оттуда до Telegram чистый: замер 12.09 дал 8 успешных соединений из 8, тогда как с Selectel теряется примерно каждый четвёртый запрос.

Что добавлено

POST /glitchtip на том же контейнере, что уже обслуживает /alertmanager и подтверждения.

Секрет принимается заголовком X-GlitchTip-Secret или параметром ?secret=. Второй путь — рабочий: GlitchTip 6.1.6 заголовков не шлёт вовсе. Подход скопирован с продуктового приёмника, где он уже обоснован в докстринге, а не изобретён заново.
Несконфигурированный секрет означает 503, а не тихий приём настежь. Неверный секрет — 401 через сравнение с постоянным временем.
Битый JSON, отсутствующие attachments, неожиданные типы полей сервис не роняют: рендер best-effort.
Сообщение уходит в тему клиентских инцидентов с баннером «резервный канал», чтобы человек сразу понимал, что основной путь, возможно, лёг. Кнопки подтверждения нет: это разовое уведомление, а не инцидент с жизненным циклом.

Тесты: 9 проверок, все проходят.

Что нужно сделать руками при выкатке

Новая переменная ALERT_ACK_GLITCHTIP_SECRET — произвольное значение, намеренно НЕ равное продуктовому TRADEIN_INTERNAL_AUTH_SECRET: это разные хосты и разные домены безопасности. Положить в тот же файл окружения на Beget, откуда alert-ack уже читает настройки Telegram, и добавить секретом в Forgejo Actions с пробросом в deploy-metrics.yml.

Маршрут в Caddy (caddy/sites/infra.caddy, домен metrics.gendsgn.ru, рядом с существующим handle /ack/*) — вынесен из этого PR, потому что файлы Caddy правит #3478:

handle /glitchtip* {
    reverse_proxy alert-ack:8080
}

Регистрация второго получателя в GlitchTip — после выкатки, URL вида https://metrics.gendsgn.ru/glitchtip?secret=<значение>. Сделаю через API.

Пункт из #3471, раздел «Маршрутизация алертов». Владелец выбрал резервный канал через alert-ack. ## Зачем Все три alert-правила GlitchTip шлют в один URL — в продуктовый бэкенд на Selectel, то есть в тот самый сервис, за которым они следят. Упал бэкенд или Caddy — ошибки приложения задержатся или пропадут именно тогда, когда нужнее всего. Инфра-алерты эту дыру не закрывают, они про другое и идут своим путём. `alert-ack` живёт на Beget, у другого провайдера, и путь оттуда до Telegram чистый: замер 12.09 дал 8 успешных соединений из 8, тогда как с Selectel теряется примерно каждый четвёртый запрос. ## Что добавлено `POST /glitchtip` на том же контейнере, что уже обслуживает `/alertmanager` и подтверждения. - Секрет принимается заголовком `X-GlitchTip-Secret` или параметром `?secret=`. Второй путь — рабочий: GlitchTip 6.1.6 заголовков не шлёт вовсе. Подход скопирован с продуктового приёмника, где он уже обоснован в докстринге, а не изобретён заново. - Несконфигурированный секрет означает 503, а не тихий приём настежь. Неверный секрет — 401 через сравнение с постоянным временем. - Битый JSON, отсутствующие `attachments`, неожиданные типы полей сервис не роняют: рендер best-effort. - Сообщение уходит в тему клиентских инцидентов с баннером «резервный канал», чтобы человек сразу понимал, что основной путь, возможно, лёг. Кнопки подтверждения нет: это разовое уведомление, а не инцидент с жизненным циклом. Тесты: 9 проверок, все проходят. ## Что нужно сделать руками при выкатке **Новая переменная `ALERT_ACK_GLITCHTIP_SECRET`** — произвольное значение, намеренно НЕ равное продуктовому `TRADEIN_INTERNAL_AUTH_SECRET`: это разные хосты и разные домены безопасности. Положить в тот же файл окружения на Beget, откуда alert-ack уже читает настройки Telegram, и добавить секретом в Forgejo Actions с пробросом в `deploy-metrics.yml`. **Маршрут в Caddy** (`caddy/sites/infra.caddy`, домен `metrics.gendsgn.ru`, рядом с существующим `handle /ack/*`) — вынесен из этого PR, потому что файлы Caddy правит #3478: ```caddyfile handle /glitchtip* { reverse_proxy alert-ack:8080 } ``` **Регистрация второго получателя в GlitchTip** — после выкатки, URL вида `https://metrics.gendsgn.ru/glitchtip?secret=<значение>`. Сделаю через API.

lekss361 added 1 commit 2026-09-12 11:04:35 +00:00

feat(ops): резервный получатель GlitchTip-алертов в alert-ack

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

Details

CI / changes (pull_request) Successful in 12s

Details

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

Details

CI Trade-In / browser-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

423842ae36

Все три alert-правила GlitchTip (backend, frontend, Trade-In) сейчас шлют
единственный вебхук в продуктовый бэкенд на Selectel — тот самый хост, за
которым они следят. Если там упал backend или Caddy, ошибки приложения
задерживаются или пропадают именно тогда, когда нужнее всего.

Добавлен POST /glitchtip в alert-ack (живёт на инфраструктурном хосте Beget,
не зависит от здоровья продукта): второй получатель того же Slack-совместимого
payload, аутентификация секретом в заголовке X-GlitchTip-Secret или query
?secret= (тот же подход, что у tradein-mvp/backend/app/api/v1/glitchtip.py).
Сообщение уходит в существующую тему клиентских инцидентов с явной пометкой
«резервный канал». Секрет свой (ALERT_ACK_GLITCHTIP_SECRET), не переиспользует
продуктовый TRADEIN_INTERNAL_AUTH_SECRET.

Refs #3471