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

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

• Как устроены оповещения
• Каналы оповещений
  • Список каналов
  • Создание канала
    • Формат запроса канала «Webhook»
  • Редактирование и удаление каналов
• Политики оповещений
  • Список политик
  • Создание политики
  • Применение политик
• Правила алертинга
  • Список правил
  • Создание правила
  • Применение правил
• Работа с правилами
• Что дальше

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Общие поля:

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

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

Проверка настроек — тестовое письмо

В форме канала есть кнопка «Отправить тестовое письмо»: параметры почтового сервера проверяются сразу при настройке, а не в момент первого реального алерта.

Что важно знать о проверке:

• Тестовое письмо проверяет только транспорт SMTP. Чтобы оповещения действительно доходили, канал должен быть привязан к политике, а политика — применена.
• При ошибке сообщение указывает, на каком этапе всё сломалось — соединение с сервером, TLS, аутентификация или отправка, — поэтому не приходится гадать между «неверный пароль» и «закрыт порт».
• Если «Требовать TLS» выключено, выводится предупреждение: соединение не шифруется, и при аутентификации LOGIN пароль SMTP уйдёт открытым текстом. Включите TLS, если сервер это поддерживает.
• Проверка ограничена по частоте: при слишком частых нажатиях интерфейс предложит повторить через несколько секунд.

Канал «Telegram»

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

Канал «MAX»

Уведомления доставляются в групповой чат или канал мессенджера MAX от имени бота.

Как получить реквизиты:

1. Создайте бота в приложении MAX через системного бота для создания ботов и сохраните выданный токен.

2. Добавьте бота в целевой чат (в канал — с правами администратора). Пока бот не состоит в чате, MAX отвечает на отправку ошибкой Chat not found, даже если идентификатор чата указан верно.

3. Узнайте идентификатор чата. Запросите список чатов бота, подставив токен:

   curl -s -H "Authorization: <ТОКЕН_БОТА>" "https://platform-api.max.ru/chats"
   

   В ответе у нужного чата возьмите значение поля chat_id.

После сохранения откройте карточку канала из списка (действие «просмотр»): рядом с кнопками «Изменить» и «Удалить» есть кнопка «Отправить тестовое сообщение». Платформа отправляет в чат синтетический алерт, и ошибка (неверный токен, бот не добавлен в чат) видна сразу. В формах создания и редактирования этой кнопки нет: проверка выполняется по сохранённым реквизитам канала. Проверяется только доставка в чат: чтобы оповещения действительно доходили, канал должен быть привязан к политике, а политика — применена.

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

Канал «Webhook»

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

Формат запроса

Сведения ниже нужны, если вы разрабатываете собственный приёмник оповещений: ITSM-коннектор, чат-бот, скрипт автоматизации. Формат совместим с webhook-форматом Alertmanager версии 4, поэтому подойдут и готовые библиотеки для его разбора.

HTTP-запрос. Платформа отправляет POST на указанный URL с заголовками Content-Type: application/json и User-Agent: Alertmanager/0.28.0. Заголовков авторизации нет: если приёмник открыт в сеть, ограничьте доступ к нему на сетевом уровне или секретом в пути URL. Тело — один JSON-объект на группу алертов.

Ответ приёмника. Ответ 2xx считается успешной доставкой, тело ответа не читается. На ответ 5xx и на сетевые ошибки (таймаут, отказ соединения) платформа повторяет отправку с нарастающей паузой. Ответ 4xx считается окончательной ошибкой: сообщение не будет отправлено повторно. Отвечайте 2xx сразу после приёма, а обработку выполняйте асинхронно.

Группировка и повторные сообщения. В одном сообщении приходят все алерты группы — алерты с одинаковыми значениями лейблов группировки политики (см. Создание политики). Первое сообщение группы отправляется примерно через 10 секунд после срабатывания. Если состав группы меняется (сработал ещё один алерт или какой-то разрешился), новое сообщение придёт не раньше чем через 5 минут и снова будет содержать все алерты группы, включая уже отправленные. Если ничего не меняется, сообщение по активной группе повторяется раз в 4 часа. Поэтому приёмник должен быть идемпотентным: один и тот же алерт придёт несколько раз.

Поля верхнего уровня:

Поля алерта (alerts[]):

Примеры. Ниже — реальные сообщения, снятые с платформы версии 203 для встроенного правила «CPU: Использование > 90%» (группа OS_LINUX) и политики с лейблом группировки alertname. Правило сработало на двух хостах, затем хосты по очереди восстановились — пришло три сообщения.

Сообщение 1. Сработали оба хоста:

