Оповещения

Памир использует Alertmanager для отправки оповещений. Итоговая конфигурация Alertmanager складывается из настроек:

• Общих настроек
• Интервалов времени
• Отправителей
• Адресатов
• Шаблонов сообщений
• Правил подавления

Итоговая конфигурация, которая попадет в Alertmanager доступна в разделе Настройки -> Уведомления -> Alert Manager.

подсказка

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

Общие настройки

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

global:
  # Поле заголовка From по умолчанию для SMTP.
  [ smtp_from: <tmpl_string> ]
  # SMTP-сервер (smarthost) по умолчанию, используемый для отправки электронных писем, включая номер порта.
  # Обычно номер порта — 25 или 587 для SMTP поверх TLS (иногда называемого STARTTLS).
  # Пример: smtp.example.org:587
  [ smtp_smarthost: <string> ]
  # Имя хоста по умолчанию для идентификации на SMTP-сервере.
  [ smtp_hello: <string> | default = "localhost" ]
  # Аутентификация SMTP с использованием CRAM-MD5, LOGIN и PLAIN. Если не указано, Alertmanager не аутентифицируется на SMTP-сервере.
  [ smtp_auth_username: <string> ]
  # Аутентификация SMTP с использованием LOGIN и PLAIN.
  [ smtp_auth_password: <secret> ]
  # Аутентификация SMTP с использованием LOGIN и PLAIN.
  [ smtp_auth_password_file: <string> ]
  # Аутентификация SMTP с использованием PLAIN.
  [ smtp_auth_identity: <string> ]
  # Аутентификация SMTP с использованием CRAM-MD5.
  [ smtp_auth_secret: <secret> ]
  # Требование TLS для SMTP по умолчанию.
  # Обратите внимание, что Go не поддерживает незашифрованные соединения с удалёнными SMTP-узлами.
  [ smtp_require_tls: <bool> | default = true ]

  [ telegram_api_url: <string> | default = "https://api.telegram.org" ]


  # Конфигурация HTTP-клиента по умолчанию.
  [ http_config: <http_config> ]

  # Параметр ResolveTimeout — это значение по умолчанию, используемое Alertmanager, если оповещение
  # не включает EndsAt. После истечения этого времени Alertmanager может объявить оповещение завершённым, если оно не было обновлено.
  # Это не влияет на оповещения от Prometheus, так как они всегда включают EndsAt.
  [ resolve_timeout: <duration> | default = 5m ]

Интервалы времени

Интервалы времени позволяют определять периоды времени, когда определенные алерты должны или не должны срабатывать. Это полезно для:

• Отключения уведомлений в нерабочее время
• Настройки разных расписаний для разных команд
• Создания периодов обслуживания

Cтруктура конфигурации

time_intervals:
  - times:
    [ - <time_range> ...]
    # Диапазоны, включающие начальное время и не включающие конечное время, чтобы упростить 
    # представление времени, которое начинается/заканчивается на границах часов.
    # Например, start_time: '17:00' и end_time: '24:00' начнутся в 17:00 и 
    # закончатся непосредственно перед 24:00.
    weekdays:
    [ - <weekday_range> ...]
    # Cписок дней недели, где неделя начинается в воскресенье и заканчивается в субботу. Дни должны 
    # быть указаны по имени (например, 'Sunday'). Для удобства диапазоны также принимаются 
    # в форме <start_day>:<end_day> и включаются с обоих концов. 
    # Например: ['monday:wednesday','saturday', 'sunday']
    days_of_month:
    [ - <days_of_month_range> ...]
    # Cписок числовых дней в месяце. Дни начинаются с 1. Также принимаются отрицательные значения, 
    # которые начинаются в конце месяца, например, -1 в январе будет представлять 31 января.
    # Расширение за пределы начала или конца месяца приведет к его ограничению.
    # Например, указание ['1:31'] в феврале ограничит фактическую дату окончания до 28 
    # или 29 в зависимости от високосных лет. Включительно с обоих концов.
    months:
    [ - <month_range> ...]
    # Cписок календарных месяцев, идентифицированных по имени без учета регистра (например, «Январь») или по номеру, где Январь = 1. 
    # Диапазоны также принимаются. Например, ['1:3', 'may:august', 'december']. Включительно с обоих концов.
    years:
    [ - <year_range> ...]
    # Числовой список лет. Диапазоны допускаются. Например, ['2020:2022', '2030']. Включительно с обоих концов.
    location: <string>
    # Строка, которая соответствует местоположению в базе данных часовых поясов IANA.

Пример:

time_intervals:
  - name: 'workhours'           # Название периода
    time_intervals:              # Список временных интервалов
      - weekdays: ['monday:friday']  # Дни недели
        times:                   # Часовые интервалы
          - start_time: '09:00'  # Начало (формат HH:MM)
            end_time: '18:00'    # Конец (формат HH:MM)
      - location: 'Europe/Moscow' # Часовой пояс
  - name: 'weekends'
    time_intervals:
      - weekdays: ['saturday', 'sunday']

