Все предыдущие посты серии — про то, что кормит Prometheus метриками (node_exporter, postgres_exporter, rabbitmq_prometheus) — сам Prometheus в стеке до сих пор не появлялся. Пора закрыть пробел: это сердце модели “L” (метрики) в LGTM, и модель работы у него принципиально другая, чем у Loki/Tempo.
Главное архитектурное отличие: Prometheus сам ходит за метриками (pull), а не ждёт, пока их пришлют (push, как в Graphite/StatsD). Конфиг — scrape_configs:
scrape_configs:
- job_name: "node"
static_configs:
- targets: ["localhost:9100"]
- job_name: "postgres"
static_configs:
- targets: ["localhost:9187"]
Каждые scrape_interval (по умолчанию 1 минута, обычно ставят 15-30 секунд) Prometheus сам приходит на /metrics каждого таргета и забирает текущие значения.
Метрики хранятся локально, в собственной TSDB (time series database) на диске сервера — никакой внешней БД не требуется для базовой работы. Запросы — на PromQL:
rate(node_cpu_seconds_total{mode="idle"}[5m])
rate() — скорость роста counter-метрики за интервал (для counter-ов, которые только растут, смотреть на абсолютное значение бессмысленно — важна именно скорость изменения), [5m] — окно, по которому считается rate.
Локальное хранилище — не рассчитано на годы истории и множество реплик; для долгосрочного хранения и горизонтального масштабирования метрики отдают дальше через remote_write:
remote_write:
- url: "http://localhost:9009/api/v1/push"
Это тот же путь, что описан у Mimir — сам Prometheus в таком режиме превращается в локальный буфер и точку сбора, а долгая история и запросы по ней уезжают в отдельную систему.
#prometheus #lgtm