Files
vidconf/docs/deploy/monitoring.md
Max Ronzhin 456cc58b25
Some checks failed
CI / backend (push) Has been cancelled
CI / frontend (push) Has been cancelled
docs(monitoring): описать node-exporter/cAdvisor и алерты по железу
Документация мониторинга описывала только старые компоненты (prometheus,
postgres/redis-exporter, дашборд пайплайнов) — актуализирована под
node-exporter/cAdvisor, дашборд host.json и три новых алерта.
2026-07-28 00:22:08 +03:00

131 lines
9.0 KiB
Markdown
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 + Grafana, профиль compose `monitoring`)
Независимый compose-профиль — можно поднимать вместе
с любым пресетом инсталлятора (15) или отдельно.
## 1. Компоненты
| Сервис | Образ | Порт (хост) | Назначение |
|---|---|---|---|
| `prometheus` | `prom/prometheus:v3.13.1` | `9090` | сбор и хранение метрик, оценка правил алертинга |
| `postgres-exporter` | `quay.io/prometheuscommunity/postgres-exporter:v0.20.1` | — (внутренний) | метрики PostgreSQL |
| `redis-exporter` | `oliver006/redis_exporter:v1.87.0-alpine` | — (внутренний) | метрики Redis |
| `node-exporter` | `prom/node-exporter:v1.8.2` | — (внутренний) | метрики хоста: CPU, память, диск, сеть, load average |
| `cadvisor` | `gcr.io/cadvisor/cadvisor:v0.49.2` | — (внутренний) | метрики по каждому контейнеру (CPU/память) |
| `grafana` | `grafana/grafana:13.1.0` | `3001` (внутри контейнера `3000`) | дашборды «Пайплайны пост-обработки» и «Хост и контейнеры» |
`node-exporter`/`cadvisor` не публикуют порт на хост вообще (не только
127.0.0.1) — Prometheus ходит к ним по имени сервиса во внутренней сети
compose, публикация на хост для этого не нужна. `cadvisor` смонтирован
к `/var/run/docker.sock` только на чтение (`:ro`) и запущен с
`--docker_only` + урезанным набором коллекторов (`--disable_metrics`) —
он заметно дороже `node-exporter` по CPU/RAM, урезание снижает накладные
расходы. Если на конкретном сервере это всё равно избыточно —
`cadvisor` можно убрать из `deploy/docker-compose.yml`, оставив только
`node-exporter` (метрики хоста при этом не пострадают, пропадёт только
разбивка по контейнерам).
Файлы: `deploy/monitoring/prometheus.yml`, `deploy/monitoring/alerts.yml`,
`deploy/monitoring/grafana/provisioning/` (datasource + провайдер
дашбордов), `deploy/monitoring/grafana/dashboards/pipelines.json`,
`deploy/monitoring/grafana/dashboards/host.json`.
## 2. Запуск
```bash
docker compose -f deploy/docker-compose.yml --env-file .env --profile monitoring up -d
```
- Prometheus: http://localhost:9090
- Grafana: http://localhost:3001 (логин/пароль — `.env`,
`GRAFANA_ADMIN_USER`/`GRAFANA_ADMIN_PASSWORD`; `install.sh` генерирует
пароль при первой установке)
⚠️ На боевом сервере оба порта публикуются ТОЛЬКО на `127.0.0.1`
(`deploy/docker-compose.yml`) — открытые наружу admin-панели без
дополнительной аутентификации ранее уже приводили к компрометации сервисов
на этом проекте (см. `.forcc/deploy/SESSION2-FINDINGS.md`). С другой машины
используйте ssh-туннель:
```bash
ssh -L 9090:127.0.0.1:9090 -L 3001:127.0.0.1:3001 <user>@<host>
```
и открывайте `http://localhost:9090` / `http://localhost:3001` у себя.
Дашборды «Пайплайны пост-обработки» и «Хост и контейнеры» (папка VidConf
в Grafana) появляются сразу — источник данных и дашборды провижинятся из
файлов, без ручной настройки.
## 3. Метрики backend
`GET /metrics` (`backend/api/metrics.py`, без авторизации внутри
приложения — снаружи периметра закрыт явным `return 403` в
`deploy/nginx/nginx.conf`; Prometheus ходит в backend напрямую по docker-сети,
`backend:8000/metrics`, минуя nginx):
- `vidconf_http_request_duration_seconds` (histogram, `method`/`path`/`status`) —
латентность HTTP по шаблону маршрута.
- `vidconf_pipeline_sessions` (gauge, `status`) — число сеансов конференций в
каждом статусе `pipeline_status`
(recording→transcribing→summarizing→notified|failed).
- `vidconf_celery_queue_depth` (gauge, `queue`) — глубина очередей Celery
(`transcription`/`summarize`/`notify`/`celery`, redis `LLEN`), карта
очередей — `docs/deploy/scaling.md`.
Job `llm` в `prometheus.yml` скрейпит `llm:8080/metrics`
(`LLAMA_ARG_ENDPOINT_METRICS=1`) — этот адрес резолвится ЛИБО сервисом
`llm` (CPU, профиль `llm`), ЛИБО `llm-gpu` (у него есть сетевой алиас `llm`,
см. `deploy/docker-compose.yml`) — профили `llm`/`llm-gpu` взаимоисключающи
по пресету, поэтому один job без дублирования.
**По умолчанию job `llm` закомментирован** в `prometheus.yml` (вместе с
алертом `LlmDown` в `alerts.yml`) — целевой набор профилей compose
(`media,monitoring`, см. `.env.example`) не включает `llm`/`llm-gpu`, и
таргет `llm:8080` не резолвится вовсе. Раскомментируйте job и алерт вместе,
если инсталляция запущена с профилем `llm`/`llm-gpu` (пресеты 35
`install.sh`) — иначе панель «LLM-сервер доступен» дашборда «Пайплайны
пост-обработки» будет показывать «No data».
## 4. Алерты (`deploy/monitoring/alerts.yml`)
| Алерт | Условие | severity |
|---|---|---|
| `PipelineFailed` | рост числа сеансов в статусе `failed` за 15 минут | critical |
| `QueueGrowing` | глубина очереди растёт 15 минут подряд и превышает 10 задач | warning |
| `LlmDown` | `up{job="llm"} == 0` дольше 2 минут | critical (закомментирован по умолчанию) |
| `HostMemoryLow` | свободно <10% RAM (≈800 МБ из 8 ГБ) дольше 10 минут | warning |
| `HostDiskLow` | свободно <10% диска (≈5 ГБ из 50 ГБ) дольше 15 минут | warning |
| `HostCpuHigh` | загрузка CPU >90% дольше 15 минут подряд | warning |
Пороги трёх алертов по железу подобраны под конкретный сервер `1gb`
(8 ГБ RAM, 4 CPU, 50 ГБ диска) — при смене сервера пересчитать
(`deploy/monitoring/alerts.yml`, группа `vidconf-host`).
`LlmDown` актуален только на инсталляциях с профилем `llm`/`llm-gpu`
(пресеты 35) — по умолчанию (профили `media,monitoring`, без AI) правило
закомментировано в `alerts.yml` вместе с job `llm` в `prometheus.yml`.
Раскомментируйте оба, если поднимаете профиль `llm`/`llm-gpu`.
Проверка (после раскомментирования job/алерта, на инсталляции с профилем
`llm`/`llm-gpu`) — искусственно завалить пайплайн и убедиться, что алерт
срабатывает:
```bash
# Стек с профилями media, transcribe, llm, monitoring уже поднят,
# идёт активная суммаризация (сеанс в статусе summarizing).
docker compose -f deploy/docker-compose.yml --env-file .env stop llm
# Подождать > 2 минут → Prometheus (http://localhost:9090/alerts)
# должен показать LlmDown в состоянии firing, следом — QueueGrowing
# (очередь summarize перестаёт разбираться) и, если сеанс не восстановится
# за 15 минут (recover_stuck_summaries переставит задачу, workers/celery_app.py),
# PipelineFailed.
docker compose -f deploy/docker-compose.yml --env-file .env start llm
```
## 5. Хранение
`prometheus_data`/`grafana_data` — именованные тома, переживают
пересоздание контейнеров. Ретеншен Prometheus — дефолт образа (15 дней);
для прод-инсталляций с длинным горизонтом донастраивается флагом
`--storage.tsdb.retention.time` (не задан в `deploy/docker-compose.yml`
осознанный dev/small-prod дефолт, донастраивается отдельно при необходимости).