Как работает Prometheus?

Принципы работы Prometheus

Prometheus — это open-source система мониторинга и алертинга, основанная на модели pull-модели сбора метрик и использующая многомерную data model с временными рядами (time series). Я использую его с 2015 года и наблюдал эволюцию экосистемы. Работа Prometheus основана на нескольких ключевых компонентах и принципах.

Архитектурные компоненты

Основные компоненты:

• Prometheus Server — ядро системы, ответственное за сбор, хранение и обработку метрик.
• Client Libraries — библиотеки для интеграции в приложения (Go, Java, Python, Ruby и др.).
• Exporters — агенты для сбора метрик со сторонних систем (Node Exporter, Blackbox Exporter и т.д.).
• Pushgateway — шлюз для кратковременных или batch-задач, работающих по модели push.
• Alertmanager — отдельный компонент для обработки и маршрутизации алертов.
• Service Discovery — механизмы автоматического обнаружения целей для мониторинга (Kubernetes, Consul, AWS и др.).

Процесс сбора метрик (Pull Model)

В отличие от многих систем, Prometheus не ждёт отправки данных, а активно запрашивает их у monitored targets. Этот процесс называется scraping.

1. Конфигурация целей: В prometheus.yml определяются targets (хосты, приложения, экспортеры) и endpoints (/metrics по умолчанию).

   scrape_configs:
     - job_name: 'node_exporter'
       static_configs:
         - targets: ['192.168.1.10:9100', '192.168.1.11:9100']
   

2. HTTP-запрос: Prometheus Server периодически (например, каждые 15s) отправляет HTTP GET запрос на endpoint /metrics каждой цели.

3. Ответ в формате текста: Цель возвращает ответ в текстовом формате, понятном Prometheus. Это простой, но эффективный человеко-читаемый формат.

   # HELP node_cpu_seconds_total Seconds the CPUs spent in each mode.
   # TYPE node_cpu_seconds_total counter
   node_cpu_seconds_total{cpu="0",mode="idle"} 10000.5
   node_cpu_seconds_total{cpu="0",mode="system"} 150.2
   http_requests_total{method="POST",handler="/api",status="200"} 42
   

4. Парсинг и сохранение: Prometheus парсит ответ, извлекает значения метрик с их labels (тегами) и сохраняет их во внутреннем TSDB (Time Series Database).

Модель данных: Time Series с Labels

Каждая временная серия (time series) однозначно идентифицируется:

• Именем метрики (metric name): http_requests_total
• Набором пар ключ-значение — labels (теги): {method="POST", handler="/api", status="200"}

Это позволяет выполнять мощные multi-dimensional запросы с использованием PromQL (Prometheus Query Language). Например, запрос ниже суммирует все HTTP-запросы, сгруппировав их по handler, но только для успешных статусов (200).

sum by (handler) (rate(http_requests_total{status="200"}[5m]))

Хранение данных

TSDB (Time Series Database) Prometheus хранит данные на локальном диске в эффективном формате:

• Данные разбиваются на блоки (blocks) по времени (обычно 2 часа).
• Актуальные данные пишутся в WAL (Write-Ahead Log) для целостности при сбоях, затем в память (memtable) и периодически сбрасываются на диск.
• Старые блоки компактируются и со временем удаляются согласно политике хранения (retention policy).

Процесс алертинга

1. Правила (Recording/Alerts Rules): В Prometheus определяются правила на PromQL. Alerting rules вычисляют условия для генерации алертов.

   groups:
     - name: example
       rules:
         - alert: HighRequestLatency
           expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
           for: 10m
           labels:
             severity: page
           annotations:
             summary: "High request latency on {{ $labels.instance }}"
   

2. Генерация алерта: Когда выражение expr возвращает результат и условие соблюдается дольше времени, указанного в for, Prometheus отправляет алерт в Alertmanager.

3. Обработка в Alertmanager: Alertmanager занимается дедупликацией, группировкой, маршрутизацией (по каналам: email, Slack, PagerDuty) и заглушением (silencing) алертов.

Ключевые особенности и ограничения

Сильные стороны:

• Простота развёртывания: Один бинарный файл, нет зависимостей.
• Мощный язык запросов (PromQL): Гибкость для анализа и агрегации.
• Надёжность: Одна нода Prometheus автономна. Проблемы сети или целей не ломают всю систему.
• Интеграция с Kubernetes: Нативная поддержка service discovery и концепций Kubernetes.
• Активное сообщество: Огромное количество готовых экспортеров и интеграций.

Ограничения (которые важно понимать):

• Pull-модель: Может быть неудобна для кратковживущих задач (используется Pushgateway).
• Хранение на локальном диске: Масштабирование по вертикали. Для горизонтального масштабирования нужны federation или Thanos/Cortex.
• Не 100% точность: Из-за pull-модели возможны небольшие расхождения в данных (например, если инстанс умер между скрейпами).
• Не подходит для хранения событий или логов: Оптимизирован именно для числовых метрик.

На практике Prometheus стал де-факто стандартом для мониторинга в cloud-native средах, особенно в связке с Kubernetes и Grafana для визуализации. Его модель данных и PromQL задали новый тренд в подходе к мониторингу, сместив фокус с простых графиков к multi-dimensional анализу работоспособности приложений и инфраструктуры.