Практикум Prometheus — архитектура и модель данных
Практикум, шаг 1 из 9. Дальше — установка.
Зачем Prometheus
Prometheus — система мониторинга и алертинга с открытым исходным кодом, де-факто стандарт для Kubernetes и cloud-native. В отличие от Zabbix с единым UI и push-агентами, Prometheus строится вокруг pull-опроса HTTP-эндпоинтов /metrics и языка запросов PromQL.
Цепочка работы:
- Scrape — сервер Prometheus по расписанию забирает метрики с targets.
- Store — значения пишутся в локальную TSDB (time series database).
- Query — PromQL и HTTP API для графиков и правил.
- Alert — alerting rules → Alertmanager → каналы оповещений.
Подробное сравнение с Zabbix и ELK — в главе про мониторинг. PromQL отработаете на шаге 3 и в галерее Lab.
Архитектурные компоненты
| Компонент | Назначение |
|---|---|
| Prometheus Server | Scrape, TSDB, rule engine, web UI (:9090) |
| Exporters | Адаптеры для ОС, БД, SNMP — отдают текстовый exposition format |
| Pushgateway | Буфер для краткоживущих jobs (CI, cron), которые Prometheus не успеет опросить |
| Alertmanager | Группировка, inhibition, маршрутизация алертов |
| Service discovery | Kubernetes, Consul, DNS, file_sd — динамический список targets |
Официальный обзор — Introduction / Overview.
Pull и push
| Модель | Кто инициирует | Плюсы | Минусы |
|---|---|---|---|
| Pull (Prometheus) | Сервер мониторинга | Централизованный контроль targets, проще обнаружить "мёртвый" scrape | Нужен доступ с Prometheus к каждому эндпоинту |
| Push (Zabbix active, OTel) | Агент или приложение | Удобно за NAT, для batch | Сложнее контролировать кардинальность |
Prometheus по умолчанию pull; исключение — Pushgateway для одноразовых задач. Телеметрия через OpenTelemetry часто идёт push в collector, который уже может отдавать метрики Prometheus scrape или remote_write.
Модель данных
Каждая метрика — временной ряд с именем и метками (labels):
http_requests_total{job="api", instance="10.0.0.5:8080", method="GET", status="200"} 1024
- Имя — что измеряем (
http_requests_total,node_cpu_seconds_total). - Labels — измерения (job, instance, method, status).
- Значение — число с timestamp при каждом scrape.
Каждая уникальная комбинация labels — отдельный ряд в памяти. Метка user_id с миллионами значений "убьёт" Prometheus. Для идентификаторов запросов используйте логи и трассировки (шаг 7).
Что Prometheus не заменяет
| Задача | Инструмент в экосистеме |
|---|---|
| Долгое хранение (>15–30 дней) | Mimir, Thanos, Cortex |
| Полнотекстовые логи | Loki, ELK |
| Распределённые трейсы | Tempo, Jaeger |
| Профили CPU/heap | Pyroscope |
| Единый UI корреляции | Grafana |
Prometheus закрывает метрики и алерты по метрикам; полная observability собирается вокруг него.
Место в стеке Grafana Labs
Современный маршрут Grafana Labs (часто LGTM+):
- Loki — логи
- Grafana — визуализация и alerting
- Tempo — трейсы
- Mimir — долгосрочные метрики (remote storage для Prometheus)
- Alloy — единый агент вместо связки Prometheus Agent + Promtail + OTel Collector
- Beyla — eBPF-метрики без изменения кода
- Faro — Real User Monitoring (браузер)
- Pyroscope — continuous profiling
В этом практикуме Prometheus остаётся точкой входа; расширение — в шагах 7–9.
Проверка понимания
- Чем target отличается от job?
- Зачем Pushgateway, если Prometheus pull?
- Почему высокая кардинальность labels опасна?
Установите сервер и получите первый график — шаг 2. Ориентир — First steps и Getting started.