Документация Proto Observability Platform – webhook

Alerting: Руководство по настройке оповещений

Mon, 01 Jan 0001 00:00:00 +0000

На этой странице:

Как устроены оповещения
Каналы оповещений
Политики оповещений
Правила алертинга
Работа с правилами
Что дальше

В этом руководстве описана настройка оповещений в веб-интерфейсе Proto Observability Platform: как создать каналы доставки, как направить алерты в нужные каналы с помощью политик и как создавать и сопровождать правила алертинга.

Концептуальное описание модуля алертинга (встроенные правила, SLO-алертинг, выявление аномалий) приведено в разделе Алертинг в Proto Observability Platform.

Как устроены оповещения

Оповещения складываются из трёх связанных сущностей. Их настраивают в разделе главного меню Алерты:

Сущность	Раздел меню	Назначение
Канал оповещения	`Алерты` > `Каналы`	Куда доставлять уведомления (email, Telegram, Webhook).
Политика оповещений	`Алерты` > `Политики`	Какие алерты в какой канал направлять (маршрутизация по лейблам).
Правило алертинга	`Алерты` > `Правила`	Что считать инцидентом (условие на языке PromQL/MetricsQL).

Данные движутся так: правило срабатывает по условию → политика сопоставляет лейблы алерта со своими матчерами и выбирает канал → канал доставляет уведомление получателю.

Рекомендуемый порядок настройки с нуля:

Создать каналы оповещений — адреса и реквизиты доставки.
Создать правила алертинга — условия срабатывания и лейблы.
Создать политики, которые свяжут лейблы правил с каналами.

Скриншот: пункт меню «Алерты» с подразделами «Каналы», «Политики», «Правила».

Применение изменений

Изменения в правилах и политиках вступают в силу не сразу: после редактирования нужно нажать кнопку «Применить». Новые настройки активируются в течение ~1 минуты.

Каналы оповещений

Канал оповещения определяет, куда и как доставляется уведомление. Поддерживаются три типа каналов: Электронная почта (email), Telegram и Webhook.

Список каналов

Откройте раздел Алерты > Каналы. На странице доступны поиск по названию, фильтр по типу канала и действия над каждым каналом (просмотр, редактирование, удаление).

Скриншот: список каналов с фильтром по типу и кнопкой «Добавить».

Создание канала

Нажмите «Добавить» и заполните форму. Часть полей общая для всех типов, остальные зависят от выбранного типа.

Общие поля:

Поле	Обязательное	Описание
Название	Да	Уникальное и описательное имя канала (до 64 символов). Допускаются латинские и кириллические буквы, цифры, дефис, подчёркивание и пробелы.
Тип	Да	Тип канала: `Электронная почта`, `Telegram` или `Webhook`. При смене типа поля, специфичные для типа, очищаются.
Комментарий	Нет	Произвольная заметка (до 500 символов): например, какая команда получает уведомления или для чего используется канал.
Отправлять завершённые?	Нет	Отправлять ли в канал уведомления о завершившихся (разрешившихся) алертах.
Отключить проверку SSL	Нет	Отключает проверку валидности SSL-сертификата сервера. Включайте только при использовании самоподписанного сертификата.

Канал «Электронная почта» (email)

Скриншот: форма создания канала типа «Электронная почта» с заполненными полями SMTP.

Поле	Обязательное	Описание
Кому	Да	Email-адрес получателя оповещений.
От кого	Да	Адрес отправителя (поле `from`).
SMTP сервер	Да	SMTP-сервер для отправки писем в формате `хост:порт`, например `smtp.example.com:587`.
Имя пользователя SMTP	Нет	Имя пользователя для SMTP-аутентификации.
Пароль SMTP	Нет	Пароль для SMTP-аутентификации (хранится в зашифрованном виде).
hello имя хоста	Нет	Имя хоста для идентификации на SMTP-сервере. По умолчанию `localhost`.
Требовать TLS	Нет	Требовать TLS для SMTP-соединения.

Канал «Telegram»

Скриншот: форма создания канала типа «Telegram».

