Руководство по настройке оповещений
На этой странице:
- Как устроены оповещения
- Каналы оповещений
- Политики оповещений
- Правила алертинга
- Работа с правилами
- Что дальше
В этом руководстве описана настройка оповещений в веб-интерфейсе 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 — автоматическая генерация правил алертинга по бюджету ошибок.