Типы метрик в Prometheus: от базовых до расширенных – полный гайд

Для кого эта статья:

• специалисты в области DevOps и SRE
• аналитики данных

• разработчики, работающие с Prometheus и системами мониторинга

  Мониторинг — кровеносная система современной инфраструктуры, а метрики в Prometheus — лучший способ измерить ее пульс. Если вы когда-либо пытались разобраться, почему продакшен-система деградирует, не имея правильного набора метрик, вы знаете эту боль. В 2025 году понимание разницы между Counter, Gauge, Histogram и Summary уже не преимущество, а необходимость. Этот гайд станет вашей картой в мире метрик Prometheus — от базовых инструментов наблюдения до расширенных конструкций, позволяющих предугадывать проблемы еще до их появления. 🚀

Хотите стать профессионалом, способным не только читать метрики, но и анализировать данные на глубинном уровне? Курс «Аналитик данных» с нуля от Skypro поможет вам выйти за рамки обычного мониторинга. Даже если вы мастерски работаете с Prometheus, понимание аналитических моделей и статистических подходов к данным откроет новые возможности для оптимизации вашей инфраструктуры. От базовых концепций до продвинутых техник — ваше путешествие к аналитическому мышлению начинается здесь!

Четыре основных типа метрик Prometheus и их особенности

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

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

// Пример объявления Counter в Go
requestsTotal = prometheus.NewCounter(
prometheus.CounterOpts{
Name: "http_requests_total",
Help: "Total number of HTTP requests",
},
)

Gauge (Датчик) — метрика, представляющая значение, которое может как увеличиваться, так и уменьшаться. Gauge идеально подходит для измерения текущих значений, таких как температура, использование памяти или количество активных соединений.

# Пример объявления Gauge в Python
memory_usage = Gauge('memory_usage_bytes', 'Memory usage in bytes')

Histogram (Гистограмма) — сложный тип метрики, который позволяет отслеживать распределение значений, таких как время запроса или размер ответа. Histogram разбивает измерения на интервалы (buckets) и подсчитывает, сколько наблюдений попало в каждый интервал.

// Пример объявления Histogram в Java
static final Histogram requestLatency = Histogram.build()
.name("http_request_duration_seconds")
.help("Request duration in seconds")
.buckets(0.05, 0.1, 0.5, 1.0, 5.0)
.register();

Summary (Сводка) — похож на Histogram, но вычисляет скользящие квантили на стороне клиента. Summary позволяет точно определить процентили (например, p95, p99) без необходимости предварительно определять buckets, но требует больше ресурсов и памяти.

// Пример объявления Summary в Go
requestDuration = prometheus.NewSummary(
prometheus.SummaryOpts{
Name: "http_request_duration_seconds",
Help: "HTTP request duration in seconds",
Objectives: map[float64]float64{0.5: 0.05, 0.9: 0.01, 0.99: 0.001},
},
)

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

Применение базовых метрик Prometheus в повседневных задачах

Алексей Соколов, DevOps-инженер

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

Мы начали с простых Counter для подсчета запросов и ошибок. Базовая формула rate(http_requests_total[5m]) наглядно показала растущие пики нагрузки по понедельникам в 9 утра. Но настоящее открытие пришло, когда мы добавили Gauge для отслеживания очередей сообщений. Оказалось, что один из сервисов не освобождал соединения с базой данных, и в часы пиковой нагрузки пул соединений исчерпывался.

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

Базовые метрики Prometheus — это фундамент, на котором строится вся система мониторинга. Рассмотрим практические примеры их применения в повседневных операциях. 🔧

Мониторинг доступности и производительности:

• Uptime-мониторинг: Используйте метрику типа Gauge up, которая принимает значения 1 (сервис работает) или 0 (сервис недоступен).
• Latency-мониторинг: Histogram http_request_duration_seconds позволяет отслеживать время ответа сервисов.
• Throughput-мониторинг: Counter http_requests_total с меткой method отслеживает количество запросов по типам.

Мониторинг ресурсов и инфраструктуры:

• CPU-утилизация: Gauge node_cpu_seconds_total с последующим применением функции rate().
• Память: Gauge node_memory_MemAvailable_bytes и node_memory_MemTotal_bytes.
• Диски: Gauge node_filesystem_avail_bytes для контроля доступного пространства.
• Сеть: Counter node_network_transmit_bytes_total и node_network_receive_bytes_total для мониторинга сетевого трафика.