Поле	Обязательное	Описание
Telegram ID	Да	Идентификатор чата (`chat_id`), куда бот отправляет сообщения. Целое число, может быть отрицательным.
Токен бота	Да	Токен Telegram-бота (хранится в зашифрованном виде).
API URL	Нет	URL API Telegram, по умолчанию `https://api.telegram.org`.
ID ветки сообщений	Нет	Идентификатор ветки (topic) для форумных групп Telegram.

Канал «Webhook»

Скриншот: форма создания канала типа «Webhook».

Поле	Обязательное	Описание
Webhook URL	Да	URL, на который отправляется HTTP POST с данными алерта. Должен начинаться с `http://` или `https://`.
Максимум алертов	Нет	Максимальное количество алертов в одном сообщении.
Таймаут	Нет	Максимальное время ожидания ответа от приёмника.

Редактирование и удаление каналов

Канал можно изменить или удалить из списка каналов. При редактировании тип канала изменить нельзя — он отображается заблокированным; для смены типа создайте новый канал.

Удаление используемого канала

Канал нельзя удалить, пока он используется хотя бы в одной политике оповещений. Сначала отвяжите канал от политик, затем удалите его.

Чувствительные поля

При редактировании канала секретные значения (пароли, токены) не показываются в открытом виде. Оставьте поле пустым, чтобы сохранить ранее заданное значение, или введите новое, чтобы заменить его.

Скриншот: форма редактирования канала — тип заблокирован, секретные поля (Пароль SMTP) пусты.

Политики оповещений

Политика (маршрут) определяет, какие алерты доставляются в какой канал. Политики сопоставляют лейблы входящего алерта со своими условиями (матчерами) и направляют совпавшие алерты в выбранный канал.

Список политик

Откройте раздел Алерты > Политики. Политики проверяются по возрастанию значения поля «Порядок» (приоритета) — сверху вниз. В списке видны матчеры, признак «Продолжение», привязанный канал и лейблы группировки каждой политики.

Скриншот: список политик с приоритетами и кнопкой «Добавить».

Создание политики

Нажмите «Добавить» и заполните форму.

Скриншот: форма создания политики с матчерами и выбором канала.

Поле	Обязательное	Описание
Лейблы группировки	Да	Лейблы, по которым входящие оповещения объединяются в одну группу (например, `alertname`, `cluster`, `service`). Несколько алертов с одинаковыми значениями этих лейблов придут одним сообщением. Чтобы отключить группировку, используйте специальный символ `...`.
Каналы оповещения	Да	Канал, в который направляются совпавшие алерты. Канал должен быть создан заранее (см. раздел «Каналы оповещений»).
Матчеры	Да (≥1)	Условия сопоставления лейблов алерта. Каждый матчер — это тройка «ключ — оператор — значение».
Продолжение	Нет	Применять ли последующие политики, если текущая совпала. `Выкл.` — обработка алерта останавливается на первой совпавшей политике. `Вкл.` — алерт обрабатывается и следующими политиками.
Порядок	Да	Приоритет проверки политики, от 1 до 100. Политики проверяются по возрастанию; на первой совпавшей обработка прекращается, если не включено «Продолжение».
Комментарий	Нет	Краткое описание политики или ссылка на регламент (до 500 символов).

Матчер состоит из трёх частей:

Часть	Описание
ключ	Имя лейбла алерта, например `severity`, `service`, `env`, `alertname`, `instance`, `job`.
оператор	`=` равно, `!=` не равно, `=~` совпадает с regex, `!~` не совпадает с regex.
значение	Значение для сравнения. Для операторов `=~` / `!~` — регулярное выражение.

Несколько матчеров в одной политике объединяются по «И»: алерт должен удовлетворять всем условиям.

Связь лейблов правил и политик

Политика маршрутизирует алерты по их лейблам. Лейблы задаются в правиле алертинга (поля Критичность и Лейблы). Например, чтобы политика ловила критичные алерты, добавьте матчер severity = CRITICAL.

Примеры матчеров

Цель	Матчер
Любой алерт (политика-перехватчик)	`alertname =~ .*`
Алерты определённого семейства по имени	`alertname =~ Аномалия.*`
Только сервисные алерты (APM)	`type = apm` (или `component_type = service`)
Алерты конкретного сервиса	`service = payment-service` (или `service =~ payment.*`)
Только критичные	`severity = CRITICAL`
Только инфраструктурные алерты	`type = infra`
Конкретная технология	`technology = postgres`
Всё, кроме предупреждений	`severity != WARNING`