Основные параметры

1. Интервалы по дням недели

weekdays: ['monday:friday']  # С понедельника по пятницу
weekdays: ['saturday', 'sunday']  # Отдельные дни

2. Часовые интервалы

times:
  - start_time: '09:00'  # Формат HH:MM
    end_time: '18:00'

Пример использования

route:
  receiver: 'team-email'
  routes:
    - receiver: 'oncall-sms'
      matchers: ['severity=critical']
      mute_time_intervals: ['weekends']  # Не отправлять SMS по выходным
      active_time_intervals: ['workhours']  # Только в рабочее время

receivers:
  - name: 'team-email'
    email_configs: [...]
  - name: 'oncall-sms'
    webhook_configs: [...]

time_intervals:
  - name: 'workhours'
    time_intervals:
      - weekdays: ['monday:friday']
        times:
          - start_time: '09:00'
            end_time: '18:00'
  - name: 'weekends'
    time_intervals:
      - weekdays: ['saturday', 'sunday']

Особенности работы

1. Приоритеты:

   • mute_time_intervals - подавляет уведомления
   • active_time_intervals - разрешает уведомления только в указанные периоды

2. Форматы времени:

   • HH:MM для ежедневных интервалов

3. Часовые пояса:

   • По умолчанию используется UTC
   • Можно указать через location

Отправители

Отправители отвечают за механизм передачи уведомлений пользователю. Отправители создаются путем выбора в навигационнон меню Настройки -> Уведомления -> Отправители (рис.Создание отправителя №1), затем после нажатия кнопки добавить (рис.Создание отправителя №2) должен появиться в списке элемент Новый отправитель с пустыми полями(рис.Создание отправителя №3) Название отправителя, Активный, Тип отправителя и конфигурация Alertmanager в формате YAML. После нажатия кнопки сохранить, будет создан отправитель.

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

E-mail

Памир позволяет отправлять алерты по электронной почте. Вот полная структура с описанием всех параметров:

from: 'alertmanager@example.com'    # Опционально (по умолчанию используется smtp_from)
smarthost: 'smtp.example.com:587'   # Обязательное поле
auth_username: 'user@example.com'   # Опционально
auth_password: 'password'           # Опционально
auth_secret: 'secret'               # Альтернатива auth_password
auth_identity: 'user@example.com'   # Опционально (обычно для SMTP)
headers:                            # Дополнительные заголовки
  Subject: '[Alert] {{ .CommonLabels.alertname }}'
  X-Custom: 'Prometheus Alert'
html: '{{ template "email.html" . }}' # HTML-шаблон
text: '{{ template "email.txt" . }}'  # Текстовый шаблон
require_tls: true                   # Использовать TLS (по умолчанию true)
tls_config:                         # Опционально, настройки TLS-соединения
  ca_file: '/tls/smtp-ca.crt'
  server_name: 'smtp.example.com'
hello: 'alertmanager.example.com'   # Имя в SMTP HELO/EHLO

Основные параметры

Параметр	Тип	Обязательный	Описание
from	string	Нет	Email отправителя (по умолчанию smtp_from из глобальных настроек)
smarthost	string	Да	SMTP сервер с портом (например: smtp.gmail.com:587)
auth_username	string	Нет	Логин для SMTP-аутентификации
auth_password	string	Нет	Пароль для SMTP-аутентификации
auth_secret	string	Нет	Альтернатива паролю (например, для секретов Kubernetes)
auth_identity	string	Нет	Идентификатор для SMTP-аутентификации
require_tls	bool	Нет	Использовать TLS (по умолчанию true)
tls_config	object	Нет	Настройки TLS-соединения с SMTP-сервером, см. Настройка TLS для SMTP
hello	string	Нет	Имя хоста для SMTP HELO/EHLO

Дополнительные настройки

Параметр	Описание
headers	Дополнительные заголовки письма (Subject, From и др.)
html	HTML-шаблон письма
text	Текстовый шаблон письма

Пример конфигурации

from: alerts@company.com
smarthost: smtp.example.com:587
auth_username: alerts@company.com
auth_password: secret

Расширенная конфигурация с шаблонами

from: alerts@company.com
smarthost: smtp.example.com:587
auth_username: alerts@company.com
auth_password: secret
headers:
  Subject: '[CRITICAL] {{ .CommonLabels.alertname }}'
html: '{{ template "email.html" . }}'

Настройка TLS для SMTP

При require_tls: true (значение по умолчанию) Alertmanager обязательно выполняет команду STARTTLS и проверяет сертификат SMTP-сервера по системному хранилищу доверенных корневых сертификатов контейнера alertmanager, подставляя в SNI хост из smarthost. Если сертификат сервера выпущен доверенным удостоверяющим центром, блок tls_config заполнять не требуется.

tls_config нужен, когда:

