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