PromQL для повседневных задач:

# Процент занятого дискового пространства
100 – ((node_filesystem_avail_bytes / node_filesystem_size_bytes) * 100)

# Rate запросов в секунду за последние 5 минут
rate(http_requests_total[5m])

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

# Соотношение ошибок к общему числу запросов
sum(rate(http_requests_total{status_code=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

Эффективные алерты на основе базовых метрик:

# Алерт на высокую нагрузку CPU
alert: HighCpuLoad
expr: 100 – (avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
for: 5m
labels:
severity: warning
annotations:
summary: "High CPU load (instance {{ $labels.instance }})"
description: "CPU load is > 85%\n VALUE = {{ $value }}\n LABELS: {{ $labels }}"

Грамотное использование базовых метрик Prometheus позволяет не только выявлять проблемы, но и предсказывать их возникновение заранее. Добавление измерений методом RED (Rate, Errors, Duration) или USE (Utilization, Saturation, Errors) к вашим сервисам обеспечит комплексное понимание состояния системы в любой момент времени.

Расширенные метрики Prometheus для глубокого мониторинга

Когда базовые метрики уже настроены, пора переходить к более глубокому уровню мониторинга. Расширенные метрики Prometheus позволяют выйти за рамки простого отслеживания состояния и перейти к пониманию паттернов поведения системы и предиктивному анализу. 🧠

Кастомные метрики для бизнес-процессов:

В 2025 году мониторинг технической инфраструктуры недостаточен — необходимо отслеживать бизнес-метрики непосредственно в коде приложения:

// Пример регистрации бизнес-метрики в Go
paymentSuccessCounter = prometheus.NewCounter(
prometheus.CounterOpts{
Name: "business_payments_success_total",
Help: "Total number of successful payments processed",
},
)

// Где-то в коде обработки платежа
func processPayment() {
// Логика обработки платежа
if paymentSuccessful {
paymentSuccessCounter.Inc()
}
}

Корреляция метрик с помощью меток (labels):

Метки в Prometheus — это мощный инструмент для сегментации и фильтрации метрик. Они позволяют добавить контекст к собираемым данным:

• customer_id: для анализа показателей по клиентам (в B2B-решениях)
• tenant: для multi-tenant-приложений
• feature_flag: для A/B-тестирования новых функций
• deployment_version: для canary-развертываний

// Пример метрики с несколькими метками
http_request_duration_seconds = prometheus.NewHistogramVec(
prometheus.HistogramOpts{
Name: "http_request_duration_seconds",
Help: "Duration of HTTP requests in seconds",
Buckets: prometheus.DefBuckets,
},
[]string{"method", "path", "status_code", "deployment_version"},
)

Экспонентиальные гистограммы в Prometheus 2.40+:

Новый тип гистограмм в Prometheus 2.40 (выпущен в конце 2023) позволяет добиться более высокой точности отслеживания распределения значений с меньшими ресурсными затратами:

// Объявление экспоненциальной гистограммы в Go
prometheusExponentialHistogram := promauto.NewHistogram(prometheus.HistogramOpts{
Name: "http_request_duration_exponential_seconds",
Help: "Duration of HTTP requests using exponential buckets",
Buckets: prometheus.ExponentialBuckets(0.001, 2, 16), // start at 1ms with 16 buckets doubling
})

Recording Rules для агрегации метрик:

Использование recording rules позволяет предварительно вычислить сложные запросы и сохранить результаты, что ускоряет доступ к часто используемым метрикам:

# prometheus.rules.yml
groups:
- name: service_slas
rules:
- record: job:slo_availability_ratio:5m
expr: sum(rate(http_requests_total{status_code=~"2.."}[5m])) / sum(rate(http_requests_total[5m]))
- record: job:error_budget_consumption:1h
expr: (1 – job:slo_availability_ratio:5m) / (1 – 0.995) # При SLO 99.5%

Игорь Петров, SRE-инженер

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

После очередного инцидента мы решили внедрить расширенные метрики. Вместо простого подсчёта RPS добавили Histogram с детализацией по endpoint'ам, типам устройств и даже регионам пользователей. Благодаря этому обнаружили, что при скроллинге каталога мобильное приложение генерировало в 5 раз больше запросов, чем веб-версия.

Самым ценным оказалось использование Exemplars — функции, позволяющей связывать трассировки с метриками. Добавив всего несколько строк кода, мы смогли из графика аномального всплеска latency сразу перейти к детальному trace'у проблемного запроса и увидеть, что он делает N+1 запросов к базе данных.

Оптимизация этого узкого места сократила нагрузку на 40%, а следующая акция прошла без единого инцидента. Теперь я уверен: инвестиции в расширенные метрики — это страховка от будущих проблем.

Exemplars для связывания метрик с трассировкой:

Exemplars — это инновационная функция, позволяющая устанавливать связь между метриками и трейсингом:

histogram_quantile(0.99, sum by(le) (rate(http_request_duration_seconds_bucket[5m]))) # exemplar={ traceID="abcdef123456" }

Многомерный мониторинг с использованием метрик SRE:

• SLO (Service Level Objective): целевые показатели качества сервиса
• SLI (Service Level Indicator): метрики для измерения соответствия SLO
• Error Budget: допустимый уровень отклонения от SLO

# Пример расчета SLI для доступности сервиса
sum(rate(http_requests_total{status_code!~"5.."}[1h])) / sum(rate(http_requests_total[1h]))

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

Применение расширенных метрик — это уже не просто мониторинг, а настоящая аналитика данных. Хотите структурировать свои знания и научиться применять их не только к мониторингу? Пройдите Тест на профориентацию от Skypro, чтобы понять, насколько ваша склонность к анализу данных может стать основой для развития карьеры. Тест поможет определить, где ваши навыки работы с метриками и аналитикой будут наиболее востребованы — в системном администрировании, DevOps, аналитике данных или разработке.

Оптимальные практики настройки различных типов метрик

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

Нейминг и организация метрик по стандартам:

Последовательное именование метрик критически важно для долгосрочного обслуживания:

• Используйте формат namespace_subsystem_name_unit_suffix
• Например: http_server_requests_duration_seconds вместо api_latency
• Документируйте метрики через HELP и TYPE комментарии
• Придерживайтесь единой системы единиц измерения (предпочтительно SI)

Оптимизация карденальности метрик:

Высокая карденальность метрик (большое количество уникальных комбинаций меток) — одна из главных причин проблем с производительностью Prometheus:

• Избегайте использования меток с неограниченным числом значений (user_id, request_id)
• Группируйте значения в категории (status="error" вместо error_code="404")
• Используйте метод семплирования для высоко-кардинальных метрик
• Применяйте topk и аналогичные функции для фокуса на значимых данных

# Вместо этого (высокая кардинальность!)
request_duration_seconds{path="/user/1234/profile", method="GET", status="200"} 

# Используйте это (группировка путей)
request_duration_seconds{path="/user/:id/profile", method="GET", status="2xx"}

Настройка оптимальных buckets для гистограмм:

Правильное определение buckets для гистограмм влияет как на точность, так и на производительность:

// Неоптимальные buckets (слишком мало или неравномерные)
prometheus.LinearBuckets(0, 100, 2) // Только [0, 100]

// Оптимальные buckets для латенси HTTP-запросов
prometheus.ExponentialBuckets(0.001, 2, 10) // [0\.001, 0.002, 0.004, ... 0.512]

// Для memory profiling (в MB)
prometheus.LinearBuckets(100, 100, 10) // [100, 200, 300, ... 1000]

Эффективное использование labels и relabeling:

Relabeling позволяет трансформировать метки перед их сохранением:

# Пример конфигурации relabeling в prometheus.yml
scrape_configs:
- job_name: 'kubernetes-pods'
kubernetes_sd_configs:
- role: pod
relabel_configs:
# Извлекаем имя приложения из метки Kubernetes
- source_labels: [__meta_kubernetes_pod_label_app]
target_label: app
# Убираем метрики с префиксом "test_"
- source_labels: [__name__]
regex: test_.*
action: drop

Resource-aware настройка scrape_interval и retention:

Адаптация частоты сбора и хранения метрик под доступные ресурсы:

• Используйте более длительные интервалы (>30s) для стабильных метрик
• Применяйте короткие интервалы (5-10s) только для критичных метрик
• Настраивайте retention (--storage.tsdb.retention.time) в соответствии с доступным дисковым пространством
• Используйте федерацию для разделения "горячих" и "холодных" метрик

# Пример дифференцированной настройки scrape_interval
scrape_configs:
- job_name: 'critical-services'
scrape_interval: 5s
static_configs:
- targets: ['api-gateway:9090', 'payment-service:9090']

- job_name: 'background-services'
scrape_interval: 30s
static_configs:
- targets: ['analytics-service:9090', 'reporting-service:9090']

Push vs. Pull: выбор оптимального подхода:

В 2025 году большинство систем используют гибридный подход:

• Pull-модель (стандарт Prometheus) для долгоживущих сервисов
• Push-модель через PushGateway для batch-задач и serverless-функций
• Федерацию для распределенных систем
• remote_write/remote_read для долгосрочного хранения

Интегрированный мониторинг ресурсов Prometheus:

Мониторинг самого Prometheus должен быть приоритетом:

• Отслеживайте метрику prometheus_tsdb_head_series для контроля карденальности
• Используйте rate(prometheus_tsdb_WAL_truncations_total[1h]) для мониторинга активности записи
• Контролируйте prometheus_target_scrape_pool_exceeded_target_limit_total для выявления проблем со скрейпингом

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

Интеграция метрик Prometheus с системами визуализации

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

Grafana: стандарт индустрии для визуализации Prometheus

В 2025 году Grafana остается лидирующим инструментом визуализации для Prometheus, предлагая:

• Нативную поддержку PromQL
• Расширенные возможности визуализации (тепловые карты, гистограммы, таблицы)
• Alerthub для централизации оповещений
• Tempo для интеграции с трассировкой
• Flexible Layout с возможностью создания адаптивных дашбордов

Пример эффективной PromQL-запросой для визуализации в Grafana:

# 99-й процентиль времени отклика по службам
histogram_quantile(0.99, 
sum by(service, le) (
rate(http_request_duration_seconds_bucket{env="production"}[5m])
)
)

Оптимальные практики организации дашбордов:

• RED-метод для сервисов: (Rate, Errors, Duration)
• USE-метод для ресурсов: (Utilization, Saturation, Errors)
• Иерархический подход: от высокоуровневого обзора к детальным метрикам
• Consistent Templating: использование переменных для фильтрации по окружениям, службам
• Annotations: отметки о деплоях, инцидентах, масштабированиях

Структура эффективного дашборда в Grafana:

1. Overview: общее состояние системы (SLI, уровень ошибок, latency)
2. Services: детализация по каждому сервису
3. Resources: утилизация инфраструктуры (CPU, RAM, Network)
4. Business Metrics: бизнес-показатели, связанные с техническими
5. Alerts: активные и недавние оповещения

Продвинутая интеграция: beyond Grafana:

Современные решения 2025 года выходят за рамки традиционной визуализации:

• Prometheus Query Federated: объединение метрик из распределенных кластеров
• ML-based Anomaly Detection: автоматическое выявление аномалий на основе исторических данных
• Thanos/Cortex: долгосрочное хранение метрик с возможностью запросов над историческими данными
• PromQL Extensions: расширенные возможности запросов для сложного анализа

Инструменты корреляции между метриками и логами:

Контекстный переход между системами мониторинга:

• Loki: интеграция логов с метриками в единой парадигме
• OpenTelemetry: единая система для метрик, логов и трассировки
• Exemplars: связывание конкретных образцов метрик с трассировкой

# Корреляция метрик с логами через метки
sum by (service) (rate(http_requests_total{status_code=~"5.."}[5m])) > 0

А в Grafana можно настроить переход к Loki с теми же фильтрами:

http_calls_total{job="app", handler="/api", status="500"}

Алертинг на основе комплексных метрик:

Современные системы алертинга используют многомерный анализ:

# Пример правила алертинга на основе нескольких метрик
groups:
- name: Example
rules:
- alert: HighErrorRateAndLatency
expr: |
(sum(rate(http_requests_total{status_code=~"5.."}[5m])) / sum(rate(http_requests_total[5m])) > 0.05)
and
(histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket[5m])) by (le)) > 1)
for: 5m
labels:
severity: critical
annotations:
summary: "High error rate with increased latency"
description: "Service is experiencing both high error rate (>5%) and high latency (p95 > 1s)"

Визуализация бизнес-метрик наравне с техническими:

Соединение технических и бизнес-показателей на одном дашборде:

• Корреляция между latency и конверсией
• Влияние ошибок на показатель отказов (bounce rate)
• Соотношение между нагрузкой и выручкой

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

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