Практические примеры для IncidentRelay v2.3.1, проверены . Имена, идентификаторы и интервалы ниже приведены для иллюстрации; проверьте их на тестовом развёртывании до использования production-учётных данных.
Бизнес-пример · Настройка · Практический пример · Приёмочные проверки · Ограничения и отказы
Бизнес-пример: три клиентские системы и один шумный чат поддержки
Это модельная ситуация, а не история реального клиента. Метрики ниже предложены для вашего пилота: это не подтверждённая экономия и не утверждение, что все нужные отчёты встроены в IR.
Ситуация и риск. Сервис-провайдер поддерживает трёх клиентов, у каждого есть алерты приложений и инфраструктуры. Всё приходит в один чат. Инженеры пересылают сообщения другим командам, а повторы скрывают первоначальный сигнал. Бизнес-риск — задержка назначения ответственного и лишняя работа поддержки, даже если мониторинг обнаружил сбой вовремя.
Процесс с IR. Сопоставьте каждый клиентский сервис с ответственной командой и используйте нужный токен маршрута для каждого отправителя. Проверяйте метки окружения и сервиса, выбирайте дежурного и группируйте повторы только в нужных границах ответственности. Прежде чем расширять схему, проведите пилот на production-биллинге одного клиента с matcher из примера ниже.
Какую пользу проверить. Замените рутинную пересылку сообщений явной маршрутизацией. Первой должна реагировать команда, которая может действовать; при этом сообщения нескольких хостов об одной проблеме сохраняются как отдельные дочерние алерты.
Что измерять. Для каждого клиента считайте алерты, переназначенные после первого решения маршрутизации, группы без ответственного и число уведомлений на одну исходную проблему. Проверяйте также отклонённые и не совпавшие с правилами тестовые события: меньше уведомлений — не успех, если авария клиента стала невидимой.
Ограничения. Совпадение меток не обеспечивает изоляцию клиентских данных. Отдельно проверьте права доступа, учётные данные и границы развёртываний. Несогласованные метки или слишком широкая группировка по-прежнему могут направить задачу не той команде или объединить несвязанные симптомы; проверьте эти ситуации до подключения следующего клиента.
Разделите приём событий, ответственность и доставку
Production-сервис биллинга и его staging-копия не должны случайно будить одних и тех же людей. Для первого пилота создайте Webhook-маршрут команды production-биллинга, выберите сервис по умолчанию, ротацию или политику и подключите каналы. Входящий токен определяет маршрут; сами по себе совпадающие метки не аутентифицируют отправителя и не выбирают произвольный маршрут.
Точный matcher маршрута и явный ключ группировки
Вставьте этот объект в редактор matcher маршрута. Это объект условий, а не тело входящего webhook. Все условия соединены логическим AND. Обязательные метки production и сервиса не пропустят в этот маршрут staging и события без нужных меток.
{
"source": "webhook",
"labels": {
"environment": "production",
"service": "billing-api"
}
}В этом примере задайте полю group_by маршрута значение:
["alertname", "severity", "labels.cluster"]Тогда два хоста с одинаковым алертом в одном кластере могут попасть в одну AlertGroup, сохранив отдельные дочерние идентификаторы. Для generic webhook используйте стабильные fingerprint, например billing:node-1:health и billing:node-2:health. Передавайте ожидаемые метки и при сбое, и при восстановлении; никогда не используйте новую временную метку как идентификатор каждого повтора.
Дедупликация и группировка решают разные задачи: одинаковый fingerprint обновляет дочерний алерт, а разные fingerprint с одним ключом группы создают в ней отдельные дочерние алерты. Маршрут, команда, источник и сервис также ограничивают область группировки. Добавляйте instance в поля группировки, только если каждому хосту нужна отдельная группа.
Когда один отправитель действительно обслуживает несколько команд
Используйте глобальную оркестрацию, когда ответственных нужно выбирать по содержимому события. В Builder начните с условий labels.environment equals production и labels.service equals billing-api, затем выберите совместимые объекты команды, маршрута и сервиса из одной группы. Не переносите числовые ID объектов между инсталляциями.
Проверьте конфигурацию и смоделируйте как совпадения, так и несовпадения, опубликуйте её, затем используйте shadow с совместимостью hybrid. Изучите реальные выполнения перед переходом в active. Shadow записывает решения, не меняя поведение production; Simulator не доказывает сквозную доставку.
Составьте небольшую матрицу проверок маршрутизации
| Входные данные | Ожидаемый результат в этом примере |
|---|---|
| Событие production-биллинга | Matcher совпадает; выбранные сервис, ответственный и каналы соответствуют запланированной схеме ответственности. |
| Staging или отсутствующая метка сервиса | Matcher не совпадает. Проверьте предусмотренный альтернативный путь отправителя; этот пример не создаёт маршрут для всех остальных событий. |
| Повторный fingerprint | Обновляется тот же дочерний алерт. Другой fingerprint хоста создаёт второй дочерний алерт в той же группе, если метки группировки совпадают. |
| Восстановление только одного из двух дочерних алертов | Этот дочерний алерт разрешается; группа остаётся активной, пока не восстановятся все активные дочерние алерты. Восстановление без соответствующего алерта не создаёт новую группу. |
Избегайте правил, которые незаметно скрывают происходящее
Пустой matcher совпадает со всем. Метка severity не обязательно является тем же полем, что и нормализованная важность события; используйте путь из документации и проверяйте реальное нормализованное событие. Не требуйте status=firing на входящем пути, который должен принимать и восстановление.
В режиме active + legacy решения оркестрации не применяются. В hybrid некорректные сочетания объектов могут привести к возврату на прежний путь обработки; в авторитетном режиме orchestration ошибка вычисления или проверки объектов, напротив, блокирует обработку. Выбирайте поведение при сбоях осознанно.
Начните без широких правил drop и suppress. Подавление и группировка могут сократить число уведомлений, но не сделают плохой сигнал мониторинга полезным. Сохраните проверенную предыдущую версию и разберите неожиданные несовпадения перед расширением внедрения.