Архитектура Prometheus: как устроен сбор метрик

«Понимание архитектуры экономит часы отладки»

#Почему важно понимать архитектуру

Можно скопировать конфиг из туториала и запустить Prometheus. Но когда что-то пойдёт не так (а оно пойдёт), вы будете беспомощны.

Понимание того, как Prometheus собирает, хранит и обрабатывает метрики, даст вам:

Уверенность в настройке конфигурации
Способность диагностировать проблемы
Понимание, как масштабировать систему

#Компоненты Prometheus

Prometheus — это не один бинарник, а экосистема компонентов:

┌─────────────────────────────────────────────────────────────┐
│                    Prometheus Server                         │
│  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
│  │   Scraper   │  │   TSDB      │  │   HTTP Server       │  │
│  │  (сбор)     │  │ (хранение)  │  │   (запросы API)     │  │
│  └─────────────┘  └─────────────┘  └─────────────────────┘  │
└─────────────────────────────────────────────────────────────┘
         │                    │                     │
         │                    │                     │
         ▼                    ▼                     ▼
   ┌──────────┐         ┌──────────┐          ┌──────────┐
   │ Targets  │         │  Disk    │          │  Grafana │
   │(экспортеры)│         │(данные)  │          │   UI     │
   └──────────┘         └──────────┘          └──────────┘

#Prometheus Server

Ядро системы. Один бинарник, который делает всё:

Сканирует цели (targets) по расписанию
Хранит метрики в базе данных временных рядов (TSDB)
Отвечает на HTTP-запросы (API, UI, PromQL)

Важно: Prometheus — это single binary. Никаких отдельных сервисов для сбора, хранения и запросов. Это упрощает развёртывание и отладку.

#Targets (Цели)

Targets — это источники метрик, которые Prometheus опрашивает.

Обычно targets — это экспортёры: небольшие сервисы, которые отдают метрики в формате Prometheus.

Примеры экспортёров:

Node Exporter — метрики Linux (CPU, память, диск, сеть)
cAdvisor — метрики контейнеров Docker
Blackbox Exporter — проверка доступности (HTTP, TCP, ICMP)
Ваше приложение — если добавить клиентскую библиотеку Prometheus

Каждый target отдаёт метрики на HTTP-эндпоинте (обычно /metrics):

# Пример ответа от target
$ curl http://localhost:9100/metrics

# 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"} 123456.78
node_cpu_seconds_total{cpu="0",mode="user"} 23456.12

#Service Discovery

Service Discovery (обнаружение сервисов) — механизм, который говорит Prometheus, какие цели опрашивать.

В простейшем случае — это статический список в конфиге:

scrape_configs:
  - job_name: 'node'
    static_configs:
      - targets: ['localhost:9100', 'server2:9100']

Но в динамической среде (Docker, Kubernetes) цели постоянно меняются. Тогда используют динамическое обнаружение:

Docker SD — автоматически находит контейнеры
Kubernetes SD — автоматически находит поды и сервисы
Consul SD — интеграция с Consul
File SD — чтение из JSON-файлов, которые обновляются внешними скриптами

#TSDB (Time Series Database)

TSDB — встроенная база данных временных рядов.

Ключевые особенности:

Хранит данные на диске в своём формате (не требует внешней БД)
Сжимает данные — типичное сжатие 1-2 байта на точку
Разделяет данные по времени — каждый час в отдельный блок
Поддерживает запросы — PromQL выполняется напрямую к TSDB

Структура хранения:

prometheus_data/
├── wal/           # Write Ahead Log (последние данные)
├── 01ABCDEF...   # Блок за 1 час
├── 01GHIJKL...   # Блок за следующий час
└── ...

WAL (Write Ahead Log) хранит последние 2-3 часа данных для быстрого доступа. Старые данные упаковываются в блоки (по 1 часу по умолчанию) и сжимаются.

#HTTP Server

Prometheus предоставляет HTTP API для:

Запросов PromQL (/api/v1/query)
Диапазонных запросов (/api/v1/query_range)
Метаданных (/api/v1/targets, /api/v1/rules)
Admin API (/api/v1/admin/tsdb/snapshot — снятие снепшотов)

