Pull vs Push модели
Тема дорожной карты · Prometheus
Prometheus использует pull-модель сбора метрик, при которой сервер Prometheus периодически инициирует HTTP-запросы для опроса метрик с инструментированных целей. Это отличает его от push-систем, где приложения сами активно отправляют свои метрики в центральный коллектор. Pull-модель упрощает наблюдаемость самой системы мониторинга: если цель недоступна, метрика up в Prometheus принимает значение 0, что делает доступность целей непосредственно видимой, и устраняет необходимость знания целями адреса сервера мониторинга. Push-сбор в Prometheus поддерживается косвенно через Pushgateway, который выступает посредником для кратковременных пакетных заданий, недоступных для опроса по требованию. Pull-модель может создавать сложности в средах, где цели находятся за межсетевыми экранами или NAT, однако интеграции обнаружения сервисов и использование конфигураций перемаркировки позволяют нивелировать большинство подобных ситуаций. Понимание компромиссов между pull- и push-моделями важно при проектировании архитектуры мониторинга на основе Prometheus для различных сетевых топологий и типов приложений.
Как это работает
Pull vs Push модели — 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 только метрики.
Типичные ошибки
Ловушки Pull vs Push модели: high-cardinality labels (per-user-id, per-request-id — TSDB Prometheus давится); ожидание бесконечного retention от локальной TSDB (разумно держит ~15 дней, больше настраивается, но дорого); Prometheus как event log (это sampled-метрики — потери между scrapes не gaps, они не записаны).
Связанные понятия
Полезные ресурсы
Проверить знания (1)
Загрузка вопросов…