Files
vidconf/deploy/monitoring/prometheus.yml
Max Ronzhin ace5bf7a0d feat(monitoring): экспортер метрик по контейнерам поверх Docker Engine API
Разбивка по контейнерам (CPU/память/сеть) — то, что не смог дать
cAdvisor из-за несовместимости с containerd-снапшоттером сервера 1gb
(убран в 7f5c888). Свой минимальный сервис container-exporter (Python/
aiohttp/prometheus_client) опрашивает Docker Engine API параллельно в
фоновой задаче, не завязываясь на scrape-интервал Prometheus.

Доступ к докер-сокету изолирован через docker-socket-proxy: экспортеру
разрешены только GET /containers/json и /containers/*/stats, любые
изменяющие запросы блокируются на уровне прокси (POST=0) — полная
компрометация экспортера не даёт управлять Docker. Ни один из двух
сервисов не публикует портов наружу.

В host.json возвращены панели «Топ контейнеров по CPU/памяти» на новых
метриках vidconf_container_* (в 0.0.9 их убрали вместе с cAdvisor).
2026-07-28 01:39:42 +03:00

74 lines
4.4 KiB
YAML
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# Конфигурация Prometheus (devops) — сбор метрик backend,
# PostgreSQL, Redis, железа хоста, контейнеров и локального LLM-сервера.
# Поднимается compose-профилем `monitoring` (deploy/docker-compose.yml,
# сервис `prometheus`).
#
# Имена метрик backend (`vidconf_http_request_duration_seconds`,
# `vidconf_pipeline_sessions`, `vidconf_celery_queue_depth`) — КОНТРАКТ с
# `backend/api/metrics.py`; правила в `alerts.yml` используют их буквально —
# при переименовании метрик в backend поправить оба файла одновременно.
global:
scrape_interval: 15s
evaluation_interval: 15s
rule_files:
- /etc/prometheus/alerts.yml
scrape_configs:
# Backend FastAPI: латентность HTTP по маршрутам + gauge'и пайплайна и
# очередей Celery (см. GET /metrics, `backend/api/metrics.py`).
- job_name: backend
metrics_path: /metrics
static_configs:
- targets: ["backend:8000"]
# PostgreSQL (профиль monitoring — сервис postgres-exporter).
- job_name: postgres
static_configs:
- targets: ["postgres-exporter:9187"]
# Redis (профиль monitoring — сервис redis-exporter): также источник для
# алерта LlmDown нет, но по нему видно состояние брокера Celery отдельно
# от глубины очередей (та берётся из backend, не отсюда).
- job_name: redis
static_configs:
- targets: ["redis-exporter:9121"]
# Хост целиком: CPU, память, диск, сеть, load average (профиль monitoring
# — сервис node-exporter). Единственный источник, который покажет
# нехватку памяти/CPU на сервере, если она не проявится как рост
# латентности API (см. дашборд host.json).
- job_name: node
static_configs:
- targets: ["node-exporter:9100"]
# Метрики по каждому контейнеру (CPU/память/сеть отдельно у backend,
# worker, postgres и т.д. — профиль monitoring, сервис
# `container-exporter`). Отвечает на вопрос «какой из контейнеров ест
# ресурсы», в отличие от job `node` (только хост целиком). Замена
# cAdvisor (несовместим с containerd-снапшоттером сервера `1gb`, см.
# .forcc/JOURNAL.md) — свой экспортер поверх Docker Engine API,
# метрики `vidconf_container_*`, см. deploy/monitoring/container-exporter/.
- job_name: container-exporter
static_configs:
- targets: ["container-exporter:9419"]
# Локальный LLM-сервер (llama.cpp, LLAMA_ARG_ENDPOINT_METRICS=1). Адрес
# `llm:8080` разрешается ОДНИМ из двух compose-сервисов в зависимости от
# выбранного при установке пресета — `llm` (CPU, профиль `llm`, уровни
# min/medium) или `llm-gpu` (GPU, профиль `llm-gpu`, уровень max, у
# которого в сети compose есть сетевой алиас `llm`, см. его определение в
# deploy/docker-compose.yml) — эти профили взаимоисключающи, поэтому один
# job без дублирования и без вечно недоступного второго таргета.
#
# Закомментировано по умолчанию: целевой набор профилей compose —
# `media,monitoring` (см. .env.example, COMPOSE_PROFILES), БЕЗ `llm`/
# `llm-gpu` — таргет `llm:8080` в этом случае не резолвится вовсе, и
# Prometheus писал бы в лог постоянные ошибки скрейпа, а алерт `LlmDown`
# (deploy/monitoring/alerts.yml, тоже закомментирован) вечно оставался бы
# firing. Раскомментируйте оба вместе на инсталляциях с профилем
# `llm`/`llm-gpu` (пресеты 35 install.sh).
# - job_name: llm
# static_configs:
# - targets: ["llm:8080"]