Перейти к основному содержимому
Руководство администратора
How To статьи
Установка и настройка
Компоненты
Руководство пользователя
Начало работы

Настройка алертов

Основные разделы для работы с алертами​

  • Alert rules - создание и редактирование правил алертов (условия срабатывания, пороги, интервалы оценки).
  • Recording rule - заранее вычисляет PromQL‑выражение и сохраняет результат как новую метрику.
  • Notification configuration - настройки каналов уведомлений.
  • Silences - временное отключение (заглушение) активных алертов по заданным критериям.
  • Settings - общие настройки алертинга.

Навигация к алертам​

Способ 1. Через главное меню

  1. Откройте Grafana и войдите в систему.
  2. На левой боковой панели перейдите в Alerting.
  3. Вы попадёте в раздел управления алертами с вкладками:
    • Alert rules - список всех правил алертов
    • Contact points - настройки каналов доставки уведомлений
    • Notification policies - политики отправки уведомлений. По умолчанию в системе применена базовая политика.
    • другие виджеты.

Способ 2. Из дашборда

  1. Откройте нужный дашборд.
  2. Найдите панель, для которой настроен алерт.
  3. В правом верхнем углу панели нажмите на значок колокольчика.
  4. В выпадающем меню выберите:
    • View alert rules - посмотреть правила алертов для этой панели.
    • Create alert - создать новый алерт для этой панели.

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

Preview

Выпадающий список действий с дашбордами и алертами

Поиск алерта​

В разделе Alert rules:

  • Используйте поиск по имени алерта.
  • Фильтруйте по:
    • статусу (Firing, Normal, Pending и Recovering);
    • дашборду;
    • меткам (labels);
    • группе (folder).
  • Сортируйте по:
    • времени последнего срабатывания;
    • важности (severity);
    • имени.

Создание правила алерта​

  1. Перейдите в интерфейс создания алерта. В меню Grafana выберите Alerting → Alert rules, затем нажмите New alert rule.

  2. Задайте понятное имя алерта. В поле Enter alert rule name укажите имя по шаблону: bercut_<компонент>_<метрика>_<порог>.
    Пример: bercut_kafka_lag_critical.
    Это упрощает поиск, фильтрацию и понимание зоны ответственности.

  3. Выберите метрику и настройте фильтры по лейблам (Label filters) в блоке Define query and alert condition.

    • В поле Metric выберите нужную метрику из списка или воспользуйтесь поиском.
    • В поле Label filters задайте условия отбора по лейблам.
      • Select Label - выберите ключ лейбла.
      • Select filters - укажите значения и операторы для выбранных лейблов.

    Используйте следующие операторы:

    ОператорНазначениеПояснение применения
    =Точное совпадение значения лейбла.Для точечного мониторинга конкретного объекта: потока, компонента, ноды.
    !=Исключает указанное значение.Позволяет исключить из мониторинга тестовые потоки или отдельные ноды, не требующие алертов.
    =~Соответствие регулярному выражению.Когда нужно захватить группу объектов по шаблону: несколько потоков, компонентов.
    !~Не соответствует регулярному выражению.Исключить группу объектов, которые заведомо не должны попадать в алерт.