• сертификат SMTP-сервера выпущен внутренним или самоподписанным УЦ — ca_file;
• SMTP-сервер требует клиентский сертификат (mTLS) — cert_file и key_file;
• имя в сертификате сервера не совпадает с хостом из smarthost — server_name;
• требуется ограничить версии протокола — min_version и max_version;
• требуется временно отключить проверку сертификата — insecure_skip_verify.

примечание

Настройки TLS для SMTP задаются у отправителя. Глобального параметра smtp_tls_config в общих настройках нет: конфигурация с ним не пройдёт проверку и не сохранится.

Параметр	Тип	Пример	Описание
ca_file	string	/tls/smtp-ca.crt	Путь к сертификату УЦ, которым проверяется сертификат SMTP-сервера.
cert_file	string	/tls/smtp-client.crt	Путь к клиентскому сертификату.
key_file	string	/tls/smtp-client.key	Путь к приватному ключу клиентского сертификата.
server_name	string	smtp.company.com	Имя сервера для SNI и проверки сертификата. По умолчанию — хост из smarthost.
insecure_skip_verify	bool	false	Если true, проверка сертификата сервера отключается (опасно!).
min_version	string	TLS12	Минимальная версия TLS: TLS10, TLS11, TLS12, TLS13.
max_version	string	TLS13	Максимальная версия TLS: TLS10, TLS11, TLS12, TLS13.

Пример 1. STARTTLS на порту 587, сертификат сервера выпущен внутренним УЦ:

from: alerts@company.com
smarthost: smtp.company.com:587
auth_username: alerts@company.com
auth_password: secret
require_tls: true
tls_config:
  ca_file: /tls/smtp-ca.crt
  server_name: smtp.company.com

Пример 2. SMTP поверх TLS на порту 465:

from: alerts@company.com
smarthost: smtp.company.com:465
auth_username: alerts@company.com
auth_password: secret
require_tls: false
tls_config:
  ca_file: /tls/smtp-ca.crt

warning

На порту 465 соединение шифруется сразу, без STARTTLS, поэтому require_tls нужно явно указать false. Со значением по умолчанию true Alertmanager поверх уже установленного TLS-соединения дополнительно потребует STARTTLS, и отправка завершится ошибкой 'require_tls' is true (default) but ... does not advertise the STARTTLS extension.

Пример 3. Аутентификация клиентским сертификатом (mTLS):

from: alerts@company.com
smarthost: smtp.company.com:587
require_tls: true
tls_config:
  ca_file: /tls/smtp-ca.crt
  cert_file: /tls/smtp-client.crt
  key_file: /tls/smtp-client.key

Сертификаты для SMTP в контейнере alertmanager

Пути в tls_config — это пути внутри контейнера alertmanager, и они должны быть абсолютными: относительные пути для e-mail-отправителей не разворачиваются относительно каталога конфигурации. Контейнер запускается в режиме read-only и каталога с пользовательскими сертификатами не содержит, поэтому файлы монтируются так же, как описано в разделе SSL между компонентами системы: сертификаты кладутся в data/tls/certs/, каталог монтируется в контейнер через docker-compose.additional.yml:

docker-compose.additional.yml

services:
  alertmanager:
    volumes:
      - type: bind
        source: ./data/tls/certs
        target: /tls
        read_only: true

Примените изменения:

pamirctl start alertmanager

warning

Проверка конфигурации не контролирует существование файлов сертификатов: конфигурация с неверным путём сохранится, а ошибка появится только при отправке письма — в журнале контейнера alertmanager.

Шаблоны писем

Пример простого шаблона:

{{ define "email.html" }}
<h1>Alert: {{ .Status | toUpper }}</h1>
{{ range .Alerts }}
<h2>{{ .Labels.alertname }}</h2>
<p><strong>Summary:</strong> {{ .Annotations.summary }}</p>
<p><strong>Description:</strong> {{ .Annotations.description }}</p>
<p><strong>Time:</strong> {{ .StartsAt }}</p>
<hr>
{{ end }}
{{ end }}

Telegram

https://prometheus.io/docs/alerting/latest/configuration/#telegram_config

# Если у вас есть особые конфигурации HTTP-клиента (например, прокси), вы можете добавить их здесь.
[ http_config: <http_config> | default = {}]

# Уведомлять ли о решенных оповещениях. Значение достается из форм 'каналы связи' при создании адресата
[ send_resolved: <boolean> | default = true ]

# Телеграм API URL i.e. https://api.telegram.org.
[ api_url: <string> | default = "https://api.telegram.org" ]

# Токен для телеграм бота
[ bot_token: <secret> ]

# ID чата куда шлется сообщение. Значение достается из форм 'каналы связи' при создании адресата
[ chat_id: <int> ]

# Шаблон сообщения
[ message: <tmpl_string> default = '{{ template "telegram.default.message" .}}' ]

