Files
vidconf/deploy/monitoring/prometheus.yml
Max Ronzhin 77ee26014d feat(monitoring): метрики CPU/RAM/диска хоста и контейнеров
Дашборд «Пайплайны пост-обработки» покрывал только прикладную логику —
нехватка памяти/CPU на сервере была видна только косвенно, по латентности API.

Добавлены node-exporter (метрики хоста) и cAdvisor (метрики по контейнерам,
профиль monitoring) — оба без публикации портов наружу, Prometheus ходит
к ним по внутренней сети compose. Новый дашборд host.json («Хост и
контейнеры») и три алерта (HostMemoryLow/HostDiskLow/HostCpuHigh) с
порогами под сервер 1gb (8 ГБ RAM, 4 CPU, 50 ГБ диска).
2026-07-28 00:21:01 +03:00

71 lines
4.1 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, сервис cadvisor). Отвечает на
# вопрос «какой из контейнеров ест ресурсы», в отличие от job `node`
# (только хост целиком).
- job_name: cadvisor
static_configs:
- targets: ["cadvisor:8080"]
# Локальный 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"]