После того как вы выбрали метрику и задали фильтры по лейблам в блоке Define query and alert condition, с полученными значениями можно выполнять следующие операции — они нужны, чтобы превратить «сырые» метрики в условия алерта:

  • Агрегация (например, sum(), avg(), max(), rate()).
    Позволяет обобщать данные: суммировать ошибки по всем инстансам компонента, считать среднюю задержку по потоку и т. д.

    Пример: sum by (flow) (rate(esb_http_errors[5m])) - суммарный RPS ошибок по каждому потоку.

  • Функции над диапазоном векторов (например, rate(), irate(), increase()). Позволяют анализировать динамику метрик за интервал времени для детектирования всплесков, трендов и аномалий в потоках Bercut.

    Пример: irate(esb_queue_size[1m]) - мгновенный прирост размера очереди.

  • Функции (например,abs(), ceil(), floor()). Применяются для нормализации и округления значений метрик, чтобы избежать ложных срабатываний из‑за «шума» и привести данные к удобному виду: abs() убирает отрицательные значения (актуально при ошибках агрегации или смещении счётчиков), ceil() и floor() позволяют привести метрику к дискретным уровням для упрощения логики алертов или отображения.

    Пример: ceil(esb_latency_ms / 10) * 10 - округление задержки до десятков миллисекунд для группировки на дашборде.

  • Бинарные операторы (например, >, >=, <, <=). Позволяют сравнивать метрики, нормализовать, фильтровать по условиям, чтобы строить сложные условия алертов, например "ошибок больше 50 в минуту".

  • Тригонометрические функции (например, sin(), cos(), atan(), asin()). Позволяют выполнять математические преобразования значений метрик.

    Пример: sin(hour(v__time) * (pi() / 12)) — синусоидальная аппроксимация суточного цикла нагрузки.

  • Функции времени (например, day_of_month(), day_of_week()). Дают возможность учитывать календарную периодичность при построении алертов и дашбордов: фильтровать по дням недели, выделять выходные/праздники, корректировать пороги в зависимости от дня месяца. Полезны для правил, где поведение системы отличается по расписанию (например, ночные деплои, еженедельные отчёты).

    Пример: esb_errors_total > 100 and day_of_week(v__time) != 6 - алерт по ошибкам только в будни.

  1. Настройте условие срабатывания в блоке Alert condition.
    Укажите логику, по которой алерт определяет инцидент (порог и сравнение).
    Без корректно заданного условия алерт не сможет отличить нормальную работу от эксплуатационного инцидента.

  2. Сгруппируйте алерты по проектам, средам или сервисам в блоке Add folder and labels. Это упрощает навигацию и разграничение сред.

    • Folder - выберите существующую папку или создайте новую, нажав New Folder.
    • Добавьте значимые лейблы (например, severity=critical, component=kafka-connector) - они будут использоваться для маршрутизации уведомлений и фильтрации в дашбордах.

  3. Настройте поведение оценки в блоке Set evaluation behavior.

    • Evaluation group and interval - логический контейнер, куда помещают набор правил (алертов или recording‑правил), которые должны проверяться с одной и той же частотой. Выберите группу из списка или создайте новую.

    • Pending period - время, в течение которого условие должно оставаться нарушенным, чтобы алерт сработал. Если выбрано None, алерт активируется сразу при превышении порога.

    • Keep firing for - время удержания статуса Firing после нормализации метрики. Рекомендуемые значения: 15m для критических алертов, 10m - для ошибок и лагов, если выбрать None, алерт вернётся в Normal сразу, как только метрика снова окажется в норме.

      При нажатии на + New evaluation group откроется окно с полями:

    • Evaluation group name - укажите или создайте группу правил с единым интервалом оценки. Все алерты в группе проверяются одновременно с заданной частотой.

    • Evaluation interval - укажите частоту, с которой система пересчитывает все правила в группе (например, каждые 5 минут).

  4. Настройте обработку отсутствия данных и ошибок в выпадающем блоке Configure no data and error handling. Эти настройки критически важны для корректной эскалации инцидентов.

    • Alert state if no data or all values are null: установите значение No Data. Это позволяет отделить проблему с объектом мониторинга (удаление потока, падение экспортера) от реальных эксплуатационных инцидентов и избежать ложных срабатываний.
    • Alert state if execution error or timeout: установите значение Error. Это сигнализирует о сбое в инфраструктуре мониторинга (VictoriaMetrics, сеть, vmalert) и позволяет изолировать такие инциденты от проблем функционирования Bercut.
      Алерты в состояниях No Data и Error должны направляться в канал команды эксплуатации (SRE/DevOps).

  5. Настройте доставку уведомлений в Configure notifications.

    • Contact point: выберите заранее созданный канал доставки или создайте новый, нажав View or create contact points.
      Если в среде настроены Notification policies, явный выбор Contact point не требуется: маршрутизация будет выполняться автоматически по лейблам.
      Для продуктивных сред Bercut рекомендуется использовать Notification policies - это обеспечивает единообразие, упрощает масштабирование и позволяет чётко разделять зоны ответственности между командами.

  6. Настройте контекст уведомления в блоке Configure notification message. Эти поля важны для сокращения времени диагностики и однозначного понимания инцидента.

    • Summary (optional) - краткая формулировка сути инцидента в одной строке. Должна сразу давать ответ на вопрос «что случилось и насколько серьёзно», без необходимости открывать Grafana.

    • Description (optional) - развёрнутый контекст для диагностики: какая метрика и как агрегируется, какие компоненты и среды затронуты, возможные причины и первые шаги проверки.

    • Runbook URL (optional) - ссылка на пошаговую инструкцию с чёткими действиями, командами для быстрой диагностики, контактами ответственных и условиями, когда алерт можно игнорировать.

  7. Нажмите Save для сохранения изменений.