# Режим анализа сообщения Telegram, поддерживаемые значения: MarkdownV2, Markdown, HTML и пустая строка для обычного текста.
[ parse_mode: <string> | default = "HTML" ]

Пример

http_config:
  follow_redirects: true
  enable_http2: true
api_url: https://api.telegram.org
bot_token: '7833060745:AAELlXdWPQ_iVsU3Nii3NH6s-iqoldQHeX8'
message: '{{ template "TelegramMessage" .}}'
parse_mode: HTML

Webhook

В Памир конфигурация webhook позволяет настраивать отправку алертов на внешние HTTP-серверы (вебхуки). Вот полная структура с описанием всех доступных параметров:

# Дополнительные параметры:
http_config:                         # Настройки HTTP-запроса
  basic_auth:                        # Базовая аутентификация
    username: 'user'
    password: 'pass'
  bearer_token: 'your-token'         # Токен в заголовке Authorization: Bearer
  bearer_token_file: '/path/to/token' # Альтернатива: токен из файла
  proxy_url: 'http://proxy:8080'      # Прокси-сервер
  tls_config:                        # Настройки TLS
    ca_file: '/path/to/ca.crt'
    cert_file: '/path/to/cert.pem'
    key_file: '/path/to/key.pem'
    server_name: 'alertmanager.example.com'
    insecure_skip_verify: false
  headers:                           # Кастомные заголовки
    Content-Type: 'application/json'
    X-Custom-Header: 'Alertmanager-Webhook'
max_alerts: 0                        # Макс. кол-во алертов в одном запросе (0 = без ограничений)
timeout: 0s                         #Максимальное время ожидания завершения запроса webhook

Основные параметры

Параметр	Тип	По умолчанию	Описание
max_alerts	int	0 (нет лимита)	Максимальное количество алертов в одном запросе. Если алертов больше, Alertmanager разобьёт их на несколько запросов.

http_config — настройки HTTP-запроса

Позволяет настроить аутентификацию, прокси и TLS.

Аутентификация

Параметр	Тип	Пример	Описание
basic_auth.username	string	admin	Логин для Basic Auth.
basic_auth.password	string	secret	Пароль для Basic Auth.
bearer_token	string	eyJhbGciOi...	Токен для заголовка Authorization: Bearer <token>.
bearer_token_file	string	/etc/alertmanager/token	Альтернатива bearer_token — токен читается из файла.

Прокси и TLS

Параметр	Тип	Пример	Описание
proxy_url	string	http://proxy:8080	URL HTTP-прокси.
tls_config.ca_file	string	/etc/ssl/ca.crt	Путь к CA-сертификату.
tls_config.cert_file	string	/etc/ssl/client.crt	Путь к клиентскому сертификату.
tls_config.key_file	string	/etc/ssl/client.key	Путь к приватному ключу.
tls_config.server_name	string	alertmanager.example.com	SNI (Server Name Indication).
tls_config.insecure_skip_verify	bool	false	Если true, отключает проверку сертификата (опасно!).

Кастомные заголовки (headers)

headers:
  Content-Type: "application/json"
  X-Custom-Header: "Alertmanager-Webhook"

Шаблоны сообщений

Памир использует Alertmanager для отправки оповещений. Получателем может быть одна из интеграций: E-mail, Telegram, webhook.

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

Шаблоны уведомлений Alertmanager основаны на системе шаблонов Go . Обратите внимание, что некоторые поля оцениваются как текст, а другие как HTML, что повлияет на экранирование.

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

Структура Data

Data — это структура, передаваемая в шаблоны уведомлений и вебхуки. Она содержит следующие поля:

• Receiver (string): Имя получателя, которому будет отправлено уведомление (например, Slack, email).
• Status (string): Статус оповещения; принимает значение firing, если хотя бы одно оповещение активно, иначе — resolved.
• Alerts ([]Alert): Список всех объектов оповещений в данной группе.
• GroupLabels (KV): Метки, по которым эти оповещения были сгруппированы.
• CommonLabels (KV): Метки, общие для всех оповещений.
• CommonAnnotations (KV): Набор аннотаций, общих для всех оповещений. Используется для добавления дополнительной информации об оповещении.
• ExternalURL (string): Ссылка на Alertmanager, отправивший уведомление.

Тип Alerts предоставляет функции для фильтрации оповещений:

• Alerts.Firing: возвращает список текущих активных оповещений в этой группе.
• Alerts.Resolved: возвращает список разрешённых оповещений в этой группе.

Структура Alert

Alert описывает отдельное оповещение и содержит следующие поля:

• Status (string): Статус оповещения (firing или resolved).
• Labels (KV): Набор меток для данного оповещения.
• Annotations (KV): Набор аннотаций для данного оповещения.
• StartsAt (Time): Время начала оповещения.
• EndsAt (Time): Время окончания оповещения.
• GeneratorURL (string): Ссылка на источник, сгенерировавший оповещение.

Тип KV

