Повторно используемые константы в правилах оповещений Prometheus

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

Содержание

• Почему Prometheus не поддерживает раздел констант
• Решение 1: Правила записи для динамических порогов
• Решение 2: Внешние метки для статических порогов
• Решение 3: Организация правил в нескольких файлах
• Решение 4: Подходы на основе шаблонов
• Лучшие практики управления порогами
• Расширенный: Пороги на основе метрик

Почему Prometheus не поддерживает раздел констант

Правила оповещений и записи Prometheus разработаны для работы с метриками и временными рядами данных, а не со статичными значениями конфигурации. Как показано в GitHub issue #1905, пользователи давно запрашивали возможность разделения констант от правил, но эта функция не была реализована в основной конфигурации Prometheus.

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

Решение 1: Правила записи для динамических порогов

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

groups:
- name: Пороги
  rules:
  - record: error_rate_threshold:warning
    expr: 0.05  # Порог предупреждения 5%
  - record: error_rate_threshold:critical
    expr: 0.10  # Критический порог 10%

- name: Сервис UI
  rules:
  - alert: HighErrorRate
    expr: calculation > error_rate_threshold:critical
    for: 10m
    labels:
      severity: critical
      title: "Ошибки превышают 10%"
    annotations:
      description: "Процент ошибок: {{ $value }}, порог: 10%"

Преимущества:

• Централизованное управление порогами
• Динамические пороги на основе других метрик
• Легкость модификации и поддержки
• Работает с любыми расчетами метрик

Как объясняется в статье на FAUN.dev, этот подход позволяет создавать “универсальные правила оповещений” с использованием правил записи в качестве пороговых переменных.

Решение 2: Внешние метки для статических порогов

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

# prometheus.yml
global:
  external_labels:
    error_rate_warning_threshold: "0.05"
    error_rate_critical_threshold: "0.10"

Затем ссылайтесь на них в правилах оповещений:

groups:
- name: Сервис UI
  rules:
  - alert: HighErrorRate
    expr: calculation > on() group_left() $externalLabels{"error_rate_critical_threshold"}
    for: 10m
    labels:
      severity: critical

Ограничения:

• Внешние метки фиксированы при запуске и не могут быть изменены без перезапуска Prometheus
• Синтаксис может быть сложным для использования в выражениях оповещений
• Наиболее подходит для действительно статичных значений

Решение 3: Организация правил в нескольких файлах

Организуйте ваши правила в отдельные файлы и используйте базовый файл для общих констант:

init.rules:

# Определения порогов
prod:disk_used_percent:warning = 80
prod:disk_used_percent:critical = 95
test:disk_used_percent:warning = 85
test:disk_used_percent:critical = 98

rules/ui-service.rules:

groups:
- name: Сервис UI
  rules:
  - alert: HighErrorRate
    expr: calculation > prod:error_rate_threshold:critical
    for: 10m
    labels:
      severity: critical

Преимущества:

• Четкое разделение ответственности
• Пороги, специфичные для окружения
• Легкость управления и обновления
• Соответствует шаблону, предложенному в GitHub issue #1905

Решение 4: Подходы на основе шаблонов

Используйте обработку шаблонов перед загрузкой правил в Prometheus:

1. Использование Helm или других шаблонизаторов:

# templates/alerts.yaml
groups:
- name: "{{ .Release.Name }} Service"
  rules:
  - alert: HighErrorRate
    expr: calculation > {{ .Values.thresholds.critical }}
    for: 10m

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

# ansible/roles/prometheus/templates/alerts.yml.j2
groups:
- name: Сервис UI
  rules:
  - alert: HighErrorRate
    expr: calculation > {{ prometheus_thresholds.critical }}

Преимущества:

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

Лучшие практики управления порогами

1. Пороги, специфичные для окружения: Определяйте различные пороги для production, staging и development окружений.

2. Пороги на основе метрик: Используйте правила записи для создания порогов на основе других метрик, как описано в статье PromLabs.

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

4. Документация: Документируйте ваши пороги и их обоснование в комментариях или отдельных файлах документации.

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

Расширенный: Пороги на основе метрик

Для сложных сценариев можно создавать динамические пороги на основе других метрик:

groups:
- name: Динамические пороги
  rules:
  # Порог CPU на основе количества ядер
  - record: cpu_threshold_warning
    expr: 80 * count(cpu_cores) / 100
  - record: cpu_threshold_critical
    expr: 90 * count(cpu_cores) / 100

- name: Оповещения узлов
  rules:
  # Оповещение с использованием динамического порога
  - alert: HighCPUUsage
    expr: rate(cpu_usage_total[5m]) > cpu_threshold_critical
    for: 5m
    labels:
      severity: critical

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

Заключение

Хотя Prometheus не поддерживает нативный раздел constants в правилах оповещений, вы можете эффективно управлять многоразовыми порогами с помощью этих подходов:

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

2. Организация в нескольких файлах: Разделяйте определения порогов от правил оповещений для лучшей поддерживаемости.

3. Внешние метки: Подходят для статичных, редко изменяющихся пороговых значений.

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

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

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

Источники

1. Правила оповещений | Документация Prometheus
2. Определение правил записи | Документация Prometheus
3. GitHub issue #1905: Правила оповещений с “константами”
4. Создание универсальных правил оповещений с Prometheus
5. Использование порогов на основе метрик в правилах оповещения Prometheus
6. Определение общих правил оповещения Prometheus с разными порогами для каждого сервиса