Архитектура Prometheus

Архитектура Prometheus построена вокруг центрального сервера, который с регулярными интервалами опрашивает (pulls) метрики инструментированных целей и хранит их в локальной базе данных временных рядов (TSDB). Основные компоненты включают сам сервер Prometheus (с HTTP-опросчиком, движком хранилища TSDB и движком запросов PromQL), экспортёры, открывающие метрики на HTTP-эндпоинтах, Alertmanager для маршрутизации оповещений и уведомлений, а также Pushgateway для обработки кратковременных пакетных заданий. Prometheus по умолчанию использует pull-модель, то есть сервер сам инициирует соединения для опроса целей, а не цели отправляют метрики на сервер; это упрощает отладку и делает доступность целей непосредственно наблюдаемой через метрику up. Интеграции обнаружения сервисов позволяют Prometheus динамически находить цели в таких средах, как Kubernetes, Consul, EC2 и других, без ручного обновления конфигурации. Архитектура Prometheus намеренно простая и самодостаточная, ставящая во главу угла надёжность и корректность в ущерб распределённой сложности, хотя её можно расширить удалёнными хранилищами для долгосрочного хранения.

Как это работает

Архитектура Prometheus — pull-based система мониторинга временных рядов. Prometheus-сервер скрейпит HTTP /metrics-эндпойнты по расписанию, хранит samples в локальной TSDB, отвечает на запросы через PromQL. Модель данных multi-dimensional: каждый временной ряд идентифицируется именем метрики + набором key=value labels. Естественно пара с Grafana (визуализация), Alertmanager (роутинг алертов), node_exporter / app SDK (экспозиция метрик).

Когда применять

Prometheus — для любого современного observability-стека: де факто стандарт. Pull-модель хорошо ложится на динамические среды (Kubernetes service discovery). Для долгого retention или высокой cardinality — pair с long-term storage backend (Thanos, Cortex, VictoriaMetrics, Mimir). Не для логов (используйте Loki) или distributed tracing (Jaeger/Tempo) — Prometheus только метрики.

Типичные ошибки

Ловушки Архитектура Prometheus: high-cardinality labels (per-user-id, per-request-id — TSDB Prometheus давится); ожидание бесконечного retention от локальной TSDB (разумно держит ~15 дней, больше настраивается, но дорого); Prometheus как event log (это sampled-метрики — потери между scrapes не gaps, они не записаны).

Связанные понятия

• Введение в Prometheus
• Что такое Prometheus
• Сценарии применения
• Pull vs Push модели