Prometheus

Prometheus — открытая система мониторинга и база данных временных рядов. Она периодически опрашивает сервисы по HTTP, забирает у них текущие значения метрик, хранит их у себя с привязкой к меткам (labels) и позволяет строить запросы на языке PromQL — для графиков, анализа и правил алертов.^[1] Prometheus стал стандартом мониторинга в облачной инфраструктуре и в Kubernetes: почти любое серверное ПО умеет отдавать метрики в его формате.

История

Систему начали в 2012 году инженеры SoundCloud — выходцы из Google, вдохновлённые внутренней системой Borgmon. В январе 2015 года проект открыли публично, в 2016-м он стал вторым проектом CNCF после Kubernetes, а в августе 2018 года — вторым её выпускником.^[5] Формат метрик лёг в основу открытого стандарта OpenMetrics.^[7] В ноябре 2024 года вышла версия 3.0 с новым веб-интерфейсом, поддержкой UTF-8 в именах и приёмом данных по протоколу OpenTelemetry.^[6]

Архитектура

• Сервер Prometheus по расписанию (обычно раз в 15–60 секунд) опрашивает цели (targets) — HTTP-эндпоинты /metrics — и записывает результат в локальную базу временных рядов (TSDB).
• Обнаружение целей (service discovery) — статический список или автоматическое: из Kubernetes, Consul, облачных API, DNS.
• Экспортеры — программы-переводчики для систем без собственных метрик: node_exporter (метрики Linux-хоста), postgres_exporter, blackbox_exporter (внешние проверки HTTP, TCP, ICMP).
• Alertmanager — отдельный компонент, получающий сработавшие алерты, группирующий и рассылающий их (см. Мониторинг и алертинг).
• Pushgateway — промежуточный узел для короткоживущих задач (cron), которые не доживают до опроса.

Модель pull — главное отличие от многих систем: не сервис отправляет данные, а Prometheus их забирает. Так проще понять, жива ли цель (up == 0), и нельзя «завалить» сервер потоком от сбойного клиента.

Модель данных

Временной ряд определяется именем метрики и набором меток:

http_requests_total{method="GET", handler="/api/users", code="200"}  1027

Каждое уникальное сочетание меток — отдельный ряд. Поэтому в метки нельзя класть значения с неограниченным разнообразием — идентификаторы пользователей, полные URL, email: число рядов («кардинальность») взрывается, и сервер исчерпывает память.^[4]

Четыре типа метрик:^[2]

PromQL

# запросов в секунду за последние 5 минут, по обработчикам
sum by (handler) (rate(http_requests_total[5m]))

# доля ошибок 5xx
sum(rate(http_requests_total{code=~"5.."}[5m])) / sum(rate(http_requests_total[5m]))

# 95-й перцентиль задержки по гистограмме
histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

# диски, которые заполнятся в ближайшие 4 часа при текущем темпе
predict_linear(node_filesystem_avail_bytes[1h], 4 * 3600) < 0

К счётчикам почти всегда применяют rate() или increase(): само значение счётчика малоинформативно, важна скорость роста.^[3] Частые сложные запросы заранее вычисляют recording rules — правила, сохраняющие результат как новый ряд.

Пример конфигурации

# prometheus.yml
global:
  scrape_interval: 30s
scrape_configs:
  - job_name: node
    static_configs:
      - targets: ["10.0.0.11:9100", "10.0.0.12:9100"]
  - job_name: api
    metrics_path: /metrics
    static_configs:
      - targets: ["api.internal:8000"]
rule_files: ["alerts.yml"]
alerting:
  alertmanagers:
    - static_configs: [{targets: ["alertmanager:9093"]}]

В Kubernetes установку и описание целей обычно берёт на себя Prometheus Operator (через Helm-чарт kube-prometheus-stack), где цели задаются объектами ServiceMonitor.

Инструментирование приложения

Клиентские библиотеки есть для всех популярных языков. Пример на Python:

from prometheus_client import Counter, Histogram, start_http_server

REQUESTS = Counter("app_requests_total", "Обработанные запросы", ["status"])
LATENCY = Histogram("app_request_duration_seconds", "Время обработки")

start_http_server(8000)   # отдаёт /metrics

@LATENCY.time()
def handle(req):
    ...
    REQUESTS.labels(status="ok").inc()

Ограничения и экосистема

Один сервер Prometheus хранит данные локально и не масштабируется горизонтально; долгий срок хранения и глобальный обзор нескольких кластеров дают совместимые системы Thanos, Grafana Mimir, VictoriaMetrics, принимающие данные через remote_write. Prometheus не предназначен для логов и событий с точными значениями (например, биллинга): метрики — это агрегаты с потерей деталей. Визуализацию строят в Grafana, встроенный интерфейс годится для разовых запросов.

См. также

• Мониторинг и алертинг
• Grafana
• Логирование и трассировка (OpenTelemetry)
• SRE, SLO и SLA

Источники

1. Prometheus Docs — Overview
2. Prometheus Docs — Metric types
3. Prometheus Docs — Querying basics (PromQL)
4. Prometheus Docs — Instrumentation best practices
5. CNCF — Prometheus graduation announcement (2018)
6. Prometheus Blog — Announcing Prometheus 3.0 (2024)
7. OpenMetrics specification