Grafana и другие инструменты используют это API для получения данных.

#Жизненный цикл метрики

Давайте проследим путь метрики от источника до запроса:

1. Сбор        2. Обработка      3. Хранение       4. Запрос
   ↓              ↓                 ↓                 ↓
Target → Prometheus → TSDB → PromQL → Результат

#Шаг 1: Сбор (Scraping)

Prometheus по расписанию (по умолчанию каждые 15 секунд) делает HTTP-запрос к каждому target:

GET /metrics HTTP/1.1
Host: localhost:9100

Target отвечает текстом в формате Prometheus:

# HELP node_memory_MemTotal_bytes Memory information field MemTotal_bytes.
# TYPE node_memory_MemTotal_bytes gauge
node_memory_MemTotal_bytes 16777216000

Важно: формат текстовый, человекочитаемый. Это упрощает отладку — можно просто curl и посмотреть.

#Шаг 2: Обработка

Prometheus парсит ответ и преобразует в внутренний формат:

Метрика: node_memory_MemTotal_bytes
Тип: gauge
Значение: 16777216000
Время: 2026-03-18T14:30:00Z
Лейблы: {instance="localhost:9100", job="node"}

Лейблы добавляются автоматически:

instance — адрес target (хост:порт)
job — имя задачи из конфигурации

Можно добавлять свои лейблы через relabel_configs.

#Шаг 3: Хранение

Метрика записывается в TSDB:

Сначала в WAL (быстрая запись на диск)
Периодически данные упаковываются в блоки (сжатие)
Старые блоки можно удалять или переносить в долговременное хранилище (Thanos, Cortex)

Важно: Prometheus хранит данные локально. Для долгосрочного хранения и глобального поиска нужны дополнительные инструменты (Thanos, Cortex, Mimir).

#Шаг 4: Запрос

Пользователь пишет PromQL-запрос:

node_memory_MemTotal_bytes{instance="localhost:9100"}

Prometheus:

Парсит запрос
Находит нужные временные ряды в TSDB
Выполняет вычисления (если есть агрегации, функции)
Возвращает результат

#Типы метрик в Prometheus

Prometheus понимает четыре типа метрик. Понимание типов критично для правильных запросов.

#Counter (Счётчик)

Counter — метрика, которая только растёт (или сбрасывается в 0).

Примеры:

Количество обработанных запросов
Количество ошибок
Время работы процесса

http_requests_total{method="GET", path="/api"} 12345

Важно: counter не может уменьшаться. Если он уменьшился (например, после перезапуска), Prometheus считает это reset и корректирует расчёты.

Когда использовать: для подсчёта событий за период времени.

Типичный запрос: «сколько запросов в секунду?»

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

#Gauge (Датчик)

Gauge — метрика, которая может расти и уменьшаться.

Примеры:

Использование памяти
Температура CPU
Количество активных подключений

node_memory_MemAvailable_bytes 8589934592

Когда использовать: для измерения текущего состояния.

Типичный запрос: «сколько памяти доступно сейчас?»

node_memory_MemAvailable_bytes  # текущее значение

#Histogram (Гистограмма)

Histogram — распределение значений по «корзинам» (buckets).

Примеры:

Время ответа API (сколько запросов уложились в 100ms, 250ms, 500ms...)
Размер запросов
Длительность операций

http_request_duration_seconds_bucket{le="0.1"} 100    # 100 запросов <= 100ms
http_request_duration_seconds_bucket{le="0.25"} 150   # 150 запросов <= 250ms
http_request_duration_seconds_bucket{le="0.5"} 180    # 180 запросов <= 500ms
http_request_duration_seconds_bucket{le="+Inf"} 200   # всего 200 запросов
http_request_duration_seconds_sum 45.5                # сумма всех времён
http_request_duration_seconds_count 200               # количество запросов

Важно: histogram создаёт несколько метрик автоматически:

..._bucket — по одной на каждый bucket
..._sum — сумма всех значений
..._count — количество наблюдений

