Prometheus важен не только как стандарт де-факто, но и как очень понятная архитектурная модель мониторинга, в которой хорошо видно, где выигрывает pull-подход и где у него начинаются ограничения.
В реальной эксплуатации эта глава помогает думать о jobs, targets, service discovery, recording rules и alerting как о связанной системе, а не о наборе разрозненных настроек, которые случайно оказались в одном YAML.
В интервью и инженерных обсуждениях она особенно полезна там, где нужно объяснить, почему Prometheus хорошо решает задачу базового cloud-native мониторинга, но не всегда закрывает долгий retention или глобальный масштаб в одиночку.
Практическая польза главы
Scrape topology
Проектируйте jobs/targets и service discovery так, чтобы избежать blind spots и дубликатов в метриках.
Rules и alert pipeline
Разделяйте recording и alerting rules, чтобы стабилизировать latency дашбордов и качество алертов.
Remote write контур
Определяйте границы локального Prometheus и long-term storage с учетом SLA и стоимости хранения.
Interview articulation
Объясняйте компромисс pull-модели Prometheus и сценарии, где нужен дополнительный слой агрегации.
Источник
Prometheus docs
Официальное описание модели Prometheus: pull-scrape, TSDB, PromQL и rules.
Prometheus — специализированная time-series система мониторинга, которая сочетает pull-модель сбора метрик, собственный TSDB-движок и язык запросов PromQL. В контексте TSDB-карты Prometheus — канонический выбор для инфраструктурного мониторинга и SLO-driven эксплуатации.
История: ключевые вехи
Рождение в SoundCloud
Prometheus появляется как внутренний мониторинг-движок для cloud-native нагрузки.
Open source и ранняя экосистема
Проект открывается сообществу и быстро набирает популярность в Kubernetes-контуре.
Incubating в CNCF
Prometheus входит в CNCF и формализует нейтральную governance-модель развития.
Graduated в CNCF
Проект получает статус зрелого стандарта для инфраструктурного мониторинга.
Prometheus 2.x как индустриальная база
Стабилизируются remote write/read, экосистема операторов и практики high-cardinality тюнинга.
Эволюция в сторону масштабируемых TSDB-профилей
Укрепляются паттерны long-term storage, federation и гибридных Prometheus-архитектур.
Специфика Prometheus
Pull-модель сбора
Prometheus сам опрашивает targets, что упрощает контроль topology и health endpoint-ов.
TSDB с WAL + blocks
Данные проходят путь WAL -> head -> compacted blocks, формируя predictable storage lifecycle.
PromQL как язык анализа
PromQL оптимизирован под time-series векторы, агрегации по labels и окна по времени.
Rule-driven alerting
Recording/alerting rules и интеграция с Alertmanager дают управляемый контур реагирования.
Архитектура Prometheus по слоям
На high-level уровне Prometheus можно читать как конвейер: ingest -> TSDB head/WAL -> block storage -> PromQL/query engine -> rules/alerts -> внешние интеграции.
Ключевые особенности
Prometheus оптимизирован под мониторинг: pull ingest, TSDB с WAL/blocks, PromQL и rule-driven alerting.
Pull-модель
Label-модель
Жизненный цикл данных
DDL vs DML: модель для Prometheus
В Prometheus нет SQL-DDL/DML в классическом смысле. Но для архитектурного анализа полезно разделять DDL-like операции (изменение конфигурации scrape/rules) и DML-like операции (движение samples и PromQL read path).
Как работает модель DDL/DML в Prometheus
DDL-like: изменение scrape/rule topology. DML-like: движение samples и PromQL запросов.
1. Scrape / ingest
Samples + queriesScraper или remote write ingest получает новые samples.
2. WAL append
Samples + queriesСэмплы пишутся в WAL для durability перед дальнейшей обработкой.
3. Head update
Samples + queriesTSDB head обновляет series и label index для свежих данных.
4. PromQL execution
Samples + queriesQuery engine читает head и исторические blocks, выполняет агрегации.
5. Compaction + retention
Samples + queriesФоновая compaction уплотняет blocks и применяет политику retention.
Активный шаг
1. Scrape / ingest
Scraper или remote write ingest получает новые samples.
Поток данных и запросов
- DML-like путь охватывает ingest, хранение и чтение метрик через PromQL.
- Свежие данные живут в head, исторические - в compacted blocks.
- Кардинальность labels напрямую влияет на стоимость и latency запросов.
Источник
InfluxDB docs
Сравнительный контекст по альтернативному TSDB-профилю.
Prometheus vs InfluxDB
Базовый подход
Prometheus: Pull-scrape модель и tight-интеграция с monitoring workflow.
InfluxDB: Сильный акцент на ingest API и time-series хранилище для широкого класса telemetry use cases.
Язык запросов
Prometheus: PromQL с фокусом на метрики, labels и alert-driven аналитике.
InfluxDB: InfluxQL/Flux в зависимости от версии и сценария обработки данных.
Типичный production-профиль
Prometheus: Инфраструктурный мониторинг, SLO, алерты, Kubernetes observability.
InfluxDB: Monitoring + IoT + телеметрия, где нужен гибкий ingest и retention-политики.
Операционная модель
Prometheus: Часто комбинируется с federation/remote storage для long-term retention.
InfluxDB: Часто используется как самостоятельный TSDB-контур или managed deployment.
Почему Prometheus часто выбирают для мониторинга
Практическая интерпретация для system design контекста:
- Prometheus стал стандартом cloud-native мониторинга благодаря простой pull-модели и экосистеме вокруг Kubernetes.
- PromQL и rules позволяют строить один контур для наблюдаемости и alerting без отдельного DSL.
- TSDB-путь WAL -> head -> blocks делает поведение write/read path предсказуемым в production.
- Интеграция с Alertmanager, Grafana и remote storage дает гибкий путь от single-node до масштабируемой топологии.
Примеры PromQL запросов
Шпаргалка для типовых production-задач: от нагрузки и latency до SLO-контроля.
Throughput (RPS) по сервису
Оценить входящую нагрузку на `checkout-api` за последние 5 минут.
sum(rate(http_requests_total{service="checkout-api"}[5m]))Базовый индикатор скорости входящего трафика, обычно первый график в RED-панели.
P95 latency
Контролировать деградации задержки в пользовательском пути.
histogram_quantile(0.95, sum(rate(http_request_duration_seconds_bucket{service="checkout-api"}[5m])) by (le))Для p95/p99 используем `*_bucket`, а не среднее значение, чтобы видеть хвосты распределения.
Error rate (%)
Считать долю 5xx-ответов относительно общего трафика сервиса.
100 * (sum(rate(http_requests_total{service="checkout-api",status=~"5.."}[5m])) / sum(rate(http_requests_total{service="checkout-api"}[5m])))Частая основа для SLO-aligned alerting и burn-rate правил.
CPU saturation по pod
Найти поды, приближающиеся к CPU-лимитам.
sum(rate(container_cpu_usage_seconds_total{namespace="prod",pod=~"checkout-api-.*"}[5m])) by (pod)Полезно при тюнинге autoscaling и анализе «горячих» pod-экземпляров.
Top-k по памяти
Выделить самые «тяжелые» pod-экземпляры по рабочему набору памяти.
topk(5, container_memory_working_set_bytes{namespace="prod",pod=~"checkout-api-.*"})Быстрый срез для расследования OOMKill и корректировки requests/limits.
Error budget burn rate
Приблизить скорость расходования error budget для 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` означает, что бюджет ошибок расходуется быстрее допустимого.
References
Связанные главы
- Time Series Databases (TSDB): типы, trade-offs и выбор - Как позиционировать Prometheus среди других TSDB-подходов по latency, retention и операционной модели.
- Database Selection Framework - Фреймворк выбора, который помогает обосновать Prometheus как мониторинговый, а не универсальный analytical storage.
- Observability & Monitoring Design - Связка метрик Prometheus с логами, трассировками и SLO/SLI-контуром в production-наблюдаемости.
- Prometheus: The Documentary - Исторический контекст появления Prometheus и эволюции его экосистемы в cloud-native мире.
- Kubernetes Fundamentals - База для понимания service discovery, scrape-модели и operator-подхода в Kubernetes-кластерах.
- Service Discovery - Как автоматическое обнаружение targets определяет качество и стабильность metrics pipeline.
- VictoriaMetrics: история и архитектура - Сравнение Prometheus-совместимых стратегий хранения и масштабирования для long-term retention.