LGTM-стек #3: экспортёры nginx и RabbitMQ — один свой, второй встроенный

Два сервиса из типового стека — и два разных подхода к тому, откуда Prometheus берёт по ним метрики: у одного нужен отдельный процесс-переводчик, у второго экспорт уже встроен.

nginx сам по себе Prometheus не понимает — нужен отдельный nginx-prometheus-exporter, который читает встроенную страницу статуса nginx и переводит её в формат Prometheus. Для этого в самом nginx нужно включить stub_status:

server {
    listen 8080;
    location /stub_status {
        stub_status;
    }
}

Дальше сам экспортёр:

nginx-prometheus-exporter --nginx.scrape-uri=http://127.0.0.1:8080/stub_status

Слушает :9113/metrics по умолчанию. Метрик немного — stub_status в open-source nginx отдаёт только базовые счётчики соединений и запросов, не разбивку по location/upstream (это уже у nginx Plus через /api).

RabbitMQ, наоборот, с версии 3.8.0 несёт экспортёр метрик прямо в себе — плагин rabbitmq_prometheus, разработанный самой командой RabbitMQ, отдельно ставить ничего не нужно:

rabbitmq-plugins enable rabbitmq_prometheus
curl http://localhost:15692/metrics

Порт 15692, путь /metrics — оба значения дефолтные. По умолчанию метрики агрегированы (без разбивки по каждой очереди отдельно) — на хосте с десятками тысяч очередей неагрегированный вывод может весить десятки мегабайт и генерироваться до минуты. Если нужна разбивка по конкретным очередям — отдельный путь:

curl http://localhost:15692/metrics/per-object

или временное включение без перезапуска:

rabbitmqctl eval 'application:set_env(rabbitmq_prometheus, return_per_object_metrics, true).'

Разница на практике: для nginx придётся держать в голове ещё один процесс и следить, что он живой сам по себе (типичный failure mode — экспортёр упал, а nginx работает, и мониторинг тихо ослеп). Для RabbitMQ отдельного процесса нет — метрики умирают только вместе с самим брокером, что само по себе полезный сигнал.

#prometheus #nginx #rabbitmq #lgtm