Как Prometheus превращает облачный сервис в временные ряды: метки, счётчики и распределения
Почему один показатель становится множеством рядов, чем текущее значение отличается от накопленного счётчика и как гистограммы позволяют обсуждать задержки нескольких экземпляров сервиса.
Сбор показателей отделён от визуализации и оповещений
Prometheus собирает числовые измерения по времени. Основной сервер опрашивает инструментированные приложения и экспортёры через HTTP, сохраняет полученные образцы и выполняет правила. Адреса целей могут поступать из статической конфигурации или механизмов обнаружения сервисов. Такая организация подходит динамической инфраструктуре, где набор экземпляров меняется, но само измеряемое свойство сервиса остаётся осмысленным.
Библиотека внутри приложения предоставляет метрики, а exporter адаптирует показатели другой системы. Pushgateway предназначен для отдельного сценария короткоживущих заданий, а не отменяет основную модель опроса. Alertmanager обрабатывает оповещения; системы графиков и другие клиенты читают результаты через API. Это разные части цепочки, поэтому изображение графика в панели не следует путать с местом хранения исходных образцов.
Каждый сервер Prometheus работает самостоятельно и не требует распределённого хранилища как обязательного компонента. Правила могут создавать новые ряды из существующих или формировать события для оповещения. При этом документация явно отделяет эксплуатационный мониторинг от точного учёта каждого запроса для выставления счетов: модель собранных измерений не рассчитана на гарантированно полный журнал финансовых операций. Здесь рассматривается устройство мониторинга, а не его использование в качестве бухгалтерской системы.
Набор меток является частью имени временного ряда
Ряд в Prometheus определяется именем метрики и набором пар «метка — значение». Условное имя числа HTTP-запросов может сопровождаться методом и обработчиком. Разные сочетания значений дают разные ряды, даже если основное имя одинаково. Добавление метки, её удаление или изменение значения меняет идентичность ряда, а не просто отображаемую подпись на графике.
Такая многомерная модель позволяет выбирать нужное подмножество и агрегировать показатели по общим признакам. Например, разделение по обработчикам можно сохранить в одном запросе и свернуть в другом. Но это не означает, что все строки с общим именем изначально являются одним физически непрерывным счётчиком. Их история существует для конкретных сочетаний измерений.
Образец содержит значение и временную отметку. В актуальной модели значение может быть обычным числом float64 либо составным образцом native histogram. Пустое значение метки считается эквивалентным отсутствию этой метки. Внутренние имена с двумя подчёркиваниями имеют служебное назначение. Синтаксис имени и соглашения об именовании обеспечивают совместимость инструментов, а смысл единиц и измеряемой величины определяется самой инструментализацией приложения.
Счётчик описывает накопление, gauge — состояние
Counter предназначен для величины, которая увеличивается или сбрасывается при перезапуске. К нему относятся число обработанных запросов, завершённых заданий и зарегистрированных ошибок. Gauge, напротив, может расти и уменьшаться: это температура, занятая память, число текущих соединений или элементов очереди. Наличие слова «число» в описании само по себе не делает показатель счётчиком.
Разница проявляется в последующей обработке. Накопленное значение отвечает на вопрос об общем числе событий за срок существования счётчика. Для интенсивности используется изменение во времени с учётом характера этой величины. Текущий размер очереди уже представляет состояние, поэтому трактовка его как постоянно накапливаемого числа событий дала бы другой смысл.
Распределения наблюдений описывают histogram и summary. Обычная классическая гистограмма раскладывается на несколько рядов: накопительные корзины, сумму наблюдений и их количество. Native histogram передаёт составной образец с набором корзин. Поэтому тип, заданный библиотекой приложения, и физическое представление в базе не всегда выглядят одинаково. В частности, историческая модель простых числовых рядов не сохраняет полноценную строгую типизацию каждого значения так, как это сделала бы обычная таблица с отдельным типом столбца.
Почему среднее время не заменяет распределение задержек
Для времени обработки запросов важен не только общий итог, но и распределение. Summary может рассчитывать заранее выбранные квантили внутри приложения для заданного временного окна. После передачи этих готовых чисел нельзя произвольно пересчитать другой процентиль или другое окно. Особенно важно, что квантили отдельных экземпляров не агрегируются в корректный общий квантиль простым усреднением.
Гистограмма сохраняет более исходное описание распределения через количества наблюдений в корзинах. Это позволяет агрегировать совместимые распределения и затем рассчитывать необходимый квантиль на стороне запроса. У классических гистограмм границы корзин задаются при инструментализации и имеют значение для дальнейшей совместимости и точности оценки. Native histogram использует составной образец и динамические корзины, а не независимый ряд для каждой границы.
Оба подхода также сохраняют сумму и количество наблюдений. Они позволяют получить среднее, но это среднее не выражает форму хвоста задержек. График из официального учебного примера иллюстрирует работу корзин, а не результаты измерения какого-либо сервиса ЭРИТКОМ. В этом разборе не приводятся вымышленные эксплуатационные значения: сравнивается характер данных, которые метрика даёт последующим запросам.
| Тип | Что описывает | Пример величины |
|---|---|---|
| Counter | Накопление с возможным сбросом | Общее число запросов |
| Gauge | Текущее изменяемое состояние | Размер очереди |
| Histogram | Распределение наблюдений по корзинам | Длительность запросов |
| Summary | Сумму, количество и выбранные квантили | Задержки с вычислением квантилей внутри приложения |
Источник: Prometheus: Metric types и Histograms and summaries
PromQL различает момент времени и интервал вычисления
PromQL позволяет выбирать и агрегировать ряды, но запросы выполняются в определённом временном контексте. Instant query рассчитывается для одной точки. Range query повторяет вычисление через равные промежутки между началом и концом диапазона. Это различие описывает режим выполнения, а не два разных языка запросов.
Внутри выражения также существуют разные типы результата. Instant vector содержит по одному образцу для каждого ряда на рассматриваемый момент, range vector — набор образцов за период, scalar — отдельное число. Оператор над историей значений должен получить соответствующий набор данных. Нельзя считать, что любое окно на графике автоматически меняет смысл всех вложенных операций.
Составные гистограммы дополнительно несут сведения о характере образца и раскладке корзин. При некоторых несовместимых операциях движок может добавить предупреждение или исключить соответствующий элемент из результата. У обычных числовых значений пользователь во многом сам отвечает за правильное различение counter и gauge. Поэтому одинаково выглядящие линии на экране могут быть получены принципиально разными вычислениями — выборкой значения, агрегацией или обработкой изменения во времени.
Локальная база и удалённое хранилище имеют разные роли
Локальная TSDB группирует поступающие данные в блоки. Текущие образцы сначала находятся в памяти, а журнал WAL позволяет восстановить ещё не уплотнённые данные после перезапуска. Индекс связывает имена и метки с размещением рядов. Удаление через API оставляет специальные отметки, а не обязательно немедленно переписывает каждый сегмент с образцами.
Удалённые системы подключаются через отдельные интерфейсы. Remote Write передаёт поступающие образцы во внешнее хранилище; Remote Read позволяет запрашивать исходные ряды за период. В описанном документацией пути Remote Read вычисление PromQL по полученным данным остаётся на стороне Prometheus. Это не автоматический перенос произвольного запроса целиком в удалённую распределённую систему.
Политики хранения могут ограничивать срок и размер данных, а очистка выполняется по блокам в фоне. Текущее состояние базы и временное место для уплотнения тоже участвуют в расходе диска. Следовательно, внешнее долговременное хранение и локальная самостоятельность сервера решают разные задачи. Одна часть отвечает за непосредственный сбор и расчёт рядом с сервисом, другая может расширять период хранения и интеграцию с общей платформой наблюдаемости.
