Что такое Prometheus Pushgateway?

Что такое Prometheus Pushgateway?

Prometheus Pushgateway — это специальный вспомогательный компонент экосистемы Prometheus, предназначенный для сбора метрик от кратковременных (short-lived) или периодических (batch) задач, которые не могут быть отсканированы (scraped) основным сервером Prometheus стандартным способом, то есть по механизму pull-модели. Это официальный проект, поддерживаемый сообществом Prometheus.

Основная проблема, которую решает Pushgateway

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

• Пакетных заданий (Batch Jobs): Например, ночной ETL-процесс, задача cron, скрипт, запускаемый по расписанию. Задача выполняется несколько минут или часов и завершается. Prometheus просто не успеет или не сможет достучаться до неё в момент её существования.
• Одноразовых задач (One-off Jobs): Скрипт развёртывания, миграции, ручной запуск.
• Сервисов, не способных предоставлять HTTP-эндпоинт /metrics: Например, некоторые утилиты командной строки.

Для таких случаев и существует Pushgateway. Он выступает в роли промежуточного буфера или кэша.

Как работает Pushgateway? Принцип "Push-to-Pull"

Механизм работы можно описать так:

1. Push (Проталкивание метрик): Ваша кратковременная задача, непосредственно перед своим завершением, проталкивает (pushes) свои итоговые метрики в Pushgateway, используя HTTP POST-запрос. Обычно для этого используется клиентская библиотека Prometheus (например, для Python, Go, Java) или простой curl.

    **Пример отправки метрики через curl:**

```bash
echo "my_batch_job_duration_seconds 42.5" | curl --data-binary @- http://pushgateway.example.com:9091/metrics/job/my_batch_job/instance/`hostname`
```

    Обратите внимание на структуру URL: в путь часто включаются ключевые метки (`job`, `instance`), чтобы идентифицировать источник.

1. Хранение (Buffering): Pushgateway хранит полученные метрики в памяти до тех пор, пока они не будут забраны Prometheus. Метрики от каждой задачи сохраняются отдельно, идентифицируясь по набору меток (labels).

2. Pull (Забор метрик Prometheus): Сервер Prometheus настраивается на сканирование (scraping) Pushgateway как обычной цели (target) с фиксированным интервалом (например, каждые 15 секунд). Таким образом, Prometheus забирает (pulls) все накопленные в Pushgateway метрики, как если бы это был обычный экспортёр.

    **Пример конфигурации Prometheus (`prometheus.yml`):**

```yaml
scrape_configs:
  - job_name: 'pushgateway'
    honor_labels: true  # Критически важная настройка!
    static_configs:
      - targets: ['pushgateway.example.com:9091']
```

    Опция **`honor_labels: true`** крайне важна, так как указывает Prometheus доверять меткам, пришедшим от задачи через Pushgateway, а не перезаписывать их.

Ключевые характеристики и особенности

• Назначение меток (Labeling): Все метрики, отправляемые в Pushgateway, должны иметь как минимум метки job и instance. Это фундаментальное отличие от обычных экспортёров и важнейшее правило.
• Состояние (Stateful): Pushgateway хранит состояние. Если задача завершилась и отправила метрику my_job_success 1, эта метрика будет оставаться в Pushgateway до тех пор, пока её не перезапишет другая задача с таким же набором меток, либо пока не будет удалена вручную (через API). Это может привести к устаревшим (stale) данным.
• Не для долгоживущих сервисов!: Это самое важное предупреждение. Pushgateway НЕ является заменой pull-модели для мониторинга долгоживущих сервисов. Его неправильное использование приводит к:

    *   **Потере преимуществ pull-модели**: Prometheus больше не может определять доступность сервиса (up/down), так как Pushgateway всегда доступен.
    *   **Накоплению устаревших метрик**.
    *   **Созданию единой точки отказа (SPOF)**: Все метрики проходят через один узел.

• Управление жизненным циклом метрик: Для удаления устаревших метрик из Pushgateway необходимо использовать его HTTP API (DELETE запросы), что часто включается в логику самих пакетных задач (удалить старые метрики перед отправкой новых) или настраивается как отдельная очистка.

Когда использовать Pushgateway? (Use Cases)

1. Мониторинг пакетных/периодических заданий: Классический пример. Измерение длительности выполнения, коды завершения (success/failure), количество обработанных записей.
2. Демоны, не предоставляющие HTTP: Сервисы, которые не могут или не должны открывать порт для Prometheus.
3. Сценарии "последнего вздоха" (Last Resort): Отправка финальных метрик от падающего сервиса, который не может обслуживать /metrics эндпоинт до конца своей жизни.
4. Мост из других систем (Ad-hoc): Временное решение для интеграции систем, которые могут только отправлять (push) данные, но не могут обслуживать pull-запросы.

Краткий итог

Prometheus Pushgateway — это специализированный буфер, который позволяет временным задачам "протолкнуть" свои финальные метрики в экосистему Prometheus, сохраняя при этом общий принцип pull-модели для самого сервера мониторинга. Его использование требует чёткого понимания ограничений и предназначено для узкого класса задач, где классический pull-подход неприменим. Золотое правило: если сервис может предоставлять /metrics эндпоинт, он должен делать это, и Prometheus должен сканировать его напрямую, без посредников. Pushgateway — это исключение, а не правило.