{
    "receiver": "webhook-test",
    "status": "firing",
    "alerts": [
        {
            "status": "firing",
            "labels": {
                "alertgroup": "OS_LINUX",
                "alertname": "CPU: Использование > 90%",
                "component_type": "host",
                "host": "app-server-01",
                "rule_group": "OS_LINUX",
                "rule_id": "6f1c2a1e-4b7d-4c1a-9a51-2f0e3d8b7c11",
                "rule_type": "cpu",
                "service_id_host": "YXBwLXNlcnZlci0wMQ==.1",
                "severity": "WARNING",
                "type": "infra"
            },
            "annotations": {
                "dashboardHost": "https://obp.example.local/dashboard/OS_LINUX/Service/YXBwLXNlcnZlci0wMQ==.1/Proto-Linux-Service",
                "summary": "Использование CPU > 90%",
                "value": "96.5"
            },
            "startsAt": "2026-10-06T08:11:50Z",
            "endsAt": "0001-01-01T00:00:00Z",
            "generatorURL": "https://obp.example.local/vmalert/alert?group_id=6667729631414967694&alert_id=14586754786845147920",
            "fingerprint": "200d0b8aee1248c2"
        },
        {
            "status": "firing",
            "labels": {
                "alertgroup": "OS_LINUX",
                "alertname": "CPU: Использование > 90%",
                "component_type": "host",
                "host": "db-server-02",
                "rule_group": "OS_LINUX",
                "rule_id": "6f1c2a1e-4b7d-4c1a-9a51-2f0e3d8b7c11",
                "rule_type": "cpu",
                "service_id_host": "ZGItc2VydmVyLTAy.1",
                "severity": "WARNING",
                "type": "infra"
            },
            "annotations": {
                "dashboardHost": "https://obp.example.local/dashboard/OS_LINUX/Service/ZGItc2VydmVyLTAy.1/Proto-Linux-Service",
                "summary": "Использование CPU > 90%",
                "value": "93.8"
            },
            "startsAt": "2026-10-06T08:11:50Z",
            "endsAt": "0001-01-01T00:00:00Z",
            "generatorURL": "https://obp.example.local/vmalert/alert?group_id=6667729631414967694&alert_id=6171399778922918722",
            "fingerprint": "da220678177e40b8"
        }
    ],
    "groupLabels": {
        "alertname": "CPU: Использование > 90%"
    },
    "commonLabels": {
        "alertgroup": "OS_LINUX",
        "alertname": "CPU: Использование > 90%",
        "component_type": "host",
        "rule_group": "OS_LINUX",
        "rule_id": "6f1c2a1e-4b7d-4c1a-9a51-2f0e3d8b7c11",
        "rule_type": "cpu",
        "severity": "WARNING",
        "type": "infra"
    },
    "commonAnnotations": {
        "summary": "Использование CPU > 90%"
    },
    "externalURL": "http://43a7a7047b92:9093",
    "version": "4",
    "groupKey": "{}/{severity=~\"WARNING|CRITICAL\"}:{alertname=\"CPU: Использование > 90%\"}",
    "truncatedAlerts": 0
}

{
    "receiver": "webhook-test",
    "status": "firing",
    "alerts": [
        {
            "status": "resolved",
            "labels": {
                "alertgroup": "OS_LINUX",
                "alertname": "CPU: Использование > 90%",
                "component_type": "host",
                "host": "app-server-01",
                "rule_group": "OS_LINUX",
                "rule_id": "6f1c2a1e-4b7d-4c1a-9a51-2f0e3d8b7c11",
                "rule_type": "cpu",
                "service_id_host": "YXBwLXNlcnZlci0wMQ==.1",
                "severity": "WARNING",
                "type": "infra"
            },
            "annotations": {
                "dashboardHost": "https://obp.example.local/dashboard/OS_LINUX/Service/YXBwLXNlcnZlci0wMQ==.1/Proto-Linux-Service",
                "summary": "Использование CPU > 90%",
                "value": "96.5"
            },
            "startsAt": "2026-10-06T08:11:50Z",
            "endsAt": "2026-10-06T08:12:40Z",
            "generatorURL": "https://obp.example.local/vmalert/alert?group_id=6667729631414967694&alert_id=14586754786845147920",
            "fingerprint": "200d0b8aee1248c2"
        },
        {
            "status": "firing",
            "labels": {
                "alertgroup": "OS_LINUX",
                "alertname": "CPU: Использование > 90%",
                "component_type": "host",
                "host": "db-server-02",
                "rule_group": "OS_LINUX",
                "rule_id": "6f1c2a1e-4b7d-4c1a-9a51-2f0e3d8b7c11",
                "rule_type": "cpu",
                "service_id_host": "ZGItc2VydmVyLTAy.1",
                "severity": "WARNING",
                "type": "infra"
            },
            "annotations": {
                "dashboardHost": "https://obp.example.local/dashboard/OS_LINUX/Service/ZGItc2VydmVyLTAy.1/Proto-Linux-Service",
                "summary": "Использование CPU > 90%",
                "value": "93.8"
            },
            "startsAt": "2026-10-06T08:11:50Z",
            "endsAt": "0001-01-01T00:00:00Z",
            "generatorURL": "https://obp.example.local/vmalert/alert?group_id=6667729631414967694&alert_id=6171399778922918722",
            "fingerprint": "da220678177e40b8"
        }
    ],
    "groupLabels": {
        "alertname": "CPU: Использование > 90%"
    },
    "commonLabels": {
        "alertgroup": "OS_LINUX",
        "alertname": "CPU: Использование > 90%",
        "component_type": "host",
        "rule_group": "OS_LINUX",
        "rule_id": "6f1c2a1e-4b7d-4c1a-9a51-2f0e3d8b7c11",
        "rule_type": "cpu",
        "severity": "WARNING",
        "type": "infra"
    },
    "commonAnnotations": {
        "summary": "Использование CPU > 90%"
    },
    "externalURL": "http://43a7a7047b92:9093",
    "version": "4",
    "groupKey": "{}/{severity=~\"WARNING|CRITICAL\"}:{alertname=\"CPU: Использование > 90%\"}",
    "truncatedAlerts": 0
}