Матчер alertname =~ .* совпадает с любым алертом — это удобно для политики-«перехватчика» по умолчанию. Разместите её последней (наибольшее значение поля «Порядок»), чтобы она ловила алерты, не подошедшие под более специфичные политики.

Типовые лейблы встроенных правил

Встроенные правила платформы несут стандартный набор лейблов — по ним удобно строить матчеры. Матчеры сопоставляются именно с лейблами, а не с аннотациями (summary, dashboard и т. п. для маршрутизации не используются).

Лейбл	Типовые значения	Описание
`alertname`	имя правила	Название сработавшего правила, например `Аномалия во времени отклика`.
`severity`	`CRITICAL`, `WARNING`	Критичность.
`type`	`apm`, `infra`, `licensing`	Категория правила: приложения/сервисы, инфраструктура, лицензирование.
`component_type`	`service`, `endpoint`, `application`, `db`, `host`, `k8s`, `container`, `queue`, `web_server`, `virtualization`	Тип объекта, к которому относится алерт.
`technology`	`postgres`, `mysql`, `mongodb`, `redis`, `memcached`, `kafka`, `nginx`, `httpd`, `php_fpm`, `elasticsearch`, `vsphere`, `k8s_node`, `k8s_ns`, `k8s_pod`, `k8s_deploy`, `k8s_daemon`, `k8s_stateful`	Конкретная технология (для инфраструктурных правил).
`rule_type`	`SLA`, `APDEX`, `anomaly_calls`, `anomaly_resptime`, `anomaly_errors`, `anomaly_errorperc`, `anomaly_duration`, `cpu`, `cpu_iowait`, `ram`, `error_endpoint`	Подтип правила.
`service`, `service_id`, `service_group`	из метрики	Сервис, к которому относится алерт (APM-правила).
`endpoint`, `opName`	из метрики	Эндпоинт/операция (правила по эндпоинтам и ключевым транзакциям).

Собственные правила несут лейбл severity (поле Критичность) и любые лейблы, добавленные в блоке Лейблы (см. Создание правила).

Применение политик

После создания или изменения политик нажмите «Применить», чтобы новая конфигурация маршрутизации вступила в силу.

Скриншот: подтверждение применения настроек политик.

Правила алертинга

Правило определяет условие, при котором генерируется алерт. Условие задаётся выражением на языке PromQL или MetricsQL.

Подробнее о доступных метриках, лейблах сервисов, синтаксисе выражений и аннотациях со ссылками на дашборды см. Метрики и выражения для правил.

Список правил

Откройте раздел Алерты > Правила. Доступны фильтры по типу (встроенные/пользовательские), по группе и по статусу (включено/отключено), а также поиск по названию.

Скриншот: список правил с фильтрами по типу, группе и статусу.

Встроенные правила

Из коробки доступно множество встроенных (системных) правил. Их нельзя редактировать и удалять, но можно отключить или создать копию и редактировать уже копию. Встроенные правила периодически обновляются вендором.

Создание правила

Нажмите «Добавить» и заполните форму.

Скриншот: форма создания правила с основными полями.

