Чем pull-модель сбора метрик (как в Prometheus) отличается от push-модели (как в StatsD) и когда какая уместнее?

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

В pull-модели сервер мониторинга сам периодически опрашивает (scrape) эндпоинт /metrics у приложений; в push-модели приложение само отправляет метрики на сервер или в промежуточный агрегатор. Prometheus по умолчанию использует pull, что проще для контроля нагрузки и обнаружения "упавших" целей.

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

при pull Prometheus по конфигурации scrape_configs сам ходит по списку целей (статическому или через service discovery) и забирает текущие значения метрик раз в заданный интервал. При push клиент (приложение или StatsD-агент) сам инициирует отправку данных по сети на коллектор, который может их буферизовать и агрегировать.

Пример кода

config.yamlКопировать

# prometheus.yml — классическая pull-конфигурация
scrape_configs:
  - job_name: "app"
    scrape_interval: 15s
    static_configs:
      - targets: ["app-1:8080", "app-2:8080"]

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

• Практика. pull-модель удобна, когда сервер мониторинга может достать до всех целей по сети (типично внутри одного кластера/VPC), и позволяет легко увидеть, что цель недоступна (метрика up == 0). Push-модель нужна для короткоживущих задач (batch job, serverless-функция), которые завершаются быстрее scrape-интервала — для них в экосистеме Prometheus есть промежуточный Pushgateway.
• Практика. После запуска Prometheus на странице http://localhost:9090/targets оба инстанса app-1 и app-2 должны иметь статус UP; если один из них недоступен, метрика up{job="app"} станет равна 0, что можно сразу использовать как условие алерта.

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

• Частые ошибки. пытаться использовать pull для задач, которые живут секунды и завершаются до следующего scrape — метрика просто не попадёт в систему; злоупотреблять Pushgateway для обычных long-running сервисов, превращая его в единую точку отказа и теряя автоматическое определение "цель недоступна".