{
    "receiver": "webhook-test",
    "status": "resolved",
    "alerts": [
        {
            "status": "resolved",
            "labels": {
                "alertgroup": "OS_LINUX",
                "alertname": "CPU: Использование > 90%",
                "component_type": "host",
                "host": "app-server-01",
                "rule_group": "OS_LINUX",
                "rule_id": "6f1c2a1e-4b7d-4c1a-9a51-2f0e3d8b7c11",
                "rule_type": "cpu",
                "service_id_host": "YXBwLXNlcnZlci0wMQ==.1",
                "severity": "WARNING",
                "type": "infra"
            },
            "annotations": {
                "dashboardHost": "https://obp.example.local/dashboard/OS_LINUX/Service/YXBwLXNlcnZlci0wMQ==.1/Proto-Linux-Service",
                "summary": "Использование CPU > 90%",
                "value": "96.5"
            },
            "startsAt": "2026-10-06T08:11:50Z",
            "endsAt": "2026-10-06T08:12:40Z",
            "generatorURL": "https://obp.example.local/vmalert/alert?group_id=6667729631414967694&alert_id=14586754786845147920",
            "fingerprint": "200d0b8aee1248c2"
        },
        {
            "status": "resolved",
            "labels": {
                "alertgroup": "OS_LINUX",
                "alertname": "CPU: Использование > 90%",
                "component_type": "host",
                "host": "db-server-02",
                "rule_group": "OS_LINUX",
                "rule_id": "6f1c2a1e-4b7d-4c1a-9a51-2f0e3d8b7c11",
                "rule_type": "cpu",
                "service_id_host": "ZGItc2VydmVyLTAy.1",
                "severity": "WARNING",
                "type": "infra"
            },
            "annotations": {
                "dashboardHost": "https://obp.example.local/dashboard/OS_LINUX/Service/ZGItc2VydmVyLTAy.1/Proto-Linux-Service",
                "summary": "Использование CPU > 90%",
                "value": "93.8"
            },
            "startsAt": "2026-10-06T08:11:50Z",
            "endsAt": "2026-10-06T08:17:30Z",
            "generatorURL": "https://obp.example.local/vmalert/alert?group_id=6667729631414967694&alert_id=6171399778922918722",
            "fingerprint": "da220678177e40b8"
        }
    ],
    "groupLabels": {
        "alertname": "CPU: Использование > 90%"
    },
    "commonLabels": {
        "alertgroup": "OS_LINUX",
        "alertname": "CPU: Использование > 90%",
        "component_type": "host",
        "rule_group": "OS_LINUX",
        "rule_id": "6f1c2a1e-4b7d-4c1a-9a51-2f0e3d8b7c11",
        "rule_type": "cpu",
        "severity": "WARNING",
        "type": "infra"
    },
    "commonAnnotations": {
        "summary": "Использование CPU > 90%"
    },
    "externalURL": "http://43a7a7047b92:9093",
    "version": "4",
    "groupKey": "{}/{severity=~\"WARNING|CRITICAL\"}:{alertname=\"CPU: Использование > 90%\"}",
    "truncatedAlerts": 0
}

Чтобы проверить приёмник без ожидания реального срабатывания, отправьте ему сообщение 1 из примера выше:

curl -i -X POST -H 'Content-Type: application/json' --data @firing.json https://receiver.example.local/hook

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что дальше

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