Модель данных Prometheus: временные ряды, лейблы и метрики

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

Краткое введение

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

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

1) Как формируются временные ряды: идентификатор на основе имени и лейблов.
2) Роли типов метрик и их семантика.
3) Формат хранения точек: sample, timestamp и их взаимосвязь.
4) Особенности отсутствия данных и сигналы устаревания.
5) Практические принципы проектирования метрик и именования.

Модель данных Prometheus: базовые сущности

Временные ряды и их уникальная идентификация

В Prometheus любой измеряемый показатель представлен как временной ряд. Уникальный ключ временного ряда формируется из имени метрики и набора лейблов. Лейблы - это пара ключ-значение, где ключ - это имя параметра (например, код HTTP-ответа или метод запроса), а значение - соответствующее значение параметра. Важно, что порядок лейблов не имеет значения для идентификации, однако валидная система требует использования одного уникального набора, чтобы две разных записи не считались различными рядами. Это означает, что один и тот же временной ряд всегда имеет идентификатор вида:

metric_name{label1="value1",label2="value2",...}

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

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

Лейблы: роль, структура и влияние на хранение

Лейблы дают контекст к измерению. Они несут информацию о источнике (service, instance), типе данных (endpoint, method), окружении (env, stage) и прочих параметрах, которые полезны для сегментации графиков. Лейблы служат фильтрами в PromQL и определяют, какие данные включать в агрегацию. Важны несколько принципов проектирования:

Стандартизированные лейблы: среди них обычно встречаются job и instance, которые позволяют идентифицировать источник scrape-сервиса и конкретную инстанцию.
Кардинальность: каждое уникальное значение лейбла умножает количество временных рядов. В Prometheus высокую кардинальность вызывают, например, многочисленные окружения, динамические параметры пользователя или идентификаторы сессий. Необходимо соблюдать баланс между аналитическими потребностями и нагрузкой на хранение и запросы.
Валидация форматов: имена лейблов и их значения должны оставаться строками; избегайте вложенных структур внутри значений, чтобы не усложнить агрегации и сравнения.
Совместимость с экспортёрами: экспортеры и сервисы должны придерживаться общепринятых наборов лейблов, чтобы упрощать кросс-проекты анализ и позволять повторное использование дашбордов.

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

Формат экспозиции: текстовый exposition format

Для иллюстрации принципов формирования точек можно привести простой пример в текстовом формате экспозиции:

## HELP http_requests_total The total number of HTTP requests
## TYPE http_requests_total counter
http_requests_total{method="GET",code="200"} 1027 1395066363000
http_requests_total{method="POST",code="500"} 3 1395066363000

Этот пример демонстрирует:

имя метрики: http_requests_total
набор лейблов: method и code
значение: количество запросов
временную отметку: 1395066363000 миллисекунд с момента эпохи

Формат экспозиции позволяет экспорторам и сервисам передавать данные в Prometheus в единообразной форме. В реальности экспортёры формируют десятки или тысячи различных линий для разных метрик и контекстов, поэтому корректное управление именованием и лейблами становится критическим для поддерживаемости.

Типы метрик: поведение и семантика

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

Counter - монотонно возрастающая метрика, используемая для подсчета количества событий (например, число обработанных запросов). Её основной смысл - рост со временем; значения не уменьшаются.
Gauge - произвольное числовое значение, которое может расти и падать. Подходит для текущего состояния (например, текущая загрузка CPU, размер очереди).
Histogram - распределение значений по заданным корзинам (bucket). В каждом временном ряду хранится счетчик по каждому bucket и дополнительные агрегаты: sum и count. Это позволяет строить эмпирические квантильные оценки и анализировать задержки.
Summary - распределение значений по квантилям, агрегируемым на уровне экспортёра или сервера. В Prometheus хранится выборка значений и их квантильные аппроксимации. В отличие от Histogram, Summary не требует конфигурации корзин, но может приводить к большему объему данных и ограниченной переносимости между кластерами.

Важно помнить: выбор типа метрики влияет на хранение, производительность и точность анализа. Counter и Gauge требуют примерно одинакового подхода в агрегациях, тогда как Histogram и Summary предлагают более детальные распределения, но требуют больше памяти и вычислительных ресурсов.

Абсервация отсутствующих данных и устаревание

В действительности в мониторинге часто возникают ситуации, когда источник данных временно не публикует новые точки. Prometheus использует концепцию отсутствия данных (staleness) и специальных сигналов устаревания: если для ряда прекратились новые выборки, система помечает этот ряд как устаревший, чтобы графики и запросы могли корректно отражать отсутствие данных. Это особенно важно для алертинга и для корректной интерпретации графиков, где длительное «нулевое» значение могло означать или отсутствие данных, или устойчивое состояние.

