Max Ronzhin
7f5c88869a
На сервере 1gb Docker Engine использует containerd-снапшоттер (driver-type: io.containerd.snapshotter.v1), а не классический overlay2. cAdvisor (проверено на v0.49.2 и свежей v0.52.1, с --docker_only и через --containerd/--containerd-namespace=moby) не может определить read-write layer контейнеров — падает с «failed to identify the read-write layer ID», метрики только по корневому cgroup, без разбивки по контейнерам. Открытая проблема совместимости, флагами не решается. Убран сервис cadvisor, job в prometheus.yml, панели «топ контейнеров» в host.json (Prometheus иначе резолвит cadvisor:8080 в никуда — Grafana показывала бы «No data» вечно). node-exporter метрики хоста (CPU/RAM/ диск/сеть) при этом покрывает полностью, без изменений. Правка конфигурации мониторинга, без изменения пользовательского поведения — версия не бампается.
63 lines
3.6 KiB
YAML
63 lines
3.6 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).
|
||
- job_name: node
|
||
static_configs:
|
||
- targets: ["node-exporter:9100"]
|
||
|
||
# Локальный 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"]
|