Поле	Обязательное	Описание
Название	Да	Короткое описание сути правила (до 64 символов). Отображается на дашбордах и в уведомлениях.
Группа	Да	Логическая группа правил. Имя группы отображается в дашборде реального времени и в уведомлениях. Можно выбрать существующую группу или ввести новую. Только латинские буквы, цифры и подчёркивание; без пробелов и кириллицы.
Критичность	Да	Уровень критичности: `CRITICAL` или `WARNING`. Сохраняется как лейбл `severity` (используется в политиках маршрутизации).
Описание	Да	Понятное описание сути правила (до 200 символов). Отображается в списке правил и в тексте получаемых алертов. Сохраняется как аннотация `summary`.
Выражение	Да	Условие правила на PromQL/MetricsQL (до 10 000 символов). Алерт срабатывает, когда выражение возвращает результат. Поле поддерживает подсветку синтаксиса.
for	Нет	Длительность, в течение которой условие должно выполняться, прежде чем алерт перейдёт в статус `firing` (формат: `30s`, `5m`, `1h`, `1d`, `1w`). До истечения этого времени алерт находится в статусе `pending`. Если не задано — алерт срабатывает сразу.
keep_firing_for	Нет	Длительность, в течение которой алерт остаётся в статусе `firing` после того, как условие перестало выполняться. Откладывает разрешение алерта. Формат как у `for`.
Лейблы	Нет	Дополнительные пары «ключ — значение», добавляемые к алерту. Используются для группировки и маршрутизации в политиках.
Аннотации	Нет	Дополнительные пары «ключ — значение» с метаданными алерта (приходят в текст уведомления). Зарезервированные ключи `dashboard`, `dashboardHost`, `dashboardContainer` формируют ссылки на дашборды — см. Метрики и выражения.
debug	Нет	Выводить ли отладочную информацию в логи (изменения состояния алертов и запросы к источнику данных).
Статус	—	Состояние правила: `включено` или `отключено`. Новое правило по умолчанию создаётся отключённым.

Предпросмотр выражения на графике

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

Скриншот: предпросмотр PromQL-выражения в виде линейного графика.

Лейблы и аннотации

Лейблы и аннотации задаются как пары «ключ — значение».

Скриншот: блоки «Лейблы» и «Аннотации» с добавленными парами.

Зарезервированные ключи

Ключ severity в лейблах и ключ summary в аннотациях зарезервированы. Изменяйте их через поля Критичность и Описание соответственно, а не вручную в блоках «Лейблы» / «Аннотации».

Применение правил

После добавления, изменения или отключения правил нажмите «Применить». Новые настройки вступят в силу в течение ~1 минуты.

Скриншот: подтверждение применения настроек правил.

Работа с правилами

Над каждым правилом в списке доступен набор действий.

Скриншот: меню действий правила — просмотр, редактирование, копия, отключение, удаление.

Действие	Описание	Применимо к
Просмотр	Открыть детали правила: выражение, лейблы, аннотации, статус.	Все правила
Редактирование	Изменить параметры правила в форме (как при создании).	Пользовательские правила
Создать копию	Создать редактируемую копию правила. Основной способ кастомизировать встроенное правило.	Все правила
Отключить / Включить	Перевести правило в статус `отключено` / `включено`. Отключённое правило не срабатывает.	Все правила
Удалить	Удалить правило без возможности восстановления.	Только пользовательские

Встроенные правила нельзя удалить

Встроенные (системные) правила удалить нельзя — их можно только отключить. Чтобы изменить логику встроенного правила, создайте его копию и отредактируйте копию.

После любого изменения (редактирование, отключение, удаление, добавление) не забудьте нажать «Применить» — иначе изменения не активируются.

Что дальше

Алертинг в Proto Observability Platform — обзор модуля, встроенные правила, SLO-алертинг и выявление аномалий.
Метрики и выражения для правил — метрики сервисов, синтаксис выражений, аннотации со ссылками на дашборды.
Управление SLO — автоматическая генерация правил алертинга по бюджету ошибок.

Alerting: Диагностика и формат уведомлений

Mon, 01 Jan 0001 00:00:00 +0000

На этой странице:

Жизненный цикл алерта
Почему уведомление не пришло
Что приходит в уведомление
- Telegram
- Email
- Webhook

Жизненный цикл алерта

Условие правила вычисляется постоянно. Алерт проходит через состояния:

Состояние	Что значит	Уведомление
pending	Условие выражения выполняется, но ещё не прошло время из поля `for`.	Не отправляется
firing	Условие держится дольше `for` — алерт считается сработавшим.	Отправляется по политикам
resolved	Условие перестало выполняться.	Отправляется, если у канала включено «Отправлять завершённые?» (`send_resolved`)

Поле keep_firing_for удерживает алерт в состоянии firing ещё заданное время после того, как условие перестало выполняться, — это откладывает разрешение и гасит «дребезг».

Когда изменения вступают в силу

