IncidentRelay
Документация

Корреляция алертов с учётом зависимостей

Версия v2.3.1 · Обновлено
Интерактивная версия Открыть на GitHub

title: Корреляция алертов с учётом зависимостей description: Как IncidentRelay использует зависимости сервисов, чтобы показать возможные первопричины и влияние на нижестоящие компоненты для связанных групп алертов.

Корреляция алертов с учётом зависимостей#

Корреляция алертов с учётом зависимостей помогает ответственным (responders) понять, может ли алерт быть связан с другим активным алертом в графе зависимостей сервисов.

Она не подавляет уведомления и не объединяет группы алертов автоматически.

Каждая группа алертов по-прежнему проходит обычный поток уведомлений. Корреляция лишь добавляет контекст:

возможная первопричина возможное влияние на нижестоящие компоненты оценка корреляции ссылки на связанные группы алертов события таймлайна

Как это работает#

Корреляция использует существующие зависимости сервисов.

Пример графа зависимостей:

Frontend -> Billing API -> PostgreSQL

Если у PostgreSQL есть активный критический алерт, а Billing API начинает срабатывать вскоре после этого, IncidentRelay может пометить группу алертов Billing API как возможный симптом.

Пример:

PostgreSQL unavailable -> Billing API 5xx

Для группы алертов Billing API:

Role: possible_symptom Possible root cause: PostgreSQL unavailable

Для группы алертов PostgreSQL:

Role: possible_root_cause Possible downstream impact: Billing API 5xx

Что сохраняется#

IncidentRelay сохраняет записи корреляции между группами алертов.

Сохранённая корреляция содержит:

корневую группу алертов связанную группу алертов корневой сервис связанный сервис зависимость тип связи направление оценку глубину причину флаг активности метки времени

Сохранённая запись используется в деталях алерта, при формировании уведомлений и в событиях таймлайна.

Типы связей#

possible_root_cause

Текущая группа алертов может быть симптомом вышестоящего алерта.

Пример:

Auth API зависит от PostgreSQL. PostgreSQL срабатывает (firing). Auth API начинает срабатывать. Auth API показывает PostgreSQL как возможную первопричину.

possible_downstream_impact

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

Пример:

PostgreSQL срабатывает (firing). Auth API зависит от PostgreSQL и тоже срабатывает. PostgreSQL показывает Auth API как возможное влияние на нижестоящие компоненты.

Активные группы алертов#

Корреляция использует только активные группы алертов.

Активные статусы:

firing acknowledged

Разрешённые (resolved) группы алертов не считаются активными. Когда группа алертов разрешается, её активные корреляции деактивируются, а в таймлайн записывается событие.

Настройки зависимости#

Каждая зависимость сервиса может управлять тем, участвует ли она в корреляции алертов.

Поля:

correlation_enabled propagation_delay_seconds

correlation_enabled включает или отключает корреляцию алертов для одной зависимости.

propagation_delay_seconds определяет, насколько далеко друг от друга могут появляться связанные алерты, чтобы всё ещё считаться вероятно связанными. Значение по умолчанию — 300 секунд.

Пример:

Billing API depends on PostgreSQL correlation_enabled = true propagation_delay_seconds = 300

Это означает, что алерт на PostgreSQL и алерт на Billing API с большей вероятностью будут скоррелированы, если появляются в пределах примерно пяти минут.

Оценка#

Оценка — это значение уверенности в диапазоне 0..100.

Оценка учитывает:

направление зависимости глубину зависимости тип зависимости критичность окружение сервиса время срабатывания алертов важность (severity)

Более высокая оценка означает, что связь с большей вероятностью будет полезна ответственному.

Оценка — не гарантия. Это контекст для расследования.

Глубина#

Корреляция может проходить по цепочкам зависимостей.

Пример:

Frontend -> Billing API -> PostgreSQL

Если PostgreSQL срабатывает и Frontend начинает срабатывать, IncidentRelay может создать корреляцию с двумя переходами:

PostgreSQL unavailable -> Frontend 5xx depth = 2

При наличии нескольких путей предпочтение отдаётся более коротким.

Уведомления#

Корреляцию можно включать в сообщения уведомлений.

Поддерживаемые видимые поверхности:

Slack Mattermost Telegram Email Универсальный вебхук Microsoft Teams Discord Шаблоны голосовых вызовов

Браузерные push-уведомления по умолчанию не содержат подробного блока корреляции. Push-уведомления должны оставаться короткими и вести на детали алерта, где корреляцию удобнее читать.

Детали алерта#

Детали алерта могут показывать:

возможные первопричины возможные влияния на нижестоящие компоненты связанную группу алертов оценку тип зависимости критичность глубину причину

Список алертов также может показывать компактные бейджи, например:

Symptom Root cause Correlated 2

События таймлайна#

Изменения жизненного цикла корреляции записываются в таймлайн группы алертов.

Примеры:

Correlation detected: #10 PostgreSQL: PostgreSQL unavailable -> #11 Auth API: Auth API 5xx Correlation deactivated: #10 PostgreSQL: PostgreSQL unavailable -> #11 Auth API: Auth API 5xx

События записываются в обе связанные группы алертов, чтобы ответственные видели связь с любой из сторон.

Чего корреляция не делает#

Корреляция не:

подавляет уведомления автоматически объединяет группы алертов разрешает связанные группы алертов напрямую меняет статус сервиса заменяет расчёт влияния на сервис гарантирует правильность первопричины

Она намеренно носит рекомендательный характер.

Рекомендуемая настройка#

Используйте корреляцию по зависимостям для важных продакшн-зависимостей.

Хорошие кандидаты:

API -> database API -> queue frontend -> backend API worker -> queue service -> external provider service -> shared infrastructure

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

Устранение неполадок#

Корреляция не появляется#

Проверьте:

  • Обе группы алертов активны: firing или acknowledged.
  • Обеим группам алертов назначены сервисы.
  • Сервисы связаны включённой зависимостью.
  • У зависимости включён correlation_enabled.
  • Связанные алерты укладываются в ожидаемую задержку распространения.
  • Сервисы относятся к области видимости одной команды.
  • Рассчитанная оценка достаточно высока для сохранения.

Корреляция появляется, но выглядит неверно#

Проверьте:

  • Правило сопоставления сервиса назначило правильный сервис.
  • Направление зависимости указано верно.
  • Тип зависимости и критичность точны.
  • Задержка распространения не слишком велика.
  • Метки алертов не назначают несвязанные алерты одному сервису.

Слишком много корреляций#

Снизьте шум так:

  • Отключите корреляцию для слабых зависимостей.
  • Уменьшите propagation_delay_seconds.
  • Используйте более точные правила сопоставления сервисов.
  • Избегайте широких «catch-all» сервисов для несвязанных алертов.