Производные метрики

Производные метрики (recording rules) рассчитываются на основе других метрик с использованием выражений PromQL и сохраняются как отдельные временные ряды.

Они используются в случаях, когда исходный PromQL-запрос:

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

Производные метрики описываются в группах правил и задаются как элементы массива spec.rules. Если у правила указано поле record, оно считается правилом вычисления производной метрики.

Виды групп правил с производными метриками

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

Описание типов групп правил:

• Системные группы правил (ClusterObservabilityMetricsRulesGroup) — используются для вычисления производных метрик уровня платформы и компонентов кластера. Создаются и управляются администраторами DKP.

• Проектные группы правил (ObservabilityMetricsRulesGroup) — используются для вычисления производных метрик в рамках конкретного проекта (неймспейса). Пользователи проекта могут создавать и редактировать их в рамках настроенных прав доступа.

• Общедоступные (propagated) группы правил (ClusterObservabilityPropagatedMetricsRulesGroup) — создаются на уровне кластера и автоматически становятся доступны во всех проектах.

Производные метрики из логов (LogQL)

Помимо производных метрик на основе метрик, модуль позволяет вычислять производные метрики из логов с помощью LogQL. Метрики вычисляются сервисом logs-ruler, который выполняет LogQL-запросы к бэкенду хранения логов в кластере, а полученные ряды экспонируются как обычные метрики Prometheus.

Типы групп правил для метрик из логов:

Поддерживаются только правила производных метрик (поля record и expr).

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

В группах правил уровня проекта выражения LogQL автоматически ограничиваются неймспейсом ресурса. Не используйте в stream-селекторах лейбл namespace, поскольку модуль автоматически подставляет его с учётом текущего проекта.

К каждому записанному временному ряду автоматически добавляются следующие платформенные лейблы: scope_type (namespaced или cluster), created_by=observability, rule_group_name и namespace (для уровня проекта). Эти лейблы зарезервированы и не могут задаваться пользователем.

Пример

Далее приведён пример, в котором LogQL вычисляет и записывает производную метрику из логов, после чего для неё создаётся триггер алерта.

1. Запись производной метрики из логов (уровень проекта):

   apiVersion: observability.deckhouse.io/v1alpha1
   kind: ObservabilityLogsRulesGroup
   metadata:
     name: app-errors
     namespace: my-project
   spec:
     interval: 1m
     rules:
       - record: app_log_errors_per_second
         expr: 'sum(rate({app="my-app"} |= "error" [5m]))'

2. Создание триггера алерта для записанной метрики через группу правил:

   apiVersion: observability.deckhouse.io/v1alpha1
   kind: ObservabilityMetricsRulesGroup
   metadata:
     name: app-errors-alerts
     namespace: my-project
   spec:
     rules:
       - alert: AppLogErrorsHigh
         expr: 'app_log_errors_per_second > 1'
         for: 5m
         labels:
           severity: S5
         annotations:
           summary: "Высокая частота ошибок в логах my-app"