После нажатия «Применить» изменения правил применяются в течение ~1 минуты, изменения политик — почти сразу. Без нажатия «Применить» новые настройки не активируются.

Почему уведомление не пришло

Проверьте по порядку:

Нажата ли «Применить». Правила вступают в силу за ~1 минуту, политики — почти сразу.
Правило включено (статус включено, а не отключено).
Алерт уже в firing, а не pending. Условие должно продержаться время из поля for. Текущее состояние видно в Алерты > Активные.
Есть политика с подходящими матчерами. Алерт маршрутизируется только если его лейблы совпадают с матчерами какой-либо политики (например, severity = WARNING). Без совпавшей политики уведомление не отправляется.
Канал привязан к политике, и его реквизиты верны (токен бота и Telegram ID, SMTP-сервер, URL вебхука).
Для уведомлений о разрешении проверьте «Отправлять завершённые?» (send_resolved) у канала — для email он по умолчанию выключен.
Нет активной тишины (silence), заглушающей этот алерт (см. Просмотр алертов → Активные).

Подробнее о создании каналов, правил и политик — Настройка оповещений.

Что приходит в уведомление

Текст уведомления формируется из лейблов и аннотаций алерта. Зарезервированные аннотации (summary, dashboard, dashboardHost, dashboardContainer) задают заголовок и ссылки на дашборды — см. Метрики и выражения → Аннотации со ссылками на дашборды. Отправку уведомлений о разрешении (resolved) включает поле «Отправлять завершённые?» у канала.

Сообщение в формате HTML:

заголовок: 🔥 + описание (summary) и эмодзи критичности (🟡 для WARNING, 🔴 для CRITICAL); для разрешённого алерта — ✅ Устранено: …;
Сервис / Хост / Контейнер — ссылками на соответствующие дашборды, если заданы аннотации dashboard*;
блоки Лейблы и Аннотации;
Начало, а для разрешённого алерта — Конец и Длительность.

По умолчанию для Telegram-каналов уведомления о разрешении включены.

Email

Тема: эмодзи статуса + имя алерта + число сработавших + критичность (и при наличии — сервис/хост/контейнер);
Тело (HTML): цветной баннер «Активно алертов: N» (или «Устранено алертов: N»), кнопки перехода к дашбордам и к разделам Активные/История, затем посекционно каждый алерт с лейблами, аннотациями, временем начала/конца и длительностью.

По умолчанию для email-каналов уведомления о разрешении выключены (включаются полем «Отправлять завершённые?»).

Webhook

На указанный URL отправляется HTTP POST со стандартным payload Alertmanager (версия 4). Используйте его для интеграции со сторонними системами (ITSM, чат-боты, автоматизация). Структура:

{
 "version": "4",
 "groupKey": "{}:{alertname=\"Высокая доля ошибок сервиса\"}",
 "truncatedAlerts": 0,
 "status": "firing",
 "receiver": "Webhook интеграции",
 "groupLabels": { "alertname": "Высокая доля ошибок сервиса" },
 "commonLabels": {
 "alertname": "Высокая доля ошибок сервиса",
 "severity": "WARNING",
 "service": "credit-bureau-service"
 },
 "commonAnnotations": { "summary": "Доля ошибок сервиса выше 5% в течение 5 минут" },
 "externalURL": "https://<адрес-вашей-платформы>",
 "alerts": [
 {
 "status": "firing",
 "labels": {
 "alertname": "Высокая доля ошибок сервиса",
 "severity": "WARNING",
 "service": "credit-bureau-service",
 "service_id": "..."
 },
 "annotations": { "summary": "Доля ошибок сервиса выше 5% в течение 5 минут" },
 "startsAt": "2026-06-10T12:00:00.000Z",
 "endsAt": "0001-01-01T00:00:00Z",
 "generatorURL": "http://.../vmalert/...",
 "fingerprint": "a1b2c3d4e5f6a7b8"
 }
 ]
}

Поля каждого элемента alerts[]: status (firing/resolved), labels, annotations, startsAt, endsAt (для firing — нулевая дата), generatorURL, fingerprint. Для разрешённого алерта status становится resolved, а endsAt заполняется (при включённом «Отправлять завершённые?»).