Отправка алертов из Prometheus на вебхук
Чтобы получать алерты Prometheus в Telegram, на Email, в Пачке или в Depesher Desktop через Депешер, настройте webhook receiver в Alertmanager. Prometheus проверяет правила и передаёт алерты Alertmanager, а тот отправляет HTTP POST с JSON на адрес входящего канала Депешера. Эта схема описана в обзоре уведомлений Prometheus.
text
Правило Prometheus → Alertmanager → Вебхук Депешера → Telegram / Email / Пачка / Depesher DesktopНиже используются обычные файлы конфигурации уже установленных Prometheus и Alertmanager. Адреса и пути замените своими; для контейнеров они должны быть доступны из соответствующего контейнера.
Подготовьте каналы Депешера
- Создайте и подтвердите нужные исходящие каналы.
- Создайте входящий канал, например «Prometheus».
- Свяжите его с подготовленными получателями и скопируйте публичный URL вида
https://depesher.ru/w/ВАШ_PUBLIC_ID. - Проверьте доставку по инструкции «Первое уведомление».
Депешер принимает application/json. Без шаблона получатель увидит исходное тело; ниже настроим его оформление. Рабочий URL и токен канала не публикуйте в репозитории.
Настройте получателя в Alertmanager
Минимальный alertmanager.yml для отправки всех алертов в Депешер:
yaml
route:
receiver: depesher
group_by: [alertname, job]
group_wait: 30s
group_interval: 5m
repeat_interval: 4h
receivers:
- name: depesher
webhook_configs:
- url: "https://depesher.ru/w/ВАШ_PUBLIC_ID"
send_resolved: trueЕсли Alertmanager уже обслуживает другие уведомления, добавьте receiver depesher в существующий список и направьте к нему нужный маршрут; целиком заменять рабочую конфигурацию этим примером не нужно.
group_by объединяет алерты по имени и заданию. group_wait задаёт ожидание первой отправки, group_interval — интервал проверки изменений группы, repeat_interval — повтор неизменившегося уведомления. send_resolved: true включает уведомления о восстановлении. Формат POST-запроса задаёт стандартный webhook receiver Alertmanager.
Если канал Депешера защищён токеном, дополните элемент webhook_configs:
yaml
receivers:
- name: depesher
webhook_configs:
- url: "https://depesher.ru/w/ВАШ_PUBLIC_ID"
send_resolved: true
http_config:
authorization:
type: Bearer
credentials_file: /etc/alertmanager/secrets/depesher-tokenФайл должен содержать только токен, без префикса Bearer, и быть доступен процессу Alertmanager. Заголовок Authorization сформирует настройка HTTP-клиента. Для канала без токена блок http_config не нужен.
Подключите Prometheus к Alertmanager
В prometheus.yml добавьте файл правил и адрес Alertmanager. Существующие scrape_configs сохраните; если rule_files или alerting уже есть, дополните их:
yaml
rule_files:
- /etc/prometheus/depesher-alerts.yml
alerting:
alertmanagers:
- static_configs:
- targets:
- "alertmanager:9093"Здесь alertmanager:9093 — пример сетевого адреса Alertmanager, доступного из Prometheus. URL Депешера указывается только в webhook_configs Alertmanager. Подробнее — в конфигурации Prometheus.
Создайте /etc/prometheus/depesher-alerts.yml с правилом недоступности наблюдаемого объекта:
yaml
groups:
- name: depesher-alerts
rules:
- alert: InstanceDown
expr: up == 0
for: 2m
labels:
severity: critical
annotations:
summary: "Не удаётся собрать метрики с {{ $labels.instance }}"
description: "Задание {{ $labels.job }}: сбор метрик неуспешен более двух минут."Правило относится к объектам, которые Prometheus уже опрашивает. up == 0 означает неуспешный сбор метрик: причиной может быть как сам сервис, так и сеть или exporter. for: 2m требует, чтобы условие сохранялось две минуты; до этого алерт находится в состоянии pending. Подстановки $labels вычисляет Prometheus в аннотациях правила.
Оформите JSON шаблоном Депешера
Создайте шаблон в формате «Обычный текст» и привяжите его к входящему каналу:
text
Prometheus: {{json.status}}
Алерт: {{json.commonLabels.alertname}}
Задание: {{json.commonLabels.job}}
События:
{{json.alerts}}Такой шаблон использует поддерживаемые Депешером пути в JSON. Массив alerts вставляется целиком компактным JSON, поэтому текст содержит все полученные события группы.
Для короткого уведомления о первом событии можно использовать:
text
Prometheus: {{json.status}}
Первое событие: {{json.alerts.0.annotations.summary}}
Описание: {{json.alerts.0.annotations.description}}
Объект: {{json.alerts.0.labels.instance}}
Статус первого события: {{json.alerts.0.status}}Этот вариант показывает только элемент с индексом 0. Для группы из нескольких алертов используйте первый шаблон или добавьте в короткий вариант {{json.alerts}}.
В стандартном JSON commonLabels содержит общие метки группы; индивидуальные метки и аннотации находятся в alerts. Групповой status равен firing, пока хотя бы один алерт активен, и resolved, когда все разрешены. Структура данных описана в справочнике уведомлений Alertmanager. Отсутствующее поле Депешер заменяет пустой строкой. Обычный текст позволяет избежать влияния символов из меток на Markdown-разметку.
Проверьте всю цепочку
Проверьте конфигурации утилитами из установленных Prometheus и Alertmanager:
bash
promtool check rules /etc/prometheus/depesher-alerts.yml
promtool check config /etc/prometheus/prometheus.yml
amtool check-config /etc/alertmanager/alertmanager.ymlПримените изменения перезапуском соответствующих служб или штатной перезагрузкой конфигурации. Для Prometheus перезагрузка через HTTP требует включённого --web.enable-lifecycle; также поддерживается SIGHUP. См. загрузку конфигурации Prometheus и Alertmanager.
Чтобы проверить отправку без остановки сервиса, временно добавьте в список rules того же файла:
yaml
- alert: DepesherWebhookTest
expr: vector(1)
for: 1m
labels:
severity: info
job: depesher-test
annotations:
summary: "Проверка вебхука Депешера"
description: "Тестовое правило Prometheus, можно удалить после проверки."После проверки файла и перезагрузки Prometheus:
- Найдите
DepesherWebhookTestна странице Alerts в Prometheus. Дождитесь перехода изpendingвfiring. - Убедитесь, что алерт появился в Alertmanager. Отправка учитывает интервал вычисления правил и
group_wait, поэтому она не мгновенная. - Откройте историю входящего канала Депешера и проверьте JSON, затем сообщение у получателя.
- Для проверки восстановления замените тестовое выражение на
vector(1) == 0и перезагрузите правила. После обработки изменения группы ожидайте уведомлениеresolved. - Удалите тестовое правило и снова примените конфигурацию.
Если уведомление не пришло
- Нет алерта в Prometheus: проверьте загрузку файла правил, результат выражения и время
for. - Нет алерта в Alertmanager: проверьте адрес в
alerting.alertmanagersи доступность Alertmanager из Prometheus. - Алерт есть, POST не приходит: проверьте маршрут к receiver
depesher, silences, inhibition и интервалы группировки. Посмотрите ошибки отправки в логах Alertmanager. - Вебхук отклоняет запрос: сверьте URL и Bearer-токен. HTTP 413 может означать превышение лимита JSON Депешера в 1 048 576 байт; уменьшите размер групп.
max_alertsв Alertmanager обрезает список, а не разбивает его на отдельные сообщения. - Запрос есть в истории, сообщения у получателя нет: проверьте подтверждение и привязку исходящего канала по инструкции диагностики доставки.
История Депешера помогает отделить приём вебхука от доставки в выбранный канал. Состояние самого инцидента проверяйте в Prometheus и Alertmanager.
Критичные алерты и восстановление для команды
Создайте канал организации, команды «Эксплуатация» и «Диспетчеры». Оставьте базовых получателей пустыми: команды разных веток назначим через правила. Добавьте метки prometheus, авария, восстановление, неизвестное.
Чтобы commonLabels.severity действительно было общим полем группы, дополните существующий group_by в Alertmanager меткой severity:
yaml
route:
receiver: depesher
group_by: ["alertname", "job", "severity"]Сохраните остальные интервалы и настройки receiver из примера выше. Общие метки и массив alerts определяет структура webhook Alertmanager.
Подключите следующие правила в организации, режим «Все условия», строковые JSON-сравнения. Шаблон с полным {{json.alerts}} наследуется:
| Порядок | Условия | Важность / метки | Получатели |
|---|---|---|---|
| 1 | status = resolved | Информация; prometheus, восстановление | «Эксплуатация» |
| 2 | status = firing, commonLabels.severity = critical | Критично; prometheus, авария | «Эксплуатация» |
| Default | Без условий | Предупреждение; prometheus, неизвестное | «Диспетчеры» |
После подключения правил сотрудники обеих команд настраивают «Мою доставку». Отключённые источники тоже позволяют настроить её заранее; перед проверкой сообщений включите определения и подключения. Правило и default добавляют цели к базе, поэтому не назначайте обе команды базово, если им нужны разные события. Общая настройка — JSON-рецепт.
Синтетический JSON для проверки, не замена настоящего вебхука:
json
{
"status": "firing",
"commonLabels": {
"alertname": "InstanceDown",
"job": "api",
"severity": "critical"
},
"alerts": [
{
"status": "firing",
"labels": { "instance": "web-01", "severity": "critical" },
"annotations": { "summary": "API недоступен" }
}
]
}В симуляции ожидайте правило №2 и эксплуатацию. При замене группового status на resolved ожидайте №1 с важностью «Информация»; для согласованного теста измените и статус элемента alerts. Без commonLabels.severity активная группа попадёт в default.
Затем отправьте примеры по HTTP и проверьте назначения/доставку, после чего повторите с реальным тестовым алертом Alertmanager. В первом уведомлении должны быть firing, InstanceDown, api и JSON события web-01; в восстановлении — resolved.
Депешер выбирает маршрут целого запроса, а не каждого элемента alerts. Для групп с разными получателями измените группировку/маршруты Alertmanager или разделите события внешним адаптером. Метки Prometheus внутри JSON не создают автоматически метки каталога Депешера. Повторы и групповые состояния остаются ответственностью Alertmanager.