Создание правила записи (recording rule)​

  1. Перейдите в интерфейс создания recording rule.
    В меню Grafana выберите Alerting → Alert rules → Recording rules, затем нажмите New recording rule.

  2. Задайте имена правила и результирующей метрики.

    • В поле Name укажите имя recording rule. Это упростит поиск и понимание назначения правила.
    • В поле Metric задайте имя новой записываемой метрики - оно будет использоваться в последующих запросах и алертах.
    • В Target data source выберите источник данных, где будут храниться результаты.

  3. Определите логику правила в блоке Define recording rule.

    • В поле Metric выберите нужную метрику из списка или воспользуйтесь поиском.
    • В поле Label filters задайте условия отбора по лейблам.
      • Select Label - выберите ключ лейбла.
      • Select filters - укажите значения и операторы для выбранных лейблов.

  4. При необходимости добавьте математические операции в Expressions.

    • В секции Reduce задайте агрегацию, которая превратит временные ряды в одно значение на каждый интервал:
      • Function - функция агрегации, которая сводит множество точек временного ряда в одно значение за выбранный интервал. Позволяет из потока данных получить понятный показатель для алерта. Возможные значения:
        • last - последнее значение за интервал. Подходит для статусов, флагов, текущих показателей, где важна актуальная точка (например, статус доступности компонента).
        • min - минимальное значение. Используют, чтобы отследить «лучший» показатель в группе (например, минимальную задержку среди потоков).
        • max - максимальное значение. Ключевая функция для критических метрик: лаг Kafka, пиковая задержка, пик ошибок. Позволяет не пропустить худший случай - важен для SLA и алертинга.
        • mean (avg) - среднее арифметическое. Подходит для типичных нагрузок и усреднённых показателей (средняя задержка, средняя пропускная способность), когда пики не критичны или уже отфильтрованы.
        • median - медианное значение. Например, при редких резких скачках задержки медиана покажет реальную картину для большинства запросов.
        • count - количество временных рядов/точек. Применяют для подсчёта активных получателей, потоков, нод - полезно для мониторинга масштаба и обнаружения пропажи экземпляров.
        • sum - суммарное значение. Нужно, когда важен общий объём по группе (суммарные ошибки, суммарная нагрузка), но требует осторожности: без жёстких фильтров по лейблам может резко увеличить число временных рядов в хранилище.
      • Mode - определяет, как recording rule реагирует, если часть входных временных рядов недоступна или содержит ошибки. Возможные значения:
        • Strict(рекомендуется) - выдаст результат, если все входные ряды валидны. Если хотя бы один ряд пропал (например, упал экспортер на одной ноде кластера), правило не запишет значение.
        • Replace non‑numeric values - нечисловые значения (NaN, null и т. п.) заменяются на заданное значение (на 0 или последнее валидное).
        • Drop non‑numeric values - нечисловые значения исключаются из расчёта. Агрегация считается только по валидным точкам, ряд становится «разреженным».

    Нажмите Preview, чтобы убедиться, что на выходе получается один временной ряд с осмысленными значениями.

  5. Организуйте правило с помощью папок и лейблов в блоке Add folder and labels.

    • Folder - позволяет выбрать существующую папку или создать новую. Это упрощает навигацию и разграничение сред. Присвойте recording rule набор лейблов, нажав Add labels. В поле Choose key выберите существующий ключ из списка или введите новый. В поле Choose value введите значение для ключа.

  6. Настройте поведение оценки в блоке Set evaluation behavior.

    • Выберите или создайте Evaluation group: все правила в группе будут оцениваться с единым интервалом.
    • Укажите имя группы Evaluation group name и частоту, с которой система пересчитывает все правила в группе Evaluation interval. Убедитесь, что папка выбрана до настройки группы и интервала - иначе продолжить будет нельзя.

  7. Нажмите Save для сохранения изменений.

