/)
Маршрутизация алертов часто начинается с простого. Команда создает несколько контактных точек, добавляет несколько сопоставителей меток и выстраивает дерево политик уведомлений, которое отправляет каждый алерт в нужное место.
Но конфигурации алертинга редко остаются простыми.
По мере роста организации дерево политик уведомлений должно учитывать потребности большего количества команд, сервисов и требований к маршрутизации. Изменения для одной команды по-прежнему требуют редактирования глобальной конфигурации, что делает владение менее прозрачным, а независимое предоставление ресурсов — более сложным. Со временем даже небольшие обновления могут потребовать навигации по все более сложному дереву маршрутизации.
В Grafana 13.2 несколько политик уведомлений стали общедоступными в системе алертинга, управляемой Grafana. Вы можете создавать именованные деревья политик уведомлений, назначать правила алертов конкретной политике и управлять каждой политикой независимо.
Существующие правила алертов продолжают использовать политику уведомлений по умолчанию, если вы не назначите их на именованную политику, поэтому вы можете внедрять эту функцию постепенно, не мигрируя все правила сразу.
Что дают несколько политик уведомлений
Несколько политик уведомлений обеспечивают более четкие границы для организации, управления и обеспечения безопасности маршрутизации алертов. С их помощью вы можете:
- Разделять логику маршрутизации на более мелкие именованные деревья, организованные вокруг команды, сервиса, домена или другой границы ответственности
Разделять логику маршрутизации на более мелкие именованные деревья, организованные вокруг команды, сервиса, домена или другой границы ответственности
- Назначать правила алертов непосредственно той политике, которая должна обрабатывать их алерты
Назначать правила алертов непосредственно той политике, которая должна обрабатывать их алерты
- Предоставлять ресурсы и управлять каждой политикой независимо через пользовательский интерфейс Grafana, API или Terraform
Предоставлять ресурсы и управлять каждой политикой независимо через пользовательский интерфейс Grafana, API или Terraform
- Контролировать доступ с помощью управления доступом на основе ролей на уровне политик
Контролировать доступ с помощью управления доступом на основе ролей на уровне политик
- Обновлять одну политику, не затрагивая конфигурацию маршрутизации или состояние уведомлений алертов, назначенных другой политике
Обновлять одну политику, не затрагивая конфигурацию маршрутизации или состояние уведомлений алертов, назначенных другой политике
Ограничения одного глобального дерева политик уведомлений
Модель маршрутизации уведомлений Grafana Alerting основана на Prometheus Alertmanager, где маршрутизация представлена как единое глобальное дерево политик уведомлений с маршрутом верхнего уровня и вложенными дочерними маршрутами.
Внутри этого дерева метки алертов сопоставляются с маршрутами, которые определяют, как алерты группируются, когда отправляются уведомления и какие контактные точки их получают.
Эта модель хорошо работает, когда конфигурация маршрутизации невелика или управляется централизованно. Но она создает проблемы, когда больше команд начинают использовать один и тот же стек Grafana:
- Логика маршрутизации каждой команды должна вписываться в одну и ту же иерархию
Логика маршрутизации каждой команды должна вписываться в одну и ту же иерархию
- Предоставление ресурсов или обновление политик означает работу со всем деревом целиком
Предоставление ресурсов или обновление политик означает работу со всем деревом целиком
- Командам нужен широкий доступ к общей конфигурации, даже если они владеют лишь ее небольшой частью
Командам нужен широкий доступ к общей конфигурации, даже если они владеют лишь ее небольшой частью
- Большие деревья политик становятся труднее для понимания, проверки и безопасного изменения
Большие деревья политик становятся труднее для понимания, проверки и безопасного изменения
Распространенная стратегия по мере масштабирования организаций — создание ветки верхнего уровня для каждой команды, сервиса или домена. Например, глобальное дерево может иметь отдельные ветки для алертов по платежам, платформе и безопасности.
Это обеспечивает некоторую логическую организацию, но ветки по-прежнему являются частью одной общей конфигурации. У них один и тот же жизненный цикл, одна и та же граница предоставления ресурсов и одна и та же граница разрешений. Обновление ветки одной команды по-прежнему означает изменение глобального дерева, которое содержит ветки всех остальных команд.
Благодаря нескольким политикам уведомлений каждая команда или сервис может иметь свою собственную именованную политику вместо того, чтобы существовать только как ветка внутри глобального дерева. Каждой политикой можно управлять, обеспечивать ее безопасность и предоставлять ресурсы независимо.
Та же знакомая модель маршрутизации, но с лучшими границами
Несколько политик уведомлений позволяют разделить эту глобальную конфигурацию маршрутизации на более мелкие именованные деревья политик.
Каждая именованная политика имеет свой собственный корневой узел и дочерние маршруты. Внутри выбранного дерева маршрутизация продолжает работать так же, как и всегда: метки алертов сопоставляются с маршрутами, а эти маршруты управляют группировкой, временем уведомлений и выбором контактных точек.
Основное отличие заключается в том, что правило алерта теперь может выбирать, какое дерево политик должно обрабатывать его алерты.
Например, правило алерта, принадлежащее команде платежей, может выбрать политику с названием «payments». Алерты, созданные этим правилом, затем маршрутизируются только через дерево «payments».
Селектор политики является частью конфигурации правила алерта. Правила, которые явно не выбирают именованную политику, продолжают использовать политику уведомлений по умолчанию, сохраняя поведение существующих конфигураций алертинга.
Это означает, что вы можете внедрять несколько политик уведомлений постепенно. Вы можете сохранить существующее дерево в качестве политики по умолчанию и вводить дополнительные политики по мере того, как команды или сервисы будут готовы управлять своей маршрутизацией независимо.
Независимое управление и предоставление ресурсов для каждой политики
При использовании одного глобального дерева предоставление ресурсов было фактически принципом «все или ничего». Обновление маршрутов одной команды означало отправку или замену конфигурации, которая также содержала логику маршрутизации всех остальных команд.
Именованные политики уведомлений — это отдельные ресурсы. Вы можете создавать, извлекать, обновлять, удалять, экспортировать и предоставлять одну политику, не заменяя остальные.
Это позволяет согласовать жизненный цикл политики с командой или сервисом, которому она принадлежит. Команда платформы может развертывать изменения в своей политике «platform», не развертывая при этом политики «payments» или «security».
Политики также изолированы друг от друга. Изменения в дереве маршрутизации одной политики не изменяют конфигурацию маршрутизации или состояние уведомлений алертов, назначенных другой политике. Обновление политики «platform», например, не изменяет и не нарушает работу алертов, маршрутизируемых через политику «payments».
Для команд, управляющих алертингом как кодом (Alerting as Code), это обеспечивает гораздо более безопасную границу развертывания. Рабочая область Terraform или конвейер автоматизации могут владеть одной именованной политикой, вместо того чтобы требовать владения всей конфигурацией маршрутизации организации.
Организация маршрутизации в соответствии с тем, как работает ваша организация
Не существует единственно правильного способа разделения политик уведомлений. Правильная граница зависит от того, как ваша организация владеет своими системами и управляет ими.
Политики могут быть организованы по:
- Команде, например «payments», «security» или «platform»
Команде, например «payments», «security» или «platform»
- Сервису, например «checkout-api» или «identity»
Сервису, например «checkout-api» или «identity»
- Домену, например «infrastructure», «customer-facing» или «data-platform»
Домену, например «infrastructure», «customer-facing» или «data-platform»
- Окружению, когда разные окружения требуют существенно разной маршрутизации и владения
Среда, когда различные окружения требуют существенно отличающихся настроек маршрутизации и владения.
Цель состоит не обязательно в создании политики для каждого правила оповещения. Вместо этого политики должны отражать значимые границы владения или жизненного цикла.
Небольшие деревья легче проверять, поскольку каждое из них содержит только те решения по маршрутизации, которые соответствуют его назначению. Команда может понять свою точку контакта по умолчанию, пути эскалации, конфигурацию группировки и временные параметры, не просматривая при этом не относящиеся к делу маршруты, принадлежащие остальной части организации.
Делегирование владения с более детальным контролем доступа
Именованные политики также обеспечивают естественную границу для более детального управления доступом на основе ролей.
Вместо предоставления пользователям разрешения на изменение всего глобального дерева политик уведомлений администраторы могут контролировать, кому разрешено просматривать, создавать, обновлять или удалять отдельные политики. Это упрощает делегирование маршрутизации оповещений командам, наиболее близким к сервису, при сохранении централизованного контроля над общими или конфиденциальными политиками.
Разрешения на уровне политик можно управлять непосредственно через пользовательский интерфейс Grafana. Администраторы могут предоставлять командам доступ к принадлежащим им политикам, не предоставляя широкого доступа к остальной конфигурации маршрутизации уведомлений организации.
Например, команда платежных систем может управлять политикой «payments», не получая разрешения на изменение или даже просмотр политики «security». Центральная команда наблюдаемости может сохранить контроль над политикой по умолчанию и резервными вариантами для всей организации.
Это помогает организациям распределять владение оповещениями, не предоставляя неограниченный доступ ко всей конфигурации уведомлений.
Управление политиками через пользовательский интерфейс, API или Terraform
Вы можете создавать именованные политики уведомлений и управлять ими из пользовательского интерфейса Grafana. Перейдите в:
Alerts & IRM → Alerting → Notification configuration → Notification policies
Оттуда создайте новую политику или выберите существующую для управления ее деревом маршрутизации. При настройке правила оповещения выберите политику уведомлений, которая должна получать оповещения от этого правила.
Именованные политики также доступны через Grafana Alerting API, что позволяет системам автоматизации управлять каждым деревом маршрутизации как отдельным ресурсом.
Для пользователей Terraform ресурс grafana_apps_notifications_routingtree_v1beta1 управляет именованными деревьями маршрутизации. Имя задается через метаданные ресурса, поэтому отдельные ресурсы Terraform могут владеть отдельными политиками.
Пример:
Каждым ресурсом может управлять рабочая область или репозиторий, ответственный за эту политику. Ресурс Terraform поддерживает вложенные маршруты, сопоставители, группировку, параметры времени уведомлений и элементы управления происхождением, которые определяют, остается ли политика доступной для редактирования вне Terraform.
Постепенное внедрение нескольких политик
Несколько политик уведомлений были представлены в Grafana 13.1 за переключателем функций alertingMultiplePolicies и стали общедоступными в Grafana 13.2.
Существующие конфигурации продолжают работать через политику уведомлений по умолчанию, и нет необходимости немедленно разделять существующее дерево или обновлять каждое правило оповещения.
Практический путь внедрения:
- Создайте именованную политику для команды, сервиса или домена.
Создайте именованную политику для команды, сервиса или домена.
- Воспроизведите соответствующее поведение маршрутизации в новой политике.
Воспроизведите соответствующее поведение маршрутизации в новой политике.
- Назначьте правила оповещения этой команды для данной политики.
Назначьте правила оповещения этой команды для данной политики.
- Проверьте полученное поведение уведомлений.
Проверьте полученное поведение уведомлений.
- Передайте управление политикой ответственной команде или рабочему процессу автоматизации.
Передайте управление политикой ответственной команде или рабочему процессу автоматизации.
Другие правила могут оставаться в политике по умолчанию, пока не появится причина для их перемещения.
Маршрутизация оповещений, которая масштабируется вместе с вашей организацией
Единое дерево политик уведомлений просто в использовании, когда настройка оповещений невелика. Однако при масштабировании оно может стать узким местом в общей конфигурации, которым трудно владеть, предоставлять и безопасно изменять.
Несколько политик уведомлений сохраняют привычную для Grafana Alerting модель маршрутизации на основе меток, вводя при этом более четкие границы жизненного цикла и владения. Команды могут работать с меньшими деревьями, независимо предоставлять политики, ограничивать область изменений и применять более детальный контроль доступа.
Независимо от того, организуете ли вы политики по командам, сервисам или доменам, результатом является маршрутизация оповещений, которая более точно отражает то, как на самом деле работает ваша организация.
Grafana Assistant — это самый простой способ начать работу с метриками, логами, трассировками, дашбордами и многим другим в Grafana Cloud. У нас есть щедрый бесплатный тарифный план и планы для любых задач. Зарегистрируйтесь бесплатно прямо сейчас!
Теги