Типы метрик Prometheus: counter, gauge, histogram, summary

Prometheus опирается на понятие метрик как времени ряда с идентификаторами по значениями метрик и набору ярлыков (labels). Правильная выборка типа метрик, аккуратная настройка ярлыков и грамотная архитектура сбора данных позволяют строить устойчивые аналитические запросы, ранжировать латентности и понимать динамику системы в реальном времени. В этой главе рассмотрены четыре базовых типа метрик Prometheus: counter, gauge, histogram и summary. Для каждого типа раскрываются семантика, характерные паттерны использования, ограничения хранения и практические примеры в промышленной среде DevOps и Data Engineering. Особое внимание уделяется архитектурным и рациональным аспектам: как выбирать типы для разных сценариев, как минимизировать избыточность ярлыков, как решать задачи агрегации и анализа временных рядов в рамках Prometheus и смежных систем.

Краткое содержание главы

Разбор семантики и архитектурных особенностей каждого типа: counter, gauge, histogram, summary.
Как правильно использовать и агрегировать данные на уровне PromQL, какие сценарии требуют histogram и какие - summary.
Вопросы хранения и производительности: влияние на TSDB, выбор bucket’ов и конфигураций, управление cardinality.
Практические принципы внедрения и интеграций: instrumentation, рекомендуемые паттерны, ограничения.

Основные принципы и архитектура метрик Prometheus

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

Ключевые концепции:

метрика - это временной ряд: имя + ярлыки + значения в моменты времени;
метрики снабжаются ярлыками, которые позволяют сегментировать данные по сервисам, среде выполнения, региону и пр.; излишняя высока cardinality ярлыков может привести к ухудшению производительности и перегрузке TSDB;
бурные данные (histogram) и квантильные оценки (summary) требуют особого подхода к агрегациям: histograms позволяют аггрегировать распределения по сервисам и географиям, в то время как summaries позволяют получать локальные квантильные оценки, но не всегда пригодны для глобального агрегационного анализа;
хранение и обработка результатов зависят от настройки bucket’ов для histogram и от параметров коррекции точности в summary.

Рациональная архитектура сбора метрик учитывает hammered effect на сеть и нагрузку на TSDB. Применение remote_write позволяет агрегировать или архивировать данные в долгосрочные хранилища, что особенно важно при больших объемах трассировки и латентностей. Важным следствием является необходимость ограничения Cardinality - количество уникальных наборов ярлыков. В противном случае Prometheus может столкнуться с перерасходом памяти и дискотеки хранённых серий.

Counter и Gauge: базовые типы

Counter представляет собой счетчик, который растет или обнуляется только при перезапуске приложения или явной ресет-функции. Он подходит для подсчета количества событий, объёма переданных данных и других кумулятивных метрик. Ключевая особенность - монотонность, то есть значения не уменьшаются. Это позволяет устойчиво рассчитывать скорость изменений через функции rate() и increase() в PromQL. Gauge описывает текущую величину во времени: может расти и падать, например уровень загрузки процесса, длина очереди или использование памяти. В Gauge не предусмотрена монотонность.

Архитектурные моменты:

Counter и Gauge экспортируются одним и тем же способом через exposition format (OpenMetrics), но семантика различна: Counter - монотонный, Gauge - произвольный;
При переработке кода и релизах сервисов важна консистентая схема именования и единообразная обработка reset’ов Counter’а;
Обе метрики могут быть агрегированы в PromQL: sum, rate, irate, increase и т. д. В контексте Grafana и безопасной постановки SLA такие агрегаты применяются для мониторинга нагрузки и устойчивости.

Практический пример (Kotlin/Java на базе библиотек Micrometer Prometheus или Prometheus Java Client):

Counter: инкремент на каждый обработанный HTTP-запрос;

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

import io.prometheus.client.Counter;
import io.prometheus.client.Gauge;

public class Instrumentation {
    static final Counter requestTotal = Counter.build()
        .name("http_requests_total")
        .help("Total HTTP requests.")
        .register();

    static final Gauge queueLength = Gauge.build()
        .name("queue_length")
        .help("Current queue length.")
        .register();

