Блог

Я использую alertmanager для получения предупреждений для метрик prometheus, у меня разные правила предупреждений для разных метрик, можно ли установить разные интервалы для каждого правила предупреждений, например, для metric1 у меня есть правило 1, и мне нужно проверять это правило на ежедневном базовом интервале, а для metric2 у меня есть правило 2, и это должно проверяться каждые 2 часа,

for: 5m Свойство используется для обеспечения того, чтобы правило возвращало значение true в течение X непрерывных минут до запуска предупреждения. Например, в случае резкого увеличения загрузки процессора в течение 30 секунд предупреждение не будет вызвано, поскольку мы установили для этого for свойства значение 5 минут. Следовательно, это не подходящее свойство для вас.

Я считаю, что вы можете использовать repeat_interval диспетчер предупреждений, чтобы установить интервал времени для отправки уведомлений. Тогда у вас есть предупреждение, но вы запускаете/запускаете его в зависимости от вашего repeat_interval . Эта ссылка подробно объясняет их.

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

Чтобы заставить их работать, вы должны определить label » s » для каждого предупреждения. Например, в моем alerts.yml файле я создаю метки app_type: server и app_type: service :

 groups:
- name: monitor_cpu
  rules:
  - alert: job:node_cpu_usage:percentage_gt_50
    expr: 100 * node_cpu_seconds_total{mode="user"} / ignoring(mode) group_left sum(node_cpu_seconds_total) without(mode) > 5.5
    for: 1m
    labels:
      severity: critical
      app_type: server
    annotations:
      summary: "High CPU usage"
      description: "Server {{ $labels.instance }} has high CPU usage."
- name: targets
  rules:
  - alert: monitor_service_down
    expr: up == 0
    for: 1m
    labels:
      severity: critical
      app_type: service
    annotations:
      summary: "Monitor service non-operational"
      description: "Service {{ $labels.instance }} is down."
 

затем я создаю дерево маршрутов для отправки уведомлений различным группам, сопоставляя конкретную метку. И вот приходит решение, которое я использую. Я определяю разные group_wait , group_interval , и repeat_interval для каждой группы. Затем вы можете использовать repeat_interval: 1h и repeat_interval: 24h то и другое в разных routes листах:

 global:
  smtp_from: 'mail@gmail.com'
  smtp_smarthost: smtp.gmail.com:587
  smtp_auth_username: 'mail@gmail.com'
  smtp_auth_identity: 'mail@gmail.com'
  smtp_auth_password: ''

route:
  receiver: 'admin-team'
  routes:
    - match_re:
        app_type: (server|service)
      receiver: 'admin-team'
      routes:
      - match:
          app_type: server
        receiver: 'admin-team'
        group_wait: 1m
        group_interval: 5m
        repeat_interval: 1h
      - match:
          app_type: service
        receiver: 'dev-team'
        group_wait: 1m
        group_interval: 5m
        repeat_interval: 24h

receivers:
 - name: 'admin-team'
   email_configs:
   - to: 'admin-mail@gmail.com'

 - name: 'dev-team'
   email_configs:
   - to: 'dev-mail@gmail.com'

 

К сожалению, я тестировал не 24 часа, а с другим промежутком в несколько минут, и это сработало. Я думаю, что это будет работать и в течение долгих часов.