Создание канала уведомлений​

  1. Перейдите к созданию Contact Point.

    В меню Grafana выберите Alerting → Notification configuration, затем нажмите New contact point.

  2. В поле Name задайте понятное имя.

  3. В выпадающем списке Integration выберите тип доставки в зависимости от критичности алерта и требований к скорости реакции:

    • Мессенджеры и командные чаты: интеграция с корпоративными мессенджерами (в соответствии с реестром ПО).
    • Сервисы алертинга и инцидент-менеджмента интеграция с системами управления инцидентами.
    • Универсальные/инфраструктурные каналы: Webhook (доставка во внутреннюю систему обработки событий).
    • Традиционные каналы связи: электронная почта.

  4. Заполните параметры выбранной интеграции:

  • Если выбран традиционный канал связи:

    • Поле To - укажите адреса получателей. Можно указать несколько, через запятую, без пробелов после запятой: ops@bercut.local, oncall@bercut.local.

    Примечание:

    Не добавляйте более 5–7 адресов в один Contact Point - это снижает риск попадания писем в спам и упрощает аудит.

  • Если выбраны мессенджеры и командные чаты:

    • URL / Webhook URL - вставьте URL вебхука.
    • Chat ID / Room ID - укажите идентификатор чата/канала, куда отправлять сообщения.

  • Если выбраны сервисы алертинга и инцидент‑менеджмента:

    • Integration Key / Service Key / API Key / Routing key - вставьте ключ интеграции (не личный токен).
    • URL - адрес эндпоинта API, куда Grafana шлёт запросы.
    • Severity / Priority - укажите уровень критичности по умолчанию:
      • critical - для падения потоков, недоступности ESB, критического лага Kafka.
      • warning - для предупреждений и приближающихся порогов.
    • Client / Client URL - укажите источник и ссылку для быстрого перехода.

  • Если выбраны каналы персональной доставки:

    • User Key - персональный токен пользователя.
    • Token - токен приложения.
    • API URL - базовый URL API или полный URL.
    • API Secret - секретный ключ.
    • Corp ID - иденификатор вашей корпоративной учётной записи.
  1. Нажмите Save contact point для сохранения изменений.

Отключение (заглушение) активных алертов​

  1. Перейдите к В меню Grafana выберите Alerting → Silences, затем нажмите кнопку Create silence.

    Вкладка Silences позволяет временно остановить уведомления по одному или нескольким правилам алертов - например, на время плановых работ, деплоя или отладки компонента Bercut ESB. Заглушение работает на уровне Alertmanager и не отключает сами правила (Alert rules остаются активными, но не отправляют уведомления).

  2. Выберите нужный экземпляр Alertmanager в правой части страницы.
    Укажите тот Alertmanager, к которому относятся алерты, которые хотите заглушить. Заглушение применяется только к выбранному экземпляру.

  3. Задайте период действия заглушения.
    В поле Silence start and end укажите период заглушения, а в поле Duration - длительность, например 2h, 4h, 1d.

  4. Уточните, какие именно алерты будут заглушены, через матчеры лейблов.
    В блоке Refine affected alerts добавьте хотя бы один matcher:

    • Label - укажите имя лейбла (например, alertname, component, environment, flow).
    • Value - задайте значение (например, kafka_lag_high).
      Нажмите Add matcher, чтобы добавить дополнительные условия.
      Чем точнее набор лейблов, тем безопаснее: заглушите только нужные алерты, а не все подряд.

  5. Посмотрите, какие алерты попадут под заглушение.
    Ниже блока матчеров есть секция Affected alert instances.
    Как только вы добавили валидный набор матчеров, в этой секции появится список алертов, которые будут затронуты.

    Важно!

    Обязательно проверьте список: если там есть лишние алерты - уточните матчеры (добавьте environment, component или flow) для лучшей защиты от случайного заглушения важных инцидентов.

  6. Добавьте комментарий с причиной заглушения.
    В поле Comment кратко опишите, зачем создаётся Silence.

  7. Сохраните заглушение.
    Нажмите кнопку Save silence. Silence сразу вступит в силу для выбранных алертов.

    Проверить активные заглушения можно на той же вкладке Silences: там видно, какие лейблы попали под заглушение, период действия и комментарий.

Работа с разделом Settings​

Раздел позволяет управлять экземплярами Alertmanager: включать приём Grafana‑управляемых алертов, редактировать конфигурации и добавлять новые.

  1. Перейдите в настройки Alertmanager.
    В меню Grafana выберите Alerting → Settings, затем откройте вкладку Alertmanagers.

  2. Ознакомьтесь со списком экземпляров.
    Вы увидите карточки для каждого Alertmanager:

    • Built‑in Alertmanager (Grafana built‑in) - встроенный экземпляр Grafana.
    • Другие Alertmanagers - внешние экземпляры (на базе Prometheus/Mimir), используемые для разных сред.

  3. Проверьте статус приёма Grafana‑алертов.
    Для каждого экземпляра отображается строка:

    • Receiving Grafana‑managed alerts - приём включён, Grafana может слать алерты в этот Alertmanager.
    • Not receiving Grafana managed alerts - приём отключён: алерты не будут доставлены, даже если в Notification policies выбран этот экземпляр.

  4. Включите приём алертов, если требуется.
    Для нужного экземпляра (например, alertmanager-1 для PROD) нажмите кнопку Enable.

    Важно!

    Включение не меняет конфигурацию самого Alertmanager - оно разрешает Grafana отправлять в него алерты. Если экземпляр находится в другой среде (Mimir/Prometheus), убедитесь, что сеть и авторизация уже настроены.

  5. При необходимости отредактируйте конфигурацию.
    Нажмите Edit configuration рядом с нужным экземпляром. В форме можно скорректировать:

    • URL (адрес API Alertmanager)
    • настройки авторизации
    • таймауты и прочие параметры подключения.
      После правки обязательно нажмите Save.

  6. Проверьте конфигурацию.
    Для встроенного или внешнего экземпляра нажмите View configuration, чтобы увидеть текущие параметры.

  7. При необходимости отключите экземпляр.
    Если экземпляр временно не должен получать алерты от Grafana, нажмите Disable. Это не удаляет экземпляр, а только запрещает Grafana слать в него алерты. Полезно для изоляции среды при тестировании.