    public void handleRequest() {
        requestTotal.inc();
        // ... обработка запроса
        queueLength.set(currentQueueSize());
    }
}

Объяснение:

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

Практика использования:

Counter хорошо применять для метрик бизнес- и инфраструктурной активности, где важно видеть рост или падение количества операций;
Gauge широко применим для текущих значений системных ресурсов: памяти, CPU-usage, количеством элементов в очереди и пр.

Histogram: распределения латентности и интервалов

Histogram отражает распределение наблюдений по предопределенным bucket’ам (границам). Каждая bucket имеет собственный временной ряд и хранит количество наблюдений, у которых наблюдаемое значение <= le(x). В дополнение к каждому histogram-объекту предоставляются две служебные метрики: _sum и _count. Это позволяет вычислять среднюю величину наблюдений и полное количество наблюдений за указанный период времени.

Архитектура и принципы:

bucket’ы задаются как массив порогов (например, [0.1, 0.2, 0.5, 1, 2, 5, 10] секунд);
в итоговом графе для latency-метрик можно вычислять процентильные значения через histogram_quantile, который аппроксимирует квантиль на основе распределения из bucket’ов;
суммарная работа histogram увеличивает нагрузку на Prometheus, поскольку каждая новая точка создаёт новую серия для каждого bucket’а и для _sum и _count. При большом числе ярлыков и bucket’ов следует внимательно контролировать cardinality.

Пример конфигурации распределения и использование PromQL:

Типичный пример латентности HTTP-запросов;

PromQL запросы для вычисления квантилей и распределений.

## Пример конфигурации histogram в коде
prometheus.NewHistogram(prometheus.HistogramOpts{
## Name:    "http_request_duration_seconds",
    Help:    "Histogram of latencies for HTTP requests.",
    Buckets: []float64{0.01, 0.05, 0.1, 0.25, 0.5, 1.0, 2.5, 5.0},
})

## Пример PromQL для квантильной оценки 95-го процентиля
histogram_quantile(0.95,
  sum(rate(http_request_duration_seconds_bucket[5m])) by (le)
)

Общие принципы:

Хранение и агрегация histograms хорошо подходит для анализа задержек на уровне сервисов, регионов и экземпляров. С ростом числа ярлыков сумма временных рядов может стать значительной, поэтому требуется внимательное планирование bucket’ов и политики маркировки;
Если цель - детальная агрегация распределений между сервисами, histogram предпочтительнее, чем summary, потому что агрегирование по _bucket, _sum и _count поддерживает cross-service анализ.

Паттерны применения:

Latency monitoring и SLA-метрики: распределение времени обработки, чтобы выявлять узкие места и регрессионные сбои;
Максимтизация throughput: анализ распределения времени обслуживания и очередности операций;
Агрегируемые показатели через PromQL: суммарные скорости, rate и агрегированные квантильные оценки.

Summary: квантильные оценки и особенности агрегаций

Summary собирает статистику наблюдений на стороне клиента и сохраняет два базовых поля: _sum и _count, плюс набор квантильных точек (quantiles) с заданной погрешностью. В отличие от histogram, Summary не предназначен для эффективной агрегации Across инстансов: квантильные значения должны рассчитываться локально в каждом экземпляре и затем агрегироваться другим способом, что делает cross-service сравнение намного сложнее и потенциально менее точным. Такой подход может быть приемлем в случаях, когда важно держать точные локальные квантильные оценки или когда задержки не требуют глобальной агрегации.

Ключевые чинники выбора:

Применение Summary целесообразно, когда требуется локальная квадранная оценка (на уровне сервиса и внутри конкретной инстанции) и глобальная агрегация не требуется;
При необходимости агрегаций по сервисам, кластерам или регионам предпочтительнее Histogram, где можно построить агрегацию across instances через PromQL;
Summary может потреблять большую память, особенно при большом числе наблюдений и заданной точности квантилей.

Пример конфигурации Summary и пояснения:

