Какие знаешь виды метрик в Prometheus?

Виды метрик в Prometheus

Как DevOps-инженер с более чем 10-летним опытом работы с мониторингом, я глубоко понимаю систему метрик Prometheus — это фундаментальный инструмент для observability в современной инфраструктуре. Prometheus оперирует четырьмя основными типами метрик, каждый из которых служит для определённого класса наблюдений.

1. Counter (Счётчик)

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

# Пример метрики-счётчика в PromQL
http_requests_total{method="POST", handler="/api/users"}

Ключевые характеристики:

• Значение всегда неотрицательное.
• В PromQL с ним часто используют функции rate(), increase() и irate() для анализа скорости изменения (например, запросов в секунду).
• Типичные use-case: requests_total, errors_total, tasks_completed_total.

2. Gauge (Измеритель)

Gauge — это метрика, представляющая числовое значение, которое может произвольно увеличиваться и уменьшаться. Это "мгновенный снимок" состояния системы в конкретный момент времени.

# Пример запроса к метрике-измерителю
node_memory_Active_bytes

Ключевые характеристики:

• Отражает текущее состояние: использование памяти, загрузку CPU, температуру, количество активных соединений, размер очереди.
• Для работы с ними в PromQL применяются функции типа delta(), deriv(), а также арифметические операции.
• Типичные use-case: memory_usage_bytes, cpu_temperature_celsius, queue_length, connections_active.

3. Histogram (Гистограмма)

Histogram — это сложная, но чрезвычайно мощная метрика для анализа распределения наблюдаемых величин (чаще всего — задержек/латентности). Она автоматически группирует (бакетирует) наблюдения в предопределённые интервалы.

Как она работает: При создании гистограммы (например, http_request_duration_seconds) клиентская библиотека Prometheus создаёт несколько временных рядов:

• <metric_name>_bucket{le="<upper_bound>"} — счётчики для каждого бакета (например, запросы быстрее 0.1s, 0.5s, 1.0s).
• <metric_name>_sum — сумма всех наблюдаемых значений.
• <metric_name>_count — общее количество наблюдений (эквивалентно Counter).

# Пример расчёта 95-го перцентиля задержки ответа за последние 5 минут
histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

Ключевые характеристики:

• Позволяет вычислять произвольные процентили (quantiles) уже после сбора данных.
• Требует предварительного определения границ бакетов (le — less or equal). Выбор границ критически важен для точности.
• Потребляет больше ресурсов, чем Counter или Gauge, из-за множества создаваемых рядов.
• Идеальна для измерения: длительности запросов, размеров ответов, времени выполнения batch-задач.

4. Summary (Сводка)

Summary — похожа на Histogram, так как тоже предназначена для анализа распределения, но работает по иному принципу. Она вычисляет процентили на стороне клиента (в приложении/агенте) до отправки метрик в Prometheus.

Как она работает: Клиентская библиотека поддерживает скользящее окно наблюдений и сразу вычисляет квантили (например, медиану, 90-й и 99-й перцентили). В Prometheus отправляются готовые значения:

• <metric_name>{quantile="<φ>"} — значение для конкретного процентиля φ (например, 0.5, 0.9, 0.99).
• <metric_name>_sum — сумма всех значений.
• <metric_name>_count — общее количество наблюдений.

// Пример создания Summary в клиентской библиотеке Go
requestDuration := prometheus.NewSummary(prometheus.SummaryOpts{
    Name: "http_request_duration_seconds",
    Help: "Duration of HTTP requests.",
    Objectives: map[float64]float64{0.5: 0.05, 0.9: 0.01, 0.99: 0.001}, // φ → допустимая погрешность
})

Ключевые характеристики:

• Процентили вычисляются на клиенте, что делает запросы в PromQL к ним быстрыми и простыми (просто выбрать готовый временной ряд).
• Не позволяет вычислять процентили агрегированных данных (например, по нескольким инстансам приложения) — это главный минус по сравнению с Histogram.
• Параметры квантилей (и их погрешности) задаются статически на стороне клиента и не могут быть изменены постфактум.
• Потребляет меньше ресурсов на стороне сервера (Prometheus), но больше CPU на стороне клиента.

Сравнительная таблица и рекомендации

Мой практический совет: Для измерения латентности в распределённых системах предпочтительнее использовать Histogram. Несмотря на сложность настройки бакетов, она предоставляет гораздо большую гибкость при анализе, позволяя вычислять любые процентили по агрегированным данным со всех инстансов сервиса. Summary стоит выбирать, когда вам нужны точные, предопределённые квантили для конкретного инстанса, и вы готовы мириться с невозможностью их глобальной агрегации. Counter и Gauge — это ваши основные "рабочие лошадки" для подсчёта событий и измерения состояний соответственно.