Обзор

Если вы уже работали с другой on-call-системой, прочитайте секцию про неё: там собраны различия в модели и терминах, без оценок «лучше» или «хуже».

Если вы из OpsGenie

• Приоритет и важность. В OpsGenie пять фиксированных приоритетов (P1–P5), которые проставляются на алерте или меняются через alert policies. У нас два уровня важности, critical и warning, и интеграция вычисляет их из лейблов через severity mapping.

• Маршрутизация. В OpsGenie у команды есть Routing Rules с условиями по тегам, источнику и тексту, срабатывает первое подходящее. У нас маршрут фиксирован: интеграция задаёт команду и политику эскалации. Условная обработка вынесена в политики с небольшим набором условий и действий, без регулярных выражений и шаблонов.

• Unacknowledge. В OpsGenie снятие подтверждения запускает уведомления заново с первого шага, а исчерпанная политика может повторяться. У нас эскалация продолжается со шага, следующего за тем, на котором алерт подтвердили. Дойдя до конца цепочки, алерт остаётся в firing без повторов (подробнее о жизненном цикле).

• Notification Policies. В OpsGenie это отдельная сущность команды с действиями suppress, delay, auto-restart и auto-close. У нас подавление и задержку делают политики, временную тишину на работы сайленсы, а автоматического закрытия по таймеру нет.

Если вы из Grafana OnCall

• Маршрутизация. В Grafana OnCall маршрут выбирают Jinja2-шаблоны, возвращающие True или False для каждого route. У нас шаблонов нет: интеграция задаёт команду и политику эскалации, а условная обработка идёт через политики с условиями по лейблам (=, !=, exists, absent), важности и времени.

• Группировка. В Grafana OnCall группу вычисляет Jinja2-шаблон на интеграции. У нас группировка плоская: один батч AlertManager становится одним алертом, а состав батча задаёт group_by в самом AlertManager (подробнее о батчах).

• Важность. В Grafana OnCall явной модели уровней нет: severity приходит в лейблах и используется в шаблонах маршрутизации или флаге Important. У нас два явных уровня, critical и warning, которые настраиваются маппингом на интеграции.

• Настойчивость эскалации. В Grafana OnCall агрессивные уведомления включаются флагом Important на шаге и отдельным набором личных правил. У нас всё решает важность: critical проходит все шаги автоматически, а по warning оповещается только первый (подробнее об эскалации). Личные правила уведомлений задаются отдельно для каждой важности.

Если вы из PagerDuty

• Priority и Urgency. В PagerDuty два независимых измерения: пять настраиваемых уровней Priority и отдельная Urgency (high, low, dynamic), которая задаёт агрессивность уведомлений. У нас одно измерение, важность (critical или warning), и оно определяет сразу и значимость алерта, и ход эскалации.

• Service. В PagerDuty маршрут строится вокруг Service: Events API принимает routing_key конкретного сервиса и политика эскалации назначена на него. У нас сервиса нет, его роль играет интеграция: её API-ключ определяет команду и политику эскалации.

• Условная обработка. В PagerDuty это Event Orchestration: три уровня (Global, Router, Service) и собственный язык условий PCL. У нас это политики без своего языка: условия по лейблам, важности и времени и одно из пяти действий (Drop, Suppress, Hold outside window, Override severity, Add labels). Сложная обработка собирается из нескольких политик, поставленных по порядку.

• Группировка. В PagerDuty есть группировка на машинном обучении (Intelligent Alert Grouping) и по правилам (Time-Based, Content-Based), частично в дополнении AIOps. У нас группировка плоская, без машинного обучения: один батч AlertManager становится одним алертом.