prometheus.NewSummary(prometheus.SummaryOpts{
## Name:       "request_duration_seconds",
    Help:       "Request duration in seconds with quantiles.",
    Objectives: map[float64]float64{0.5: 0.05, 0.9: 0.01, 0.99: 0.001},
})

Пояснение:

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

Преимущества и ограничения Summary:

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

Выбор между Histogram и Summary и вопросы хранения

Разработка instrumentation и архитектура мониторинга требует понимания того, как данные будут использоваться в аналитике. Основные различия между histogram и summary влияют на архитектуру хранения и эксплуатацию:

Агрегации и глобальные показатели:
- Histogram позволяет легко агрегировать распределения по всем инстансам, сервисам и регионам через PromQL: sum(rate(http_latency_seconds_bucket[5m])) by (le) и затем использование histogram_quantile для вычисления квантилей на глобальном уровне.
- Summary ограничивает агрегации квантильной части и чаще приводит к локальным квантильным оценкам. Глобальные квантильные значения требуют дополнительных подходов (например, продуманной архитектуры сбора с редукцией, использованием histogram в качестве основного источника и ремаппинга квантилей).
Ограничения по памяти и производительности:
- Histogram требует хранения по каждому bucket’у вместе с _sum и _count на каждом ярлыке. Это может привести к быстрому росту числа временных рядов при большом числе ярлыков.
- Summary хранит локальные квантильные точки вместе с суммой и количеством наблюдений. При высокой частоте событий и большом числе ярлыков суммарная нагрузка может быть не менее значимой, но агрегация квантилей затруднена.
Cardinality и архитектура развертывания:
- Необходимо минимизировать ярлыки, особенно в высоконагруженных сервисах. Выбор между histogram и summary должен основываться на том, какие вопросы мониторинга являются критичными: глобальные распределения или локальные квантильные оценки.
Вопросы внедрения и интеграции:
- Для latency-портфеля на уровне инфраструктуры и сервисов, histogram чаще является предпочтительным, поскольку позволяет гибко агрегировать данные. Для специфических ситуаций, где локальная квантильная оценка нужна без глобальной агрегации, summary может быть использована, однако нужно заранее определить, как будет происходить агрегирование.

Практические принципы внедрения:

Планирование bucket’ов: выбирайте разумные границы, отражающие реальную латентность операций. Включайте как низкие, так и высокие пороги, чтобы охватить пик и краевые сценарии.
Минимизация ярлыков: используйте только те ярлыки, которые действительно необходимы для фильтрации и агрегации. Избегайте высокодименсиональных ярлыков, не связанных с аналитическими целями.
Архитектура хранения: при необходимости долгосрочной аналитики рассмотрите remote_write к ВР-системам или прочим хранилищам, чтобы не перегружать локальный Prometheus-инстанс.

Применение на практике:

Latency dashboards: histogram → histograms позволяют строить графики по квантильям через histogram_quantile; это мощный подход для SLA и SLO анализа.
Системные показатели: Counter и Gauge используются для метрик активности и состояния, сочетаются с histogram для контекстной детализации и диагностики.

Key takeaways

Counter - монотонный счетчик событий; Gauge - текущая величина, которая может расти и уменьшаться.
Histogram предоставляет распределения наблюдений через bucket’ы, _sum и _count и поддерживает квантильные вычисления через histogram_quantile.
Summary обеспечивает локальные квантильные оценки с указанием objectives, но агрегация квантилей Across инстансов ограничена и требует осторожности.
Выбор между histogram и summary зависит от требований к агрегациям, точности квантилей и объема ярлыков; histogram чаще подходит для глобального анализа, summary - для локальных оценок.
При проектировании метрик следует минимизировать ярлыки и планировать bucket’ы, чтобы обеспечить управляемую нагрузку на Prometheus и TSDB.
Интеграции и хранение: для масштабируемых сценариев рекомендуется рассмотреть remote_write и долгосрочные хранилища, разумно сочетать Prometheus с Grafana и соответствующими инструментами анализа.

FAQ

Чем отличаются histogram и summary по семантике и применению?

