Алертинг в Proto Observability Platform

На этой странице:

• Из чего состоит алертинг
• Встроенные правила алертинга
• Правила алертинга по SLO
• Автоматическое выявление аномалий
• Инциденты
• Интеграция с CI/CD
• В этом разделе

Модуль алертинга Proto Observability Platform отвечает за выявление проблем по телеметрии и доставку оповещений в нужные каналы. Эта страница даёт общее представление о модуле; пошаговые инструкции вынесены в отдельные руководства (см. В этом разделе).

Из чего состоит алертинг

Система оповещений складывается из трёх связанных сущностей, которые настраиваются в разделе главного меню Алерты:

Связка работает так: правило срабатывает по условию → политика сопоставляет лейблы алерта со своими матчерами и выбирает канал → канал доставляет уведомление получателю.

Пошаговая настройка каналов, политик и правил описана в руководстве Настройка оповещений. Справочник по метрикам и выражениям для правил — на странице Метрики и выражения для правил.

Новым пользователям стоит начать с раздела Быстрый старт — он за четыре шага проводит от создания канала до первого уведомления.

Встроенные правила алертинга

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

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

Чтобы добавить собственное правило, воспользуйтесь кнопкой Добавить — см. Настройка оповещений → Создание правила. О доступных метриках, синтаксисе выражений и аннотациях со ссылками на дашборды читайте на странице Метрики и выражения для правил.

Правила алертинга по SLO

Начиная с версии 200, при создании SLO (см. Управление SLO) платформа автоматически генерирует набор правил алертинга по скорости сжигания бюджета ошибок:

• Быстрое сжигание (fast burn, 14.4×/1h) — сигнализирует о внезапной деградации, при которой бюджет будет исчерпан за несколько часов;
• Медленное сжигание (slow burn, 6×/6h) — выявляет устойчивое, но менее резкое превышение допустимого уровня ошибок;
• Контроль объёма (volume guard) — блокирует ложные срабатывания при резком падении трафика;
• Исчерпание бюджета — фиксирует момент нарушения SLO.

Метки и владелец из определения SLO автоматически прокидываются в алерты. Правила генерируются и обновляются сервисом proto-alert-rule-manager и появляются в общем списке правил алертинга.

Редактировать эти правила напрямую нельзя — для изменения условий измените параметры соответствующего SLO.

Автоматическое выявление аномалий

Платформа с помощью машинного обучения (ML) автоматически строит базовую линию (ожидаемый диапазон) для ключевых показателей каждого сервиса и ключевой транзакции — с учётом суточной и недельной сезонности и без ручной настройки порогов. При выходе значений за верхнюю границу базовой линии срабатывают встроенные правила группы ANOMALY.

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

Инциденты

Платформа автоматически коррелирует связанные алерты и объединяет их в инциденты: вместо потока однотипных уведомлений дежурный работает с одной сущностью, у которой есть первопричина, охват, ответственный, этапы жизненного цикла (ITIL) и история. Для инцидентов доступны ИИ-сводка, ИИ-расследование первопричины и граф распространения.

Подробнее — см. Инциденты.

Интеграция с CI/CD

Вы можете сообщать в Proto Observability Platform информацию о сделанном релизе из вашего CI/CD пайплайна. Для этого встройте в свой пайплайн вызов скрипта marker.sh со следующеми аргументами:

./marker.sh "адрес_бекенд_сервер" "название_релиза" "название сервиса (опционально)"

• Адрес бэкенд сервера указывается без префикса https://
• Название релиза – короткая строка, например, номер коммита, версия релиза и тд.
• Название сервиса:
  • если указано – маркер релиза будет отображаться только у этого конкретного сервиса.
  • если не указано – маркер релиза будет отображаться у каждого сервиса (то есть релиз распространяется на все сервисы).

Например:

./marker.sh "proto-backend.fqdn" "и снова 3 сентября"

Содержимое marker.sh:

#!/bin/bash

PROTO_BACKEND_URL=${1}
PROTO_RELEASE_NAME=${2}
PROTO_SERVICE_NAME="${3}"

generate_post_data()
{
 now=$(date +%s000)

if [ -z "${PROTO_SERVICE_NAME}" ]; then
  cat <<EOF
[
    {
        "uuid": "${now}",
        "name": "${PROTO_RELEASE_NAME}",
        "source": {
          "service": ""
        },
        "layer":"GENERAL",
        "type": "RELEASE",
        "message": "Релиз: ${PROTO_RELEASE_NAME} Сервис: Все",
        "parameters": {},
        "startTime": ${now},
        "endTime": ${now}
    }
]
EOF
else
  cat <<EOF
[
    {
        "uuid": "${now}",
        "name": "${PROTO_RELEASE_NAME}",
        "source": {
          "service": "${PROTO_SERVICE_NAME}"
        },
        "layer":"GENERAL",
        "type": "RELEASE",
        "message": "Релиз: ${PROTO_RELEASE_NAME}",
        "parameters": {},
        "startTime": ${now},
        "endTime": ${now}
    }
]
EOF
fi
}
  # echo $(generate_post_data) | jq
  curl -i -k \
  -H "Accept: application/json" \
  -H "Content-Type:application/json" \
  -X POST --data "$(generate_post_data)" "https://${PROTO_BACKEND_URL}/v3/events"

В этом разделе

• Быстрый старт: первое оповещение — сквозной пример: канал, правило, политика и проверка.
• Настройка оповещений — каналы, политики и правила (описание полей форм), а также работа с правилами.
• Просмотр алертов и событий — активные алерты в реальном времени, история с аналитикой и MTTR, лента событий.
• Инциденты — автоматическая корреляция связанных алертов в инциденты, этапы жизненного цикла (ITIL), ИИ-сводка и ИИ-расследование первопричины, граф распространения.
• Метрики и выражения для правил — метрики сервисов и их лейблы, синтаксис выражений и аннотации со ссылками на дашборды.
• Выявление аномалий — автоматические базовые линии метрик, встроенные правила аномалий и настройка профилирования.
• Диагностика и формат уведомлений — состояния алерта, почему уведомление не пришло, содержимое email/Telegram и payload вебхука.
• Управление SLO — цели уровня обслуживания и автоматическая генерация правил алертинга по бюджету ошибок.