KV представляет собой карту строковых ключей и значений (map[string]string). Он используется для хранения меток и аннотаций.

Тип KV предоставляет следующие методы:

• Value(key string): возвращает значение для заданного ключа.
• Exists(key string): проверяет наличие заданного ключа.
• Match(regex string): возвращает все ключи, соответствующие заданному регулярному выражению.

Тип Time

Time представляет собой временную метку и предоставляет методы для форматирования:

• Time.Format(layout string): форматирует временную метку согласно заданному шаблону.

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

Адресаты

Работа адресатов заключается в отправке уведомлений по 1 и более каналам отправки(Отправители) в промежутки времени указаные Интервалами Времени. Адресаты создаются путем выбора в навигационнон меню Уведомления -> Адресаты (рис.Создание адресатов №1), затем после нажатия кнопки добавить (рис.Создание адресатов №2) должен появиться в списке элемент Новый адресат с обязательными полями для заполнения Название, при существующем канале отправки уведомлений Имя отправителя, Адресат также обязательны. После нажатия кнопки сохранить, будет создан интервал.

Создание адресатов

Опции полей Интервал отправки и Интервал тишины зависят от созданных Интервалов Времени

Интервал отправки и Интервал тишины

В каждом канале отправки существует поле Имя отправителя, опции которого зависят от созданных Отправителей

Интервал отправки и Интервал тишины

Значение поля Адресат вставляется в конфигурацию Alertmanager для Отправителя в зависимости от его типа (смотри раздел типы Отправителей). Свитч Активный и Отправлять resolve тоже попадают в конфигурацию Alertmanager соответсвующего отправителя. Также есть индикатор, говорящий о активности данного отправителя и взятые из формы его создания.

Правила подавления

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

Правила редактируются в разделе Настройки -> Уведомления -> Правила подавления. Страница содержит YAML-редактор с текущим содержимым секции inhibit_rules итоговой конфигурации Alertmanager, кнопки Сбросить и Сохранить, а также переключатель автообновления, который раз в 5 секунд перечитывает правила с сервера (автообновление выключается, пока в редакторе есть несохранённые изменения).

примечание

Доступ к разделу выдаётся тем же правом, что и к разделу Alert Manager, — Уведомления -> Управление менеджером уведомлений.

Cтруктура конфигурации

inhibit_rules:
  - source_matchers:
    [ - <matcher> ...]
    # Матчеры, которым должен соответствовать подавляющий алерт (источник). Обязательное поле.
    target_matchers:
    [ - <matcher> ...]
    # Матчеры, которым должен соответствовать подавляемый алерт (цель). Обязательное поле.
    equal:
    [ - <labelname> ...]
    # Метки, значения которых должны совпадать у источника и цели, чтобы подавление сработало.
    # Необязательное поле.

Матчер записывается в синтаксисе Alertmanager: <имя_метки><оператор>"<значение>", где оператор — =, !=, =~ или !~. Доступные метки перечислены в разделе Метки и аннотации события.

Пример использования

inhibit_rules:
  - source_matchers:
      - event_type = "monitoring.hi.Changed"
      - value =~ "^[3-5]$"
    target_matchers:
      - event_type = "monitoring.hi.Changed"
      - value = "2"
    equal:
      - tql_hi_link_id
      - user_id
      - fingerprint

Правило означает: пока по паре «привязка индикатора здоровья — пользователь» активен алерт со значением value от 3 до 5, алерты с value = 2 этой же пары уведомлений не порождают.

Особенности работы

1. Проверка перед сохранением. При сохранении сервис уведомлений собирает итоговую конфигурацию Alertmanager с новыми правилами и проверяет её через amtool. Если конфигурация некорректна (сломанный YAML, отсутствующие source_matchers/target_matchers, неверный матчер), изменения не сохраняются, а в интерфейс возвращается ошибка с описанием проблемы.
2. Пустое значение допустимо. Если очистить редактор и сохранить, правила подавления будут сброшены — секция сохранится как inhibit_rules: без правил.
3. Связь с итоговой конфигурацией. Сохранённые правила попадают в итоговую конфигурацию Alertmanager, доступную в разделе Настройки -> Уведомления -> Alert Manager. Правку удобнее выполнять в разделе Правила подавления: изменения в отправителях, адресатах и подписках перезаписывают итоговую конфигурацию, но не затрагивают секцию inhibit_rules.

Подписка на Индикаторы здоровья

Подписка на индикатор здоровья (ИЗ) — это правило, по которому изменение состояния конкретного индикатора превращается в персональное уведомление. Подписка связывает три сущности:

• привязку индикатора здоровья к узлу TQL (tql_hi_link_id) — источник событий;
• адресата (см. Адресаты) — канал или набор каналов доставки;
• пользователя, оформившего подписку, — уведомление получит только он.

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

