Как в общих чертах устроена архитектура Prometheus и какую роль в ней играет TSDB?

Короткий ответ

Prometheus состоит из scrape-компонента (сборщик, который опрашивает цели), локальной time series database (TSDB) для хранения собранных рядов и движка PromQL для запросов; отдельно работает Alertmanager, который получает сработавшие правила алертов и занимается их маршрутизацией.

Как это работает подробнее

каждый scrape создаёт новую точку для каждого временного ряда (комбинация имени метрики и набора labels) и дописывает её в TSDB — специализированное хранилище, оптимизированное под append-only запись и сжатие похожих последовательных значений. Запросы PromQL читают данные напрямую из TSDB на том же сервере.

Пример кода

commands.shКопировать

# Посмотреть использование диска TSDB локального Prometheus
du -sh /prometheus/data
# Проверить фактический retention в запущенном процессе
curl -s http://localhost:9090/api/v1/status/flags | grep retention

Что использовать на практике

• Практика. один инстанс Prometheus 2.x хранит данные локально на диске (по умолчанию до 15 дней retention) и не реплицируется "из коробки" — для долгосрочного хранения и высокой доступности используют remote_write в системы типа Thanos, Mimir или VictoriaMetrics. Начинающему важно понимать, что Prometheus сам по себе — это один процесс с локальным диском, а не распределённая система.
• Практика. Команда покажет текущий объём данных на диске и настроенный storage.tsdb.retention.time; если диск растёт аномально быстро при том же числе сервисов, это сигнал высокой кардинальности метрик, а не нормального роста объёма данных.

Подводные камни

• Частые ошибки. ожидать от standalone Prometheus автоматической репликации или бесконечного retention; хранить метрики с высокой кардинальностью лейблов, из-за чего TSDB быстро разрастается и потребляет много RAM/диска; путать Prometheus (сборщик и хранилище) с Grafana (только визуализация, без собственного хранения метрик).