Добавление нового Alertmanager​

  1. Перейдите в настройки Alertmanager.
    В меню Grafana выберите Alerting → Settings, затем откройте вкладку Alertmanagers. Нажмите Add new Alertmanager в правом верхнем углу страницы, затем Add new data source.

  2. Задайте имя и тип реализации.

  • Name - укажите понятное имя, по которому сразу ясно, что это за экземпляр.
  • Implementation - выберите тип, который соответствует вашей инфраструктуре.
    Возможные значения:
    • Mimir - распределённый Alertmanager для высоконагруженных и мультитенантных сценариев. Подходит для сред с большим потоком алертов и требованиями к отказоустойчивости.
    • Cortex - масштабируемое решение для мультитенантной среды. Выбирайте, если в вашей инфраструктуре Bercut Cortex управляет алертами.
    • Prometheus - «коробочный» Alertmanager. Оптимален для небольших контуров, где не нужна сложная распределённость. Использует стандартный набор эндпоинтов и настроек.
  1. Укажите URL подключения.
  • URL - введите полный адрес API Alertmanager, доступный с бэкенда Grafana (Server access):
  • Убедитесь, что:
    • URL начинается с http:// или https://;
    • порт указан явно;
    • домен/IP доступен из сети, где работает Grafana backend (не только из браузера пользователя).

 4. Настройте доступ.

Режим доступа Server (default)​

  1. В блоке Allowed cookies перечислите имена cookies, которые должны передаваться к Alertmanager: вводите каждое имя отдельной строкой и нажимайте Add.

  2. Задайте таймаут HTTP‑запроса. В поле Timeout укажите значение в секундах - для контуров Bercut оптимально 15–20 с. Меньшие значения могут давать ложные сбои при временных задержках кластера; большие - затягивают диагностику инцидентов.

  3. Включите нужные переключатели в блоке Auth:

    • Basic auth - активируйте, если используется базовая HTTP‑аутентификация; после включения появятся поля для логина и пароля.
    • With Credentials - работает в связке с Basic auth. Определяет, будут ли учётные данные (cookies, заголовки аутентификации) отправляться вместе с межсайтовыми (cross‑site) HTTP‑запросами.
    • TLS Client Auth - активируйте при использовании mTLS; после включения станут доступны поля для загрузки клиентского сертификата и ключа.
    • With CA Cert - добавьте корневой сертификат (CA), если Alertmanager использует самоподписанный TLS‑сертификат.
    • Skip TLS Verify - отключает проверку сертификата и снижает безопасность. Допустимо только в изолированных DEV‑контурах.
    • Forward OAuth Identity - оставьте выключенным: для Alertmanager в сценариях Bercut эта опция практически не применяется.

  4. Добавьте кастомные HTTP‑заголовки, если нужно.
    Нажмите Add header, затем укажите пару «Имя - Значение».

  5. Проверьте подключение.
    Нажмите кнопку Save & test. Тест выполняется с бэкенда Grafana - это единственный достоверный способ убедиться, что соединение реально работает в продуктивной среде.
    Если тест не прошёл, проверьте:

    • доступность URL с сервера Grafana
    • корректность учётных данных, сертификаты и сетевые правила. При необходимости используйте логи Grafana backend.

Режим доступа Browser​

Browser может использоваться для:

  • Разовых тестов доступности Alertmanager с рабочей станции.
  • Отладки UI в изолированных DEV‑контурах, где нет требований к безопасности и доставке алертов.

Не подходит для эксплуатации: алерты и политики работают только при выборе режима Server.

Включите нужные переключатели в блоке Auth: Basic auth и With Credentials. Описание приведено выше.

Нажмите Save & test. Тест запускается из браузера и показывает, доступен ли Alertmanager с вашей рабочей станции.