Технически каждая подписка превращается в отдельный маршрут (route) в конфигурации Alertmanager, который Памир собирает автоматически. Вручную править эти маршруты в разделе Alert Manager не нужно: любое изменение подписок перезапишет их.

Где настраивается

Подписки оформляются на той же вкладке, где настраиваются сами индикаторы здоровья:

1. Перейдите в Главная / Настройки / Мониторинг / Шаблоны мониторинга.
2. Выберите шаблон мониторинга и откройте вкладку Индикаторы здоровья.
3. В строке нужного индикатора вызовите меню действий и выберите Настроить уведомления.
4. В открывшемся окне Подписки ИЗ нажмите Добавить и заполните форму.

Каждая подписка сохраняется отдельной кнопкой в своём блоке — закрытие окна не сохраняет изменения. Если в окне остались несохранённые данные, при закрытии выводится предупреждение.

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

к сведению

Пункт Настроить уведомления доступен только пользователям с правом на редактирование уведомлений.

Форма подписки

Поле	Обязательное	Описание
Включить	Нет	Активность подписки. Выключенная подписка не попадает в конфигурацию Alertmanager, уведомления по ней не отправляются.
Название	Да	Отображаемое имя подписки. Используется в заголовке блока и в колонке Подписки.
Системное имя	Нет	Уникальное имя подписки: строчная латиница, цифры и _, первым символом — буква. Если поле оставлено пустым, имя формируется транслитерацией отображаемого имени. После сохранения изменению не подлежит.
Выберите типы тревог	Да	Уровни критичности, при переходе в которые индикатор порождает уведомление: Ок, Предупреждение, Ошибка, Критический. По умолчанию выбраны Предупреждение, Ошибка, Критический.
Получать уведомления в браузере	Условно	Дублирование уведомлений в веб-интерфейс Памир (внутренний адресат bell).
Получатель	Условно	Адресат из раздела Уведомления → Адресаты. Определяет каналы доставки, интервал отправки и интервал тишины. В списке доступны только собственные адресаты пользователя.
Группировать уведомления	Нет	Если флаг снят, Alertmanager группирует уведомления по всем меткам события (group_by: ['...']). Если установлен — группировка выполняется по индикатору здоровья и пользователю.
Интервал создания группы	Да	group_wait — задержка перед отправкой первого уведомления группы. По умолчанию 00:00:30.
Интервал расширения группы	Да	group_interval — период, через который в уже отправленную группу досылаются новые события. По умолчанию 00:05:00.
Интервал напоминания	Да	repeat_interval — период повторной отправки уведомления, если состояние не изменилось. По умолчанию 04:00:00.
Расширенный фильтр событий	Нет	Дополнительные матчеры Alertmanager в формате YAML-списка строк.

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

Если у подписки одновременно указан адресат и включена доставка в браузер, Памир формирует два маршрута: один — на выбранного адресата (с учётом его интервалов отправки и тишины), второй — на внутреннего адресата bell (без временных интервалов, уведомление в интерфейсе приходит всегда).

подсказка

Интервалы задаются в формате ЧЧ:ММ:СС, а в конфигурацию Alertmanager попадают в секундах.

Проверка и применение конфигурации

При сохранении подписки сервис уведомлений:

1. Пересобирает раздел route итоговой конфигурации Alertmanager из всех включённых подписок.
2. Проверяет полученную конфигурацию утилитой amtool. Если конфигурация некорректна, подписка не сохраняется и возвращается ошибка с текстом проверки.
3. Публикует событие об изменении конфигурации, по которому новая конфигурация применяется в Alertmanager.

Изменение адресата, отправителя или интервала времени также приводит к пересборке маршрутов, поэтому ручные правки в разделе Alert Manager будут перезаписаны.

Повтор текущих состояний

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

Повтор выполняется, когда:

• подписка создана и сразу включена;
• выключенная подписка включена;
• у включённой подписки изменились уровни критичности или индикатор здоровья.

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

Маршрут подписки в конфигурации Alertmanager

Маршруты группируются по пользователям: на верхнем уровне создаётся маршрут-контейнер с матчером user_id, внутри которого располагаются маршруты отдельных подписок.

route:
  receiver: empty
  routes:
    # маршрут-контейнер пользователя
    - receiver: empty
      matchers:
        - user_id = 4e0f2a1b-6f0e-4f2c-9d0e-2c7c9a5f1b30
      continue: false
      routes:
        # маршрут подписки: доставка выбранному адресату
        - receiver: duty_team_resolve
          group_by:
            - tql_hi_link_id
            - user_id
          matchers:
            - value =~ 3|4|5
            - tql_hi_link_id = 0f1c8f6e-3f6a-4a5f-9f19-0f9f2b6e1d44
            - event_type = monitoring.hi.Changed
          mute_time_intervals:
            - weekends
          active_time_intervals:
            - workhours
          group_wait: 30s
          group_interval: 300s
          repeat_interval: 14400s
          continue: true
        # маршрут подписки: дублирование в веб-интерфейс
        - receiver: bell_resolve
          group_by:
            - tql_hi_link_id
            - user_id
          matchers:
            - value =~ 3|4|5
            - tql_hi_link_id = 0f1c8f6e-3f6a-4a5f-9f19-0f9f2b6e1d44
            - event_type = monitoring.hi.Changed
          continue: true

Как формируются матчеры:

• value — выбранные в форме уровни критичности;
• tql_hi_link_id — индикатор здоровья, для которого открыто окно подписок;
• event_type — тип события, для индикаторов здоровья это monitoring.hi.Changed;
• далее добавляются строки из поля Расширенный фильтр событий.

К имени адресата добавляется суффикс _resolve: подписки на индикаторы здоровья всегда работают в режиме разрешения (см. Разрешение уведомлений). Признак send_resolved для каждого канала берётся из настроек адресата.

Если у выбранного адресата не осталось ни одного активного канала отправки, маршрут на него не формируется. При этом маршрут на bell сохраняется, если включена доставка в браузер.

Путь события от индикатора здоровья до уведомления

1. Сервис monitoring фиксирует изменение состояния индикатора здоровья и публикует событие monitoring.hi.Changed.
2. Сервис notification отбирает включённые подписки, маска типа события которых соответствует событию, и оставляет из них те, у которых tql_hi_link_id совпадает с индикатором из события.
3. Для каждой подобранной подписки формируется алерт: поля события становятся метками, к ним добавляется метка user_id владельца подписки, а поля annotation события — аннотациями.
4. Алерт обогащается данными из сервисов monitoring и srm: наименованием типа индикатора, наименованием и типом КЕ.
5. Алерт отправляется в Alertmanager, который применяет к нему правила подавления, маршрутизацию, группировку и временные интервалы, после чего отправляет уведомление через отправителей адресата.

к сведению

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

Метки и аннотации события

Метки доступны в матчерах расширенного фильтра, в правилах подавления и в шаблонах сообщений.

Метка	Описание
event_type	Тип события, monitoring.hi.Changed.
value	Текущий уровень критичности индикатора здоровья.
tql_hi_link_id	Идентификатор привязки индикатора здоровья к узлу TQL.
hi_type_name	Системное имя типа индикатора здоровья.
type	Тип привязки индикатора: raw, calculate, alert_hint, event_hint, static.
ci_id	Идентификатор КЕ, на которой сработал индикатор.
ci_type_name	Системное имя типа КЕ.
ci_hint	Значение ci_hint, если индикатор привязывает алерты по нему.
tql_node_display_name	Отображаемое имя узла TQL шаблона мониторинга.
fingerprint	Отпечаток исходного алерта. Пуст, если индикатор не привязан к алертам.
user_id	Идентификатор владельца подписки.
change_status	Время изменения состояния индикатора.
id	Идентификатор индикатора здоровья на конкретной КЕ.
sot_id	Идентификатор эпизода истории индикатора — периода, в течение которого индикатор непрерывно находится в текущем состоянии.
ci_resolved	Признак, что КЕ из метки ci_id найдена в СРМ. False означает, что КЕ удалена или недоступна: по такому событию уведомление в браузере не рисует ссылку на здоровье КЕ.

Дополнительно в метки попадают метки исходного алерта (например, severity, instance, job). Для индикаторов, не привязанных к алертам (calculate, event_hint, static), метки алерта отсутствуют, а severity содержит текущий уровень критичности индикатора.

Аннотация	Описание
summary	Краткое описание из правила алертинга индикатора здоровья.
description	Подробное описание из правила алертинга.
hi_type_label	Отображаемое имя типа индикатора здоровья.
ci_name	Наименование КЕ.
ci_type_label	Отображаемое имя типа КЕ.

Ссылка на здоровье КЕ в уведомлении браузера

Уведомление в браузере (колокольчик) группирует пришедшие состояния по КЕ. Строка группы — ссылка на страницу СРМ, вкладку Здоровье КЕ: переход открывает индикатор, по которому пришло уведомление, на нужной КЕ. На отдельных алертах внутри группы ссылок нет — собственной страницы у алерта на здоровье КЕ не предусмотрено.

Ссылка открывает КЕ целиком, без выбранного индикатора, если все состояния группы имеют значение Не настроен (0) или Обслуживание (6): такие состояния карточка индикатора не показывает.

Ссылки нет совсем, когда в событии нет метки ci_id либо КЕ не найдена в СРМ (ci_resolved = False). Уведомления, полученные до появления ссылок, остаются без них: содержимое уведомления собирается один раз, в момент получения алерта.

Расширенный фильтр событий

Поле принимает YAML-список матчеров Alertmanager. Матчеры добавляются к матчерам подписки, то есть сужают её область действия.

- ci_type_name = "linux_server"
- instance =~ "prod-.*"

Некорректный YAML или конфигурация, которую отвергает amtool, приводят к ошибке сохранения подписки.

Разрешение уведомлений

Подписки на индикаторы здоровья всегда создаются с признаком разрешения (need_resolve). Это означает, что алерт считается активным, пока индикатор находится в проблемном состоянии:

• при получении события сервис уведомлений сохраняет тело алерта в таблицу разрешений;
• фоновая задача раз в минуту продлевает время жизни таких алертов в Alertmanager (на RESOLVE_PERIOD, по умолчанию 2 минуты);
• когда индикатор возвращается в норму, запись удаляется, Alertmanager перестаёт получать продление и переводит алерт в состояние resolved;
• уведомление о разрешении уходит по тем каналам адресата, у которых включён параметр Отправлять resolve.

Записи о разрешении также очищаются при выключении подписки, выключении привязки индикатора здоровья и при удалении КЕ.

Параметры фоновой обработки описаны в разделе Cервис уведомлений.

Подавление менее критичных состояний

Чтобы при ухудшении состояния индикатора не приходило несколько уведомлений подряд, в конфигурацию Alertmanager по умолчанию входит набор правил подавления — по одному на каждый уровень критичности. Алерт с более высоким значением value подавляет алерты с меньшим значением, если у них совпадают индикатор (tql_hi_link_id), подписчик (user_id) и исходный алерт (fingerprint). Ниже — правило, подавляющее уведомление об уровне Ок, пока тот же индикатор находится в худшем состоянии; остальные правила устроены так же.

inhibit_rules:
  - source_matchers:
      - event_type = "monitoring.hi.Changed"
      - value =~ "^[3-5]$"
    target_matchers:
      - event_type = "monitoring.hi.Changed"
      - value = "2"
    equal:
      - tql_hi_link_id
      - user_id
      - fingerprint

Правила подавления доступны для просмотра и редактирования в разделе Настройки → Уведомления → Правила подавления (см. Правила подавления) и входят в итоговую конфигурацию Alertmanager.

Особенности и ограничения

• Подписка оформляется на привязку индикатора здоровья к узлу TQL, а не на отдельную КЕ. Уведомления придут по всем КЕ, попадающим в узел TQL шаблона мониторинга.
• Системное имя подписки уникально в пределах установки Памир и не изменяется после создания.
• Удаление привязки индикатора здоровья удаляет все связанные с ней подписки.
• Удаление адресата не удаляет подписку: она остаётся, но перестаёт формировать маршрут доставки, пока не будет выбран новый адресат (или включена доставка в браузер).
• Удаление пользователя удаляет все его подписки.
• Подписка привязана к адресатам своего владельца: чужой адресат выбрать нельзя.

Администрирование подписок и адресатов

Подписки и адресаты заводятся каждым пользователем для себя, поэтому по отдельности они не видны ни другим пользователям, ни администратору. Два реестра в разделе Настройки → Уведомления показывают их по всей установке: Подписки — все подписки на индикаторы здоровья, Адресаты — всех адресатов. Личные страницы при этом не меняются: пользователь по-прежнему заводит подписки на вкладке шаблона мониторинга, а адресатов — в разделе Уведомления → Адресаты.

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

Реестр подписок

Строка реестра показывает отображаемое и системное имя подписки, логин владельца, индикатор здоровья с шаблоном мониторинга и узлом TQL, выбранные уровни критичности, адресата и состояние.

Отдельная колонка Доставка отвечает на вопрос, дойдёт ли уведомление. У работающей подписки в ней перечислены каналы адресата и, если включена доставка в браузер, отметка В браузере. Метка Не доставляется означает, что подписка включена, но маршрут не попадёт в конфигурацию Alertmanager:

• адресат не задан, браузер выключен — адресат был удалён, а подписка осталась;
• у адресата нет активных каналов — все каналы адресата выключены или выключены их отправители.

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

Реестр фильтруется по названию и системному имени, владельцу, состоянию и адресату; сортируется по названию, владельцу, адресату и состоянию. Список подгружается страницами по мере прокрутки.

Действия администратора

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

Карточка подписки открывается на чтение и показывает то, что не помещается в таблицу: системное имя, узел TQL, интервалы группировки и напоминания, признак группировки и расширенный фильтр событий. Из карточки и из меню строки можно перейти к индикатору здоровья в шаблоне мониторинга.

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

подсказка

Массовые действия выполняются одной операцией: конфигурация Alertmanager пересобирается и проверяется один раз на всю выборку, а не на каждую подписку.

Реестр адресатов

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

Серый бейдж канала означает, что канал выключен, отдельная метка отправитель отключён — что выключен сам отправитель. Если ни один канал адресата не попадёт в конфигурацию Alertmanager, в колонке состояния появляется Нет активных каналов; переключатель Только проблемные оставляет таких адресатов. Число подписок ведёт в реестр подписок, отфильтрованный по этому адресату.

Реестр фильтруется по названию, владельцу и отправителю.

Удаление адресата

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