Когда использовать: для анализа распределения (например, перцентили задержки).

Типичный запрос: «95-й перцентиль времени ответа?»

histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))

#Summary (Саммари)

Summary — как histogram, но вычисляет перцентили на стороне клиента.

Примеры:

Те же, что у histogram

http_request_duration_seconds{quantile="0.5"} 0.1    # 50-й перцентиль = 100ms
http_request_duration_seconds{quantile="0.95"} 0.25  # 95-й перцентиль = 250ms
http_request_duration_seconds_sum 45.5
http_request_duration_seconds_count 200

Разница с histogram:

Histogram: бакеты на стороне клиента, перцентили вычисляются в запросе
Summary: перцентили вычисляются на клиенте, нельзя агрегировать across instances

Когда использовать: реже, чем histogram. Summary нельзя агрегировать, что ограничивает гибкость запросов.

#Job и Instance: группировка целей

Prometheus группирует цели для удобства:

Job — логическая группа целей (например, «node», «api», «database»).

Instance — конкретный target внутри job (например, localhost:9100, server2:9100).

scrape_configs:
  - job_name: 'node'        # ← Job
    static_configs:
      - targets:            # ← Instances
          - 'localhost:9100'
          - 'server2:9100'

В метрики автоматически добавляются лейблы:

job="node"
instance="localhost:9100"

Это позволяет фильтровать:

«Покажи CPU для всех node»: {job="node"}
«Покажи CPU для конкретного сервера»: {instance="localhost:9100"}

#Pull-модель: преимущества и ограничения

Мы уже говорили, что Prometheus использует pull-модель. Давайте разберём последствия этого решения.

#Преимущества

Контроль частоты сбора — Prometheus решает, как часто опрашивать
Легкое добавление целей — просто добавь в конфиг (или service discovery)
Централизованная конфигурация — всё в одном месте
Проще обработка недоступных целей — Prometheus сам видит таймауты

#Ограничения

Target должен быть доступен из Prometheus — нужна сетевая связность
Кратковременные задачи — batch job может завершиться до того, как Prometheus её опросит
NAT и фаерволы — сложнее, если target за NAT

Решение для batch jobs: Pushgateway — отдельный сервис, который принимает метрики от кратковременных задач, а Prometheus забирает их оттуда.

┌─────────────────────────────────────────────────────────────┐ │ Prometheus Server │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────────────┐ │ │ │ Scraper │ │ TSDB │ │ HTTP Server │ │ │ │ (сбор) │ │ (хранение) │ │ (запросы API) │ │ │ └─────────────┘ └─────────────┘ └─────────────────────┘ │ └─────────────────────────────────────────────────────────────┘ │ │ │ │ │ │ ▼ ▼ ▼ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ Targets │ │ Disk │ │ Grafana │ │(экспортеры)│ │(данные) │ │ UI │ └──────────┘ └──────────┘ └──────────┘

prometheus_data/ ├── wal/ # Write Ahead Log (последние данные) ├── 01ABCDEF... # Блок за 1 час ├── 01GHIJKL... # Блок за следующий час └── ...

1. Сбор 2. Обработка 3. Хранение 4. Запрос ↓ ↓ ↓ ↓ Target → Prometheus → TSDB → PromQL → Результат

http_request_duration_seconds_bucket{le="0.1"} 100 # 100 запросов <= 100ms http_request_duration_seconds_bucket{le="0.25"} 150 # 150 запросов <= 250ms http_request_duration_seconds_bucket{le="0.5"} 180 # 180 запросов <= 500ms http_request_duration_seconds_bucket{le="+Inf"} 200 # всего 200 запросов http_request_duration_seconds_sum 45.5 # сумма всех времён http_request_duration_seconds_count 200 # количество запросов

http_request_duration_seconds{quantile="0.5"} 0.1 # 50-й перцентиль = 100ms http_request_duration_seconds{quantile="0.95"} 0.25 # 95-й перцентиль = 250ms http_request_duration_seconds_sum 45.5 http_request_duration_seconds_count 200