/)
Маршрутизация оповещений часто начинается с простого. Команда создает несколько точек контакта, добавляет сопоставители меток и строит дерево политик уведомлений, которое отправляет каждое оповещение в нужный пункт назначения.
Но конфигурации оповещений редко остаются простыми.
По мере роста организации ее дерево политик уведомлений должно учитывать все больше команд, сервисов и требований к маршрутизации. Изменения для одной команды по-прежнему требуют редактирования глобальной конфигурации, что делает владение менее прозрачным, а независимую подготовку — более сложной. Со временем даже небольшие обновления могут потребовать навигации по все более сложному дереву маршрутизации.
Начиная с Grafana 13.2, несколько политик уведомлений стали общедоступными в системе оповещений под управлением Grafana. Вы можете создавать именованные деревья политик уведомлений, назначать правила оповещений конкретной политике и управлять каждой политикой независимо.
Существующие правила оповещений продолжают использовать политику уведомлений по умолчанию, если вы не назначите их именованной политике, поэтому вы можете внедрять эту функцию постепенно, не мигрируя каждое правило сразу.
Что дают множественные политики уведомлений
Множественные политики уведомлений обеспечивают более четкие границы для организации, управления и защиты маршрутизации оповещений. С их помощью вы можете:
- Разделять логику маршрутизации на более мелкие именованные деревья, организованные вокруг команды, сервиса, домена или другой границы ответственности
Разделять логику маршрутизации на более мелкие именованные деревья, организованные вокруг команды, сервиса, домена или другой границы ответственности
- Назначать правила оповещений напрямую политике, которая должна обрабатывать их оповещения
Назначать правила оповещений напрямую политике, которая должна обрабатывать их оповещения
- Предоставлять ресурсы и управлять каждой политикой независимо через пользовательский интерфейс Grafana, API, или Terraform
Предоставлять ресурсы и управлять каждой политикой независимо через пользовательский интерфейс Grafana, , или
- Контролировать доступ с помощью управления доступом на основе ролей на уровне политик
Контролировать доступ с помощью управления доступом на основе ролей на уровне политик
- Обновлять одну политику, не затрагивая конфигурацию маршрутизации или состояние уведомлений оповещений, назначенных другой политике
Обновлять одну политику, не затрагивая конфигурацию маршрутизации или состояние уведомлений оповещений, назначенных другой политике
Ограничения единого глобального дерева политик уведомлений
Модель маршрутизации оповещений Grafana Alerting базируется на Prometheus Alertmanager, где маршрутизация представлена в виде единого глобального дерева политик уведомлений с маршрутом верхнего уровня и вложенными дочерними маршрутами.
Внутри этого дерева метки оповещений сопоставляются с маршрутами, которые определяют, как оповещения группируются, когда отправляются уведомления и какие точки контакта их получают.
Эта модель хорошо работает, когда конфигурация маршрутизации мала или управляется централизованно. Но она создает трудности, когда все больше команд начинают использовать один и тот же стек Grafana:
- Логика маршрутизации каждой команды должна вписываться в одну и ту же иерархию
Логика маршрутизации каждой команды должна вписываться в одну и ту же иерархию
- Предоставление или обновление политик означает работу со всем деревом целиком
Предоставление или обновление политик означает работу со всем деревом целиком
- Командам необходим широкий доступ к общей конфигурации, даже если они владеют лишь ее небольшой частью
Командам необходим широкий доступ к общей конфигурации, даже если они владеют лишь ее небольшой частью
- Большие деревья политик становится труднее понимать, проверять и безопасно изменять
Большие деревья политик становится труднее понимать, проверять и безопасно изменять
Распространенной стратегией по мере роста организаций является создание ветки верхнего уровня для каждой команды, сервиса или домена. Например, глобальное дерево может иметь отдельные ветки для оповещений платежной системы, платформы и безопасности.
Это обеспечивает определенную логическую организацию, но ветки все равно являются частью одной общей конфигурации. У них тот же жизненный цикл, та же граница подготовки ресурсов и та же граница разрешений. Обновление ветки одной команды по-прежнему означает изменение глобального дерева, содержащего ветку любой другой команды.
Благодаря нескольким политикам уведомлений каждая команда или сервис может иметь собственную именованную политику вместо того, чтобы существовать лишь как ветка в глобальном дереве. Каждая политика может быть подготовлена, защищена и управляема независимо.
Та же знакомая модель маршрутизации с лучшими границами
Несколько политик уведомлений позволяют разделить эту глобальную конфигурацию маршрутизации на более мелкие именованные деревья политик.
Каждая именованная политика имеет собственный корневой узел и дочерние маршруты. Внутри выбранного дерева маршрутизация продолжает работать так же, как и раньше: метки оповещений сопоставляются с маршрутами, а эти маршруты управляют группировкой, временем отправки уведомлений и выбором точек контакта.
Основное отличие заключается в том, что правило оповещения теперь может выбирать, какое дерево политик должно обрабатывать его оповещения.
Например, правило оповещения, принадлежащее команде платежей, может выбрать политику с именем «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 ресурс управляет именованными деревьями маршрутизации. Имя передается через метаданные ресурса, поэтому отдельные ресурсы Terraform могут отвечать за отдельные политики.
Пример:
Каждым ресурсом может управлять рабочее пространство или репозиторий, отвечающие за соответствующую политику. Ресурс Terraform поддерживает вложенные маршруты, сопоставители, группировку, параметры времени уведомлений и элементы управления происхождением, которые определяют, остается ли политика доступной для редактирования за пределами Terraform.
Поэтапный переход на несколько политик
Поддержка нескольких политик уведомлений была представлена в Grafana 13.1 в рамках переключателя функций alertingMultiplePolicies и стала общедоступной в Grafana 13.2.
Существующие конфигурации продолжают работать через политику уведомлений по умолчанию, и нет никакой необходимости сразу разделять существующее дерево или обновлять каждое правило оповещения.
Практический путь внедрения:
- Создайте именованную политику для команды, сервиса или домена.
Создайте именованную политику для команды, сервиса или домена.
- Воспроизведите соответствующее поведение маршрутизации в новой политике.
Воспроизведите соответствующее поведение маршрутизации в новой политике.
- Назначьте правила оповещений этой команды созданной политике.
Назначьте правила оповещений этой команды созданной политике.
- Проверьте получившееся поведение уведомлений.
Проверьте получившееся поведение уведомлений.
- Передайте управление политикой ответственной команде или рабочему процессу автоматизации.
Передайте управление политикой ответственной команде или рабочему процессу автоматизации.
Остальные правила могут оставаться на политике по умолчанию до тех пор, пока не возникнет необходимость их перемещения.
Маршрутизация оповещений, масштабируемая вместе с вашей организацией
Единое дерево политики уведомлений просто в использовании, когда инфраструктура оповещений мала. Однако при масштабировании оно может превратиться в общее узкое место конфигурации, которым сложно управлять, подготавливать и безопасно изменять.
Несколько политик уведомлений сохраняют привычную для Grafana Alerting модель маршрутизации на основе метк, при этом обеспечивая более четкие границы жизненного цикла и ответственности. Команды могут работать с меньшими деревьями, независимо настраивать политики, ограничивать область изменений и применять более детальный контроль доступа.
Независимо от того, организуете ли вы политики по командам, сервисам или доменам, результатом станет маршрутизация оповещений, которая точнее отражает реальные процессы работы вашей организации.
Grafana Assistant — это самый простой способ начать работу с метриками, логами, трейсами, дашбордами и многим другим в Grafana Cloud. У нас есть щедрый бесплатный тарифный план, действующий бессрочно, а также планы для любых сценариев использования. Зарегистрируйтесь бесплатно прямо сейчас!
Теги
/)
/)
/)