Max Ronzhin
a53ba7c827
`node_network_*` показывал трафик собственного `eth0` экспортера (56 МБ) вместо хостового `enp3s0` (39.8 ГБ). При разборе нагрузочного теста 28.07 сетевых метрик хоста не оказалось вовсе — весь анализ трафика пришлось вести по метрикам контейнеров. Причина не в конфигурации экспортера, а в устройстве procfs: bind-mount `/proc` хоста достаточен для CPU, памяти и диска, но `/proc/net` — это симлинк на `self/net`, который резолвится в сетевом namespace читающего процесса. Никакое монтирование это не обходит, нужен host network namespace. Прежний комментарий в compose утверждал обратное — исправлен. Порт 9100 теперь слушается на хосте, наружу не торчит: ufw пропускает только 22/80/443/3478/7881/51820 и UDP-диапазон LiveKit. Prometheus обращается к экспортеру через `host.docker.internal` (`extra_hosts: host-gateway`), потому что по имени сервиса в docker-сети он больше не резолвится. Дашборд `host.json` правок не требует: сетевые панели фильтруют интерфейсы по исключению (`device!~"lo|veth.*|docker.*|br-.*"`), под которое `enp3s0` не подпадает. Алерты на имя instance не завязаны.
107 lines
7.0 KiB
YAML
107 lines
7.0 KiB
YAML
# Конфигурация 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).
|
||
#
|
||
# Адрес `host.docker.internal`, а не `node-exporter:9100`: с 2026-07-28
|
||
# экспортер работает в host-сети и по имени сервиса в docker-сети не
|
||
# резолвится. Причина перевода — сетевые метрики: `/proc/net` это симлинк
|
||
# на `self/net`, поэтому в bridge-сети экспортер отдавал трафик
|
||
# собственного `eth0` вместо хостового `enp3s0`. Имя резолвится через
|
||
# `extra_hosts: host-gateway` у сервиса prometheus (deploy/docker-compose.yml).
|
||
- job_name: node
|
||
static_configs:
|
||
- targets: ["host.docker.internal: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"]
|
||
|
||
# LiveKit SFU (профиль `media`). Порт объявлен в самом LiveKit —
|
||
# `deploy/livekit/livekit.yaml.template`, секция `prometheus: port: 6789`;
|
||
# наружу он не публикуется, скрейп идёт по имени сервиса внутри docker-сети.
|
||
#
|
||
# Почему это важно отдельно от `container-exporter`: тот показывает CPU,
|
||
# память и суммарный трафик контейнера, но ничего не знает о том, ЧТО внутри
|
||
# этого трафика. Разбор нагрузочного теста 28.07.2026 пришлось делать по
|
||
# логам именно потому, что job'а здесь не было (см. .forcc/LOAD-FINDINGS.md).
|
||
#
|
||
# Ключевое, что отсюда появляется:
|
||
# livekit_track_subscribed_total / livekit_track_published_total —
|
||
# подписки против публикаций, то есть прямой эффект adaptiveStream;
|
||
# livekit_participant_total, livekit_room_total — нагрузка в участниках;
|
||
# livekit_quality_score, livekit_packet_loss_percent, livekit_rtt_ms,
|
||
# livekit_jitter_us, livekit_nack_total, livekit_pli_total — качество
|
||
# связи у клиентов, а не догадки по событиям congestion в логах;
|
||
# livekit_webhook_queue_length, livekit_webhook_dispatch_total — очередь
|
||
# доставки вебхуков в backend (на тесте она росла до 56 секунд).
|
||
#
|
||
# Профиль `media` входит в дефолтный набор COMPOSE_PROFILES (см. .env.example),
|
||
# поэтому job включён, а не закомментирован, как `llm`. На инсталляции без
|
||
# профиля `media` таргет не резолвится — закомментируйте секцию.
|
||
- job_name: livekit
|
||
static_configs:
|
||
- targets: ["livekit:6789"]
|
||
|
||
# Локальный 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` (пресеты 3–5 install.sh).
|
||
# - job_name: llm
|
||
# static_configs:
|
||
# - targets: ["llm:8080"]
|