Histogram предоставляет распределение наблюдений через набор bucket’ов, что позволяет агрегировать распределения по множеству инстансов и вычислять квантильные значения через histogram_quantile. Summary хранит локальные квантильные оценки и не поддерживает эффективную глобальную агрегацию квантилей, поэтому он лучше подходит для локального мониторинга без необходимости глобального агрегационного анализа.

Какой тип метрики лучше использовать для латентности HTTP-запросов?

В большинстве сценариев лучше использовать histogram, потому что он поддерживает глобальную агрегацию по сервисам и регионам и позволяет строить квантильные оценки через PromQL. Summary полезен, если требуется локальная оценка конкретного сервиса и если агрегации квантилей Across инстансов не нужны.

Какие риски связаны с высокой кардинальностью ярлыков и как их избежать?

Высокая кардинальность приводит к росту числа временных рядов, что может перегрузить Prometheus и увеличить требования к памяти. Решение - ограничить ярлыки до тех, что действительно необходимы для анализа; применить relabeling, агрегацию на стороне scrape-конфига и избегать включения уникальных идентификаторов в ярлыки, если они не критичны для мониторинга.

Как правильно выбирать bucket’ы для histogram?

Bucket’ы должны отражать реальные пороги задержек в вашей системе. Начните с разумного набора, включайте как нижние, так и верхние пороги, чтобы не пропустить характерные пики, и затем корректируйте по мере анализа данных. Избыточное количество bucket’ов повышает стоимость памяти и времени обработки.

Как интерпретировать результаты PROMQL для histogram?

Для квантильной оценки используйте histogram_quantile, например: histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)). Это позволяет получить 95-й процентиль распределения латентности за последние 5 минут на агрегированном уровне.

Что учитывать при применении Summary в продакшене?

Summary может потреблять больше памяти при высокой частоте наблюдений и имеет ограниченную совместимость с глобальной агрегацией квантилей. Используйте Summary только если локальные квантильные оценки критичны и глобальная агрегация не требуется. В противном случае предпочтительнее histogram.

Как связать выбор типов метрик с архитектурой хранения и долгосрочного анализа?

Histogram лучше подходит для глобальной аналитики и долгосрочного анализа распределений, так как он легко агрегируется Across инстансов. Summary полезен для локального мониторинга, но для долгосрочного анализа лучше хранить данные в histogram и использовать remote_write для экспорта в долгосрочные хранилища.

Какие практики внедрения помогают снизить влияние на производительность?

Ограничение Cardinality, разумное планирование ярлыков, минимизация количества bucket’ов, используя подходящие стратегии шардирования и агрегирования, а также применение remote_write для архивации в сторонние хранилища.

Какие примеры инструментальных решений стоит учитывать при работе с Prometheus и метриками?

Популярные open-source решения включают Prometheus и Grafana; для долгосрочного хранения - сторонние плагины и сервисы, поддерживающие remote_write, например Cortex или Thanos (примеры на выбор). В рамках российского контекста - ограниченные интеграции, но можно опираться на общие подходы к экспортерам и клиентским библиотекам.

Как тестировать instrumentation и корректность метрик?

Применяйте тестовые сценарии instrumentation, валидируйте, что метрики отражают ожидаемые значения в тестовой среде, проверьте корректность reset’ов Counter и поведения Gauge, а также корректность bucket’ов и квантилей для histogram и summary. Важно проверить совместимость PromQL-выражений с вашим стеком мониторинга.

Как начать миграцию с Summary на Histogram (или наоборот) при отсутствии глобальной квантильной агрегации?

Начните с анализа целей мониторинга: если глобальные квантильные значения критичны для SLA, prefer histogram. Если же локальные квантile важны, можно временно поддерживать Summary и постепенно внедрять histogram для агрегации Across инстансов. При переходе обеспечьте совместимость дашбордов и сохраните совместимость PromQL-запросов, постепенно перенаправляя запросы на новой схеме агрегирования.

← Предыдущая статья

Моделирование метрик: имена, лейблы, схемы классификации

Следующая статья →

Язык запросов PromQL: синтаксис, базовые выражения и примеры