Pull-модель, TSDB и scrape

Урок объясняет ядро Prometheus: почему он сам ходит за метриками и где их хранит.

Prometheus — это система мониторинга, которая периодически сама опрашивает цели по HTTP, забирает метрики и складывает их в локальную базу временных рядов.

Многие системы мониторинга работают по push-модели: приложение само отправляет метрики в сборщик. Prometheus делает наоборот — это его фирменная черта, и она объясняет почти всё остальное в его устройстве.

Pull против push

В pull-модели Prometheus по расписанию обращается к каждой цели (target) по HTTP и читает её метрики. Цель просто отдаёт текущие значения по адресу /metrics — и ничего не знает про адрес Prometheus.

Плюсы pull-модели:

  • Prometheus всегда знает, какие цели он опрашивает, — список целей у него под контролем.
  • Если цель не ответила на scrape, это само по себе сигнал «сервис недоступен».
  • Цель не зависит от доступности Prometheus и не копит метрики в очередь.

Что такое scrape

Scrape — это один цикл опроса цели: Prometheus делает HTTP-GET на /metrics, парсит ответ и записывает значения с текущей меткой времени. Частота задаётся параметром scrape_interval (обычно 15–60 секунд).

# Посмотреть, что отдаёт цель, можно обычным curl
curl http://localhost:9100/metrics

Вывод:

node_cpu_seconds_total{cpu="0",mode="idle"} 184523.4
node_memory_MemAvailable_bytes 5.21e+09
...

Хранилище TSDB

TSDB (time-series database) — встроенная база Prometheus для временных рядов. Каждый ряд однозначно определяется именем метрики и набором лейблов; внутри ряда лежат пары «время → значение».

temperature{room="kitchen"}  ->  [(t1, 21.0), (t2, 21.4), (t3, 21.6)]
temperature{room="bedroom"}  ->  [(t1, 19.8), (t2, 19.9), (t3, 20.1)]

Как работает под капотом

Данные пишутся блоками по времени. Свежие сэмплы сначала попадают в память и в WAL (write-ahead log) для защиты от потери, затем периодически сбрасываются на диск компактными блоками по два часа. Старые блоки удаляются по сроку хранения (--storage.tsdb.retention.time). Поэтому Prometheus отлично хранит недели данных локально, но не годы — для долгого хранения метрики отдают во внешние системы.

[scrape] -> [head block в памяти + WAL] --каждые 2ч--> [блок на диске]
                                                          |
                                              удаление по retention.time

Частые ошибки

  • Ждать push там, где работает pull. Кратко живущие job'ы (cron, батчи) Prometheus может не успеть опросить — для них есть Pushgateway.
  • Рассчитывать на вечное хранение в TSDB. По умолчанию данные удаляются через 15 дней.
  • Скрейпить слишком часто без нужды. Маленький interval умножает объём данных и нагрузку.

Итог

  • Prometheus работает по pull-модели: сам опрашивает цели по HTTP.
  • Scrape — один цикл опроса /metrics с записью значений.
  • TSDB хранит ряды как «имя + лейблы → точки во времени», с ограниченным сроком хранения.
Проверьте себя
1. Что означает pull-модель в Prometheus?
AПриложения сами шлют метрики в Prometheus
BPrometheus сам периодически опрашивает цели по HTTP
CМетрики тянутся из базы данных
DМетрики приходят по email
2. Что такое scrape?
AОчистка диска
BОдин цикл опроса цели по /metrics с записью значений
CУдаление старых рядов
DТип алерта
3. Почему нельзя полагаться на TSDB как на вечное хранилище?
ATSDB не хранит лейблы
BДанные удаляются по сроку хранения (по умолчанию ~15 дней)
CTSDB работает только в RAM
DTSDB не поддерживает SELECT