Такая семантика требует осторожности: отсутствие данных не равно нулю. В запросах PromQL следует применять функции, учитывающие absent или absent_over_time, чтобы точно выявлять пропуски и их причины.

Формат хранения и структура данных: от концепций к реализации

В Prometheus временные ряды хранятся в локальном Time Series Database (TSDB). Каждому ряду соответствует ключ - сочетание имени метрики и лейблов, и набор точек данных (samples) с временными отметками и значениями. Внутри TSDB реализованы механизмы индексирования по метрикам и по лейблам, а также эффективные структуры хранения точек в виде чанков. Применение компрессии, ленточной организации данных и соответствующих структур (индексы на лейблах, индексация по времени) обеспечивает приемлемую производительность запросов в условиях высокого объема данных.

Отдельно следует отметить принципы архитектуры хранения: сохранение неизменяемости данных, поддержка сжатия и гибкие политики хранения (retention) и архивирования. В сценариях огромной потребности в долговременном хранении существует схема remote_storage, где данные отправляются на внешние хранилища (например, Cortex или VictoriaMetrics) для масштабирования и долговременной аналитики. Это позволяет сохранять преимущества Prometheus в локальном сборе данных, но при этом уходить от ограничений одного узла в плане хранения. В рамках двух типичных подходов можно упомянуть:

Прямое хранение в Prometheus: простота, единый источник мониторинга, хорошо подходит для небольших и средних инсталляций.
Расширенная архитектура: Prometheus вместе с remote_storage-провайдерами (напр., Cortex или VictoriaMetrics) для горизонтального масштабирования и долговременного хранения.

Пример источников данных и соответствующих решений можно резюмировать так:

Node exporter как один из классических экспортёров для инфраструктурных метрик.
Простой перенос в remote storage через Cortex или VictoriaMetrics для расширения горизонтального масштаба и долговременного хранения.

Типовые паттерны проектирования метрик и практические выводы

Стратегия именования: использовать понятные и единообразные имена метрик, которые отражают функциональность и характер измерения (например, http_requests_total, cpu_usage_seconds_total).
Стратегия лейблов: держать набор стандартных лейблов (job, instance, depends_on environment) и избегать бесконечного роста за счет динамических параметров, которые приводят к высокой кардинальности.
Выбор типа метрик: для счетчика событий** - Counter; для состояния - Gauge; для распределения задержек - Histogram; если требуется точка оценок квантилей без разумной конфигурации корзин - может быть применен Summary, но с учётом объема данных и совместимости.
Мониторинг экстремумов и устойчивость к отсутствию данных: планировать обработку стaleness и absent функций в PromQL, чтобы не искажать графики и алерты.
Архитектура данных и экспортёры: проектировать экспортёры так, чтобы они публиковали измерения с единообразной структурой лейблов и минимизировали кардинальность; при необходимости использовать промежуточные адаптеры или сборщики, которые нормализуют форму метрик.

Архитектура сбора и хранение данных в Prometheus

Как данные попадают в Prometheus

Основной путь - скрапинг (scrape) метрик с целевых приложений и сервисов через Exporter-агенты или встроенные метрики. Примером может служить node_exporter или встроенные метрики приложений. В сборке Prometheus присутствуют настройки scrape_configs и service_discovery, которые определяют источники данных, параметры аутентификации и частоту выборок. Важной характеристикой является то, что данные, собранные с источников, структурируются как временные ряды с уникальными идентификаторами на основе имени метрики и лейблов.

Структура хранения и индексация

В TSDB Prometheus хранение реализовано через блоки/чанки и индексы по лейблам и времени. Глубоко принципиально то, что каждый уникальный набор пар metric_name и лейблов формирует отдельный временной ряд. Это приводит к потенциалу высокой кардинальности при большом числе уникальных сочетаний лейблов. Следовательно, архитекторы мониторинга должны не только думать о качестве экспортёров и корректности набора лейблов, но и поддерживать политику управления кардинальностью: ограничивать динамические параметры, использовать фиксированные контекстные лейблы и группировать данные там, где это возможно.

Применение гиперсистем: remote storage и интеграции

Для требований к долговременному хранению и горизонтальному масштабированию Prometheus поддерживает интеграцию с внешними системами хранения через remote_write и remote_read. В рамках гибридной архитектуры можно использовать Cortex или VictoriaMetrics как удалённое хранилище, сохраняя при этом локальное сканирование и алертинг. Эти решения обеспечивают масштабируемость и долговременную аналитическую способность при сохранении совместимости с PromQL и существующим UX Prometheus.

Типы метрик и их семантика в Prometheus

Counter: счетчик событий

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

Gauge: текущее состояние

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

Histogram: распределение задержек и значений

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

Summary: квантильная оценка

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

Взаимодействие метрик и агрегаций

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

Эталонные практики проектирования метрик

Разделение ответственности между метриками: создавать отдельные счетчики для общей активности и по конкретным источникам.
Консистентность имён: формировать имена так, чтобы они отражали смысл измерения и легко сопоставлялись между сервисами.
Контроль кардинальности: избегать включения в лейблы уникальных значений, связанных с пользователями или сессиями, если они не необходимы для бизнес-аналитики.
Включение контекста: пользоваться стандартными лейблами (job, instance) и добавлять дополнительные контекстные параметры, только если они действительно помогают анализу.

Практические аспекты проектирования метрик и внедрения

Нормы именования и правила лейблов

Имя метрики должно быть понятным и отображать характер измерения (например, http_requests_total, cpu_usage_seconds_total).
Лейблы следует использовать для контекстной сегментации, избегая динамических параметров, которые приводят к росту кардинальности.
Порядок лейблов не влияет на идентификацию временного ряда, поэтому ключ строится как множество пар.

Экспортёры и источники данных

Начинайте с наиболее распространённых экспортёров (node_exporter для инфраструктурных метрик, mysqld_exporter для баз данных).
При необходимости добавляйте собственные экспортёры, но старайтесь сохранять единообразие набора лейблов и форматов экспозиции.
Используйте сервис-дискавери (service discovery) для автоматического обнаружения целевых метрик, чтобы уменьшить операционные затраты и риск пропусков.

Управление кардинальностью и устойчивость к изменениям

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

Key takeaways

В Prometheus каждый временной ряд определяется именем метрики и набором лейблов; уникальный набор лейблов идентифицирует конкретный ряд.
Лейблы обеспечивают контекст и фильтрацию, но их количество напрямую влияет на кардинальность и нагрузку на хранение.
Метрики бывают Counter, Gauge, Histogram и Summary; выбор типа влияет на семантику и способы агрегации.
Отсутствие данных и устаревание требуют специальных механизмов обработки в PromQL и алертинге.
Архитектура хранения может быть локальной или с remote storage через Cortex или VictoriaMetrics для масштабирования и долговременного хранения.
Практическое проектирование метрик и экспортёров требует баланса между информативностью и управляемостью кардинальности.

FAQ

Что такое временной ряд в Prometheus и зачем он нужен?

Временной ряд - это уникальная последовательность точек данных, связанных с определённой метрикой и конкретным набором лейблов. Он позволяет хранить и анализировать значения во времени, что критично для мониторинга и алертинга. Системы запросов, такие как PromQL, работают именно с временными рядами, чтобы извлекать статистику по времени, сегментам и источникам.

Как формируется уникальный ключ временного ряда?

Уникальный ключ формируется из имени метрики и набора лейблов. Порядок лейблов не имеет значения, важна совокупность ключей и значений. Любая новая пара лейблов, которая образует новый набор, приводит к новому временной ряду.

В чем принципиальная разница между Counter, Gauge, Histogram и Summary?

Counter - монотонный счетчик, растет во времени и не уменьшается. Gauge - текущее состояние, может расти и падать. Histogram - распределение значений через корзины и пару дополнительных полей (sum и count). Summary - квантильная аппроксимация без явной конфигурации корзин, но обычно требует большего объема данных и имеет ограничения на переносимость.

Как обрабатываются отсутствующие данные и устаревание рядов?

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

Какие проблемы возникают из-за высокой кардинальности и как их уменьшить?

Высокая кардинальность приводит к большому числу временных рядов, что увеличивает требования к памяти и месту хранения. Решения включают ограничение динамических лейблов, применение фиксированных, стандартных лейблов, агрегацию на уровне экспортёра и использование remote storage для долговременного хранения.

Какие типы источников данных лучше всего подходят для Prometheus?

Встроенные метрики в приложениях и продвинутые экспортёры (node_exporter, mysqld_exporter) являются типичным стартом. При необходимости масштабируемости и долговременного хранения можно использовать remote storage-партнёров вроде Cortex или VictoriaMetrics.

Как проектировать метрики, чтобы они были полезны в дашбордах и алертинге?

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

Что учитывать при внедрении экспортеров в существующую среду?

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

Как выбрать между локальным хранением Prometheus и удалённым хранением?

Локальное хранение обеспечивает простоту и быструю реакцию, подходит для сред с ограниченной архитектурой. Удалённое хранение через Cortex или VictoriaMetrics позволяет масштабировать объём данных и сохранять данные на длительный срок. Выбор зависит от требований к объему данных, задержке доступа и долгосрочной аналитике.

Какие практические риски связаны с изменением схемы метрик в существующей среде?

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

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

Архитектура системы мониторинга: компоненты и взаимодействия

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

Форматы данных и стандарты: OpenMetrics и exposition