Prometheus важен не только как стандарт де-факто, но и как очень понятная архитектурная модель мониторинга, в которой хорошо видно, где выигрывает модель опроса и где у неё начинаются ограничения.
В реальной эксплуатации эта глава помогает думать о том, какие сервисы Prometheus мониторит, как он их находит и какие правила считает, как о связанной системе, а не о наборе разрозненных настроек в одном YAML.
В интервью и инженерных обсуждениях она особенно полезна там, где нужно объяснить, почему Prometheus хорошо решает задачу базового облачно-ориентированного мониторинга, но не всегда закрывает длительное хранение или глобальный масштаб в одиночку.
Практическая польза главы
Топология сбора метрик
Проектируйте список сервисов и экспортёров вместе с обнаружением сервисов, чтобы избежать слепых зон и дубликатов в метриках.
Правила и конвейер оповещений
Разделяйте правила записи и правила оповещения, чтобы стабилизировать задержку дашбордов и качество оповещений.
Контур удалённой записи
Определяйте границы локального Prometheus и длительного хранения с учётом целевого уровня сервиса и стоимости хранения.
Аргументация на интервью
Объясняйте компромисс pull-модели Prometheus и сценарии, где нужен дополнительный слой агрегации.
Рамка выбора и редакторский фокус
Фокус главы
Prometheus, опросе метрик, правилах и надёжности мониторинга
Профиль нагрузки
Начинайте с специализированного запроса: аналитика, поиск, временные ряды, графовые обходы, векторное извлечение или мониторинговые метрики.
Когда выбирать
Выбор оправдан, когда модель индекса или хранения напрямую совпадает с продуктовой задачей и разгружает источник истины.
Граница и риск
Опасность — превратить специализированный слой в универсальную БД и потерять границы консистентности, свежести и владения данными.
Связать дальше
Связывайте главу с источником транзакционных данных, конвейером данных, удержанием данных, компакцией и архитектурой слоя модели чтения.
Основной источник
Prometheus docs
Официальная модель Prometheus из первых рук: опрос метрик, база временных рядов, язык запросов PromQL и правила — без пересказа.
в Prometheus строится вокруг сервисов и экспортёров, у которых забираются метрики, , , , и . Эти понятия помогают отличить локальный мониторинг от длительного хранения и понять, где кардинальность меток начинает стоить дорого.
Когда нужно понять, что происходит с инфраструктурой прямо сейчас, выбор почти всегда падает на Prometheus — специализированную систему мониторинга временных рядов, которая сочетает модель опроса метрик, собственный движок базы временных рядов и язык запросов PromQL. На карте баз временных рядов это канонический инструмент инфраструктурного мониторинга и эксплуатации, ориентированной на .
История: ключевые вехи
Рождение в SoundCloud
Prometheus появляется в SoundCloud как внутренний движок мониторинга для облачно-ориентированных нагрузок.
Открытый код и ранняя экосистема
Проект открывается сообществу и быстро набирает популярность в кластерах платформы Kubernetes.
Incubating в CNCF
Prometheus входит в CNCF и закрепляет нейтральную модель управления проектом.
Graduated в CNCF
Проект получает статус зрелого стандарта для инфраструктурного мониторинга.
Prometheus 2.x как индустриальная база
Удалённая запись и чтение становятся стабильными, вокруг проекта складываются операторы и практики, которые удерживают кардинальность меток в безопасных пределах.
Эволюция масштабируемого хранения метрик
Один узел Prometheus упирается в локальный диск раньше, чем хотелось бы, — отсюда зрелые паттерны длительного хранения, федерации и гибридных архитектур мониторинга.
Специфика Prometheus
Модель опроса метрик
Prometheus сам ходит за метриками к сервисам и экспортёрам. Источник правды о том, какие цели опрашиваются и живы ли они, остаётся на стороне мониторинга, а не разбросан по приложениям.
Хранилище с журналом предзаписи (WAL) и блоками
Свежие значения сперва живут в памяти и журнале предзаписи (WAL), затем уплотняются в блоки на диске. Цена этого выбора — локальный диск как предел: длительное хранение приходится выносить наружу.
Язык запросов PromQL как инструмент анализа
Язык запросов PromQL заточен под векторы временных рядов, агрегации по меткам и временные окна. Тот же язык описывает и графики, и условия оповещений — отдельный язык под алерты не нужен.
Правила и оповещения
Правила записи, правила оповещения и связка с Alertmanager замыкают контур реагирования. Слабое место появляется там, где правил становится слишком много и сигнал тонет в шуме.
Архитектура Prometheus по слоям
На верхнем уровне Prometheus можно читать как конвейер: сбор метрик у сервисов и экспортёров -> свежие данные в памяти и -> блочное хранение -> движок -> правила и оповещения -> внешние интеграции.
Ключевые особенности
Prometheus оптимизирован под мониторинг: модель опроса, TSDB с WAL и блоками, PromQL и правила оповещения.
Модель опроса
Модель меток
Жизненный цикл данных
Конфигурация и данные: аналогия с DDL и DML
В Prometheus нет привычных по SQL операций определения и изменения данных (DDL/DML). Но для разбора архитектуры удобно держать их врозь: изменение конфигурации (сбор метрик и правила) — это одно, а работа с данными (запись новых значений и чтение через ) — другое.
Конфигурация и данные в Prometheus
Аналогия: конфигурация меняет структуру мониторинга, данные проходят путь записи и чтения.
1. Опрос и приём метрик
Данные и запросыОпрос сервисов или удалённая запись приносит новые значения метрик.
2. Запись в WAL
Данные и запросыЗначения метрик записываются в WAL для восстановления после сбоя.
3. Обновление свежих данных
Данные и запросыTSDB обновляет активные ряды в памяти и индекс меток для свежих данных.
4. Выполнение PromQL
Данные и запросыДвижок запросов читает свежие данные и исторические блоки, затем выполняет агрегации.
5. Слияние блоков и срок хранения
Данные и запросыФоновое слияние уплотняет блоки и применяет политику хранения.
Активный шаг
1. Опрос и приём метрик
Опрос сервисов или удалённая запись приносит новые значения метрик.
Поток данных и запросов
- Путь данных охватывает приём, хранение и чтение метрик через PromQL.
- Свежие данные хранятся в памяти, исторические - в компактных блоках.
- Кардинальность меток напрямую влияет на стоимость и задержку запросов.
Источник
InfluxDB docs
Сравнительный контекст по альтернативному профилю базы временных рядов.
Prometheus и InfluxDB
Базовый подход
Prometheus: Модель опроса целей и плотная интеграция с рабочим процессом мониторинга.
InfluxDB: Сильный акцент на программный интерфейс (API) приёма данных и хранилище временных рядов для широкого класса телеметрии.
Язык запросов
Prometheus: Язык запросов PromQL с фокусом на метрики, метки и аналитику, связанную с оповещениями.
InfluxDB: InfluxQL/Flux в зависимости от версии и сценария обработки данных.
Типичный рабочий профиль
Prometheus: Инфраструктурный мониторинг, , оповещения и наблюдаемость кластеров платформы Kubernetes.
InfluxDB: Мониторинг, интернет вещей (IoT) и телеметрия, где нужны гибкий приём данных и политики хранения.
Операционная модель
Prometheus: Один узел держит свежие данные, а для длительного хранения его дополняют федерацией или внешним хранилищем.
InfluxDB: Часто работает как самостоятельный контур временных рядов или управляемый сервис, без отдельного слоя для долгого хранения.
Почему Prometheus часто выбирают для мониторинга
Что именно это даёт на этапе проектирования системы:
- Простая модель опроса и плотная экосистема вокруг платформы Kubernetes сделали Prometheus стандартом облачно-ориентированного мониторинга — его проще встроить, чем обосновать альтернативу.
- Язык запросов PromQL и правила держат наблюдаемость и оповещения в одном контуре: отдельный язык (DSL) под алерты заводить не нужно.
- Журнал предзаписи (WAL), данные в памяти и блочное хранение делают запись и чтение метрик предсказуемыми под нагрузкой, пока не упираешься в локальный диск.
- Связка с Alertmanager, Grafana и внешним хранилищем размечает маршрут от одного узла до масштабируемой топологии — расти можно постепенно, а не переписывать всё сразу.
Примеры запросов на языке PromQL
Шпаргалка для типовых рабочих задач: от нагрузки и задержки до контроля .
Пропускная способность сервиса: запросы в секунду (RPS)
Оценить входящую нагрузку на `checkout-api` за последние 5 минут.
sum(rate(http_requests_total{service="checkout-api"}[5m]))Базовый индикатор скорости входящего трафика, обычно первый график в панели метрик RED.
Задержка: 95-й перцентиль (P95)
Контролировать деградации задержки в пользовательском пути.
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{service="checkout-api"}[5m])) by (le))Для перцентилей / используем `*_bucket`, а не среднее значение, чтобы видеть хвосты распределения.
Доля ошибок (%)
Посчитать долю 5xx-ответов относительно общего трафика сервиса.
100 * (sum(rate(http_requests_total{service="checkout-api",status=~"5.."}[5m])) / sum(rate(http_requests_total{service="checkout-api"}[5m])))Частая основа для оповещений по и правил скорости расходования бюджета ошибок.
Насыщение процессора (CPU) по pod
Найти поды, которые подбираются к лимитам процессора (CPU).
sum(rate(container_cpu_usage_seconds_total{namespace="prod",pod=~"checkout-api-.*"}[5m])) by (pod)Отсюда видно, когда пора подкручивать автомасштабирование и где сидит «горячий» pod-экземпляр, тянущий задержку вверх.
Первые k результатов (top-k) по памяти
Выделить самые «тяжелые» pod-экземпляры по рабочему набору памяти.
topk(5, container_memory_working_set_bytes{namespace="prod",pod=~"checkout-api-.*"})Быстрый срез для расследования OOMKill и корректировки requests/limits.
Скорость расходования бюджета ошибок
Оценить, насколько быстро сервис расходует бюджет ошибок при 99.9%.
(sum(rate(http_requests_total{service="checkout-api",status=~"5.."}[5m])) / sum(rate(http_requests_total{service="checkout-api"}[5m]))) / (1 - 0.999)Значение значительно выше `1` означает, что бюджет ошибок расходуется быстрее допустимого.
Источники
Связанные главы
- Базы данных временных рядов (TSDB): типы, компромиссы и выбор - Как позиционировать Prometheus среди других подходов к временным рядам по задержке, сроку хранения и операционной модели.
- Фреймворк выбора СУБД - Фреймворк выбора, который помогает обосновать Prometheus как мониторинговое хранилище, а не универсальную аналитическую СУБД.
- Observability & Monitoring Design - Метрики Prometheus в одиночку не дают полной картины: глава связывает их с логами, трассировками и контуром целевых уровней сервиса / в рабочей наблюдаемости.
- Prometheus: The Documentary - Исторический контекст появления Prometheus и эволюции его экосистемы в облачно-ориентированном мире.
- Kubernetes Fundamentals - База для понимания обнаружения сервисов, модели опроса и подхода операторов в кластерах платформы Kubernetes.
- Обнаружение сервисов - Если обнаружение целей пропускает новые поды, в метриках появляются дыры ровно там, где их сложнее всего заметить, — глава о том, как этого избежать.
- VictoriaMetrics: история и архитектура - Сравнение Prometheus-совместимых стратегий хранения и масштабирования для длительного хранения метрик.