Обзор

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

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

С помощью "Alerting (Оповещения)" создаются запросы и выражения из нескольких источников данных – независимо от того, где хранятся данные, – что позволяет комбинировать данные и получать оповещения о метриках и журналах новыми и уникальными способами. Затем можно создавать оповещения, управлять ими и принимать меры по ним из единого консолидированного представления, что позволит команде быстрее выявлять и устранять проблемы.

На рисунке 73 представлен обзор "Alerting (Оповещения)" и описаны некоторые основные функции, лежащие в основе работы.

Рисунок 73 — Функции оповещений

Общая схема работы выглядит следующим образом:

"Alerting (Оповещения)" периодически запрашивает источники данных и оценивает условие, заданное в правиле оповещения;
если условие нарушено, срабатывает экземпляр оповещения;
случаи срабатывания (и устранения) оповещений отправляются для уведомления либо напрямую в контактную точку, либо с помощью политик уведомлений для большей гибкости.

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

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

Каждое правило оповещения может создавать несколько экземпляров оповещения (также известных как сигналы) – по одному экземпляру для каждого временного ряда. Это исключительно удобно, так как позволяет наблюдать за несколькими рядами в одном выражении (рисунок 74).

Рисунок 74 — Несколько экземпляров оповещений из одного правила оповещения

Правило, использующее приведенное ниже выражение PromQL, создает столько же экземпляров оповещений, сколько процессоров после первой оценки, что позволяет одному правилу сообщать о состоянии каждого процессора:

sum by(cpu) (
rate(node_cpu_seconds_total{mode!="idle"}[1m])

Правила оповещений часто оцениваются, и состояние их экземпляров оповещений соответствующим образом обновляется. В уведомлениях отправляются только экземпляры оповещений, которые находятся в состоянии срабатывания или разрешения.

Контактные точки определяют, какое сообщение будет отправлено и куда будут отправляться уведомления. Например, может быть контактная точка, которая отправляет уведомления на адрес электронной почты, в Slack, в систему управления инцидентами или в вебхук.

По умолчанию в сообщениях уведомлений указываются сведения об оповещениях, такие как количество оповещений, их статус и примечания, которые помогают операторам решать проблемы, связанные с оповещениями. Сообщения уведомлений также можно настроить.

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

Политика уведомлений – это расширенная опция для обработки уведомлений об оповещениях в крупных инфраструктурах.

Политики уведомлений направляют оповещения в контактные точки с помощью сопоставления меток. Каждая политика уведомлений состоит из набора сопоставлений меток (0 или более), которые определяют, какие экземпляры оповещений (идентифицируемые по их меткам) они обрабатывают. Политики уведомлений определяются в виде древовидной структуры, где корнем дерева политик уведомлений является "Default notification policy (Политика уведомлений по умолчанию)", которая обеспечивает обработку всех экземпляров оповещений (рисунок 75).

Рисунок 75 — Маршрутизация запуска экземпляров оповещений с помощью политик уведомлений

Каждая политика уведомлений определяет, куда отправлять оповещения (контактная точка) и когда отправлять уведомления (параметры времени). Кроме того, она может объединять несколько оповещений в одно уведомление, чтобы уменьшить количество оповещений (рисунок 76).

Рисунок 76 — Политика уведомлений

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

"Alerting (Оповещения)" построена на основе модели Prometheus для разработки систем оповещений. Системы оповещений на основе Prometheus состоят из двух основных компонентов:

генератор оповещений, который оценивает правила оповещений и отправляет сработавшие и разрешенные оповещения получателю оповещений;
получатель оповещений (также известный как Alertmanager), который получает оповещения и отвечает за отправку уведомлений.

Мониторинг сложных ИТ-инфраструктур и понимание того, все ли работает правильно, – непростая задача. Поэтому важно настроить эффективную систему управления оповещениями, чтобы получать информацию о сбоях до того, как они начнут влиять на результаты деятельности.

Разработка и настройка эффективной системы управления оповещениями требует времени.

Вот несколько рекомендаций о том, как создать эффективную систему управления оповещениями для бизнеса:

ключевые метрики бизнеса, которые требуется отслеживать и по которым получать оповещения:
- найти события, о которых важно знать, но которые не настолько просты или часты, чтобы получатели их игнорировали;
- оповещения следует создавать только для крупных событий, требующих немедленного внимания или вмешательства;
- отдавать предпочтение качеству, а не количеству;
организация оповещений и уведомлений:
- избирательность в адресате отправки оповещений: нужные команды, присутствие на связи, конкретные каналы.
- продуманные уровни приоритета и серьезности;
- по возможности автоматизация подготовки ресурсов для оповещений с помощью API или Terraform;
информация, включаемая в уведомления:
- ясность в том, кто является получателем оповещения и ответственными за реагирование;
- обмен информацией, которая помогает респондентам выявлять и устранять потенциальные проблемы;
- связь оповещения с панелями мониторинга, чтобы указать респондентам, какие данные следует исследовать;
нивелирование усталости от бдительности:
- избегать громких и ненужных оповещений, используя режим без звука, отключение оповещений по времени или приостановка оценки правил оповещений;
- постоянно настраивать правила оповещений, чтобы оценивать их эффективность; удалять правила оповещений, чтобы избежать дублирования или неэффективных оповещений;
- постоянно пересматривать пороговые значения и правила оценки.