feat(metrics): метрики доступности БД и занятости пулов БД/Redis

vidconf_db_up проверяется отдельным от основного пула соединением
(NullPool, короткий таймаут) — иначе в момент исчерпания пула проверка
сама встала бы в очередь и не отличила бы «БД лежит» от «пул занят».
vidconf_db_pool_* читаются синхронно из engine.pool, без единого запроса
к БД. metrics_endpoint больше не виснет и не падает при недоступном
основном пуле: критичные gauge'и считаются первыми и не зависят от него,
а vidconf_pipeline_sessions (по-прежнему через Depends(get_session) —
тестовый харнесс подменяет её на savepoint-сессию) обёрнут таймаутом
и try/except.
This commit is contained in:
2026-08-09 02:39:59 +03:00
parent c906c97cb8
commit 0e56960714
5 changed files with 238 additions and 5 deletions

View File

@@ -1,4 +1,4 @@
"""Метрики Prometheus: латентность HTTP + gauge'и пайплайна, очередей и железа.
"""Метрики Prometheus: латентность HTTP + gauge'и пайплайна, очередей, БД и железа.
`GET /metrics` — без авторизации (снаружи закрывается на уровне nginx, вне
периметра backend, см. `docs/deploy/scaling.md`/monitoring-часть devops):
@@ -12,8 +12,22 @@ Gauge'и `vidconf_pipeline_sessions`/`vidconf_celery_queue_depth`/
Redis) можно опросить обычным `await` вместо реализации синхронного
`prometheus_client.registry.Collector` (у `vidconf_host_info` источник
и вовсе синхронный — настройки уже в памяти процесса).
🔴 Метрики о состоянии основного пула БД (`vidconf_db_up`,
`vidconf_db_pool_*`) обязаны читаться БЕЗ обращения к самому пулу — иначе
в момент его исчерпания (см. `.forcc/session-results/32-loadtest-07-08-debug.md`)
эндпоинт метрик падал бы вместе со всем остальным ровно тогда, когда нужнее
всего. `vidconf_db_pool_*` — синхронный снимок `engine.pool` (см.
`core/db.py::db_pool_stats`), `vidconf_db_up` — отдельное соединение вне
основного пула (`core/db.py::check_db_up`). `_refresh_pipeline_sessions_gauge`
по-прежнему ходит через основной пул (`Depends(get_session)`, тестовый
харнесс подменяет её на savepoint-сессию — см. `tests/conftest.py`; развести
полностью, как `vidconf_db_up`, значило бы переделывать харнесс ради того же
эффекта — цена не оправдана, см. прецедент `f7c4fb4`/session 32), но обёрнута
таймаутом и try/except, чтобы её недоступность не роняла остальные метрики.
"""
import asyncio
import time
from collections.abc import Awaitable, Callable
@@ -23,7 +37,7 @@ from sqlalchemy.ext.asyncio import AsyncSession
from starlette.routing import Match
from core.config import get_settings
from core.db import get_session
from core.db import check_db_up, db_pool_checked_out, get_session
from core.redis import redis_client
from models.session import PIPELINE_STATUSES
from repositories.conferences import ConferenceSessionRepository
@@ -80,9 +94,30 @@ PIPELINE_SESSIONS = Gauge(
)
# Сколько ждать основной пул под этой конкретной метрикой, прежде чем
# сдаться и оставить прежнее значение gauge. Меньше `db_pool_timeout` (10с,
# `core/config.py`) — Prometheus скрейпит раз в 15с, и эта метрика не должна
# в одиночку съедать бюджет всего окна scrape.
_PIPELINE_GAUGE_TIMEOUT_S = 2.0
async def _refresh_pipeline_sessions_gauge(session: AsyncSession) -> None:
"""Пересчитать `vidconf_pipeline_sessions` по всем статусам `pipeline_status`."""
counts = await ConferenceSessionRepository(session).count_by_pipeline_status()
"""Пересчитать `vidconf_pipeline_sessions` по всем статусам `pipeline_status`.
Ходит через основной пул (`session` — из `Depends(get_session)`, см.
докстринг модуля про ограничения тестового харнесса). Если пул занят
или БД недоступна, запрос не должен держать весь `/metrics` — таймаут
короче `db_pool_timeout`, ошибка гасится, gauge остаётся на прежнем
значении (не обнуляется — обнулять его при недоступности БД так же
неверно, как считать сеансы пропавшими).
"""
try:
counts = await asyncio.wait_for(
ConferenceSessionRepository(session).count_by_pipeline_status(),
timeout=_PIPELINE_GAUGE_TIMEOUT_S,
)
except Exception: # noqa: BLE001
return
for status in PIPELINE_STATUSES:
PIPELINE_SESSIONS.labels(status=status).set(counts.get(status, 0))
@@ -113,6 +148,70 @@ async def _refresh_celery_queue_depth_gauge() -> None:
CELERY_QUEUE_DEPTH.labels(queue=queue).set(depth)
# --- Доступность БД и занятость основного пула (сессия 33) -----------------
#
# Ранний сигнал важнее самого факта отказа: в инциденте 07.08 пул заполнялся
# постепенно (`idle in transaction` 3→8→16→26→35→39→40 участников) —
# `vidconf_db_pool_checked_out` показал бы это задолго до первого 500.
# Обе метрики читаются без обращения к основному пулу (см. докстринг модуля
# и `core/db.py`), поэтому доступны и в момент, когда сам пул исчерпан.
DB_UP = Gauge(
"vidconf_db_up",
"Доступность БД (1/0) — проверяется отдельным соединением вне основного пула",
)
DB_POOL_SIZE = Gauge(
"vidconf_db_pool_size",
"Настроенный размер основного пула БД без overflow (db_pool_size)",
)
DB_POOL_MAX_OVERFLOW = Gauge(
"vidconf_db_pool_max_overflow",
"Настроенный максимум overflow-соединений сверх db_pool_size (db_max_overflow)",
)
DB_POOL_CHECKED_OUT = Gauge(
"vidconf_db_pool_checked_out",
"Число соединений основного пула БД, занятых прямо сейчас (в пуле + overflow)",
)
async def _refresh_db_up_gauge() -> None:
"""Пересчитать `vidconf_db_up` отдельным от основного пула соединением."""
DB_UP.set(1 if await check_db_up() else 0)
def _refresh_db_pool_gauges() -> None:
"""Пересчитать gauge'и занятости основного пула — синхронно, без I/O."""
settings = get_settings()
DB_POOL_SIZE.set(settings.db_pool_size)
DB_POOL_MAX_OVERFLOW.set(settings.db_max_overflow)
DB_POOL_CHECKED_OUT.set(db_pool_checked_out())
# --- Занятость пула Redis (сессия 33, второй потолок из session 32) --------
#
# Тот же класс отказа, что и у пула БД: каждое WS-подключение комнаты держит
# pub/sub-соединение всё время, пока участник в конференции (`core/redis.py`,
# `redis_max_connections`). Снимок — синхронный (атрибуты пула в памяти
# процесса redis-py), Redis для этого спрашивать не нужно.
REDIS_POOL_IN_USE = Gauge(
"vidconf_redis_pool_in_use",
"Число занятых соединений пула Redis прямо сейчас",
)
REDIS_POOL_MAX = Gauge(
"vidconf_redis_pool_max_connections",
"Настроенный максимум соединений пула Redis (redis_max_connections)",
)
def _refresh_redis_pool_gauges() -> None:
"""Пересчитать gauge'и занятости пула Redis — синхронно, без I/O."""
pool = redis_client.connection_pool
REDIS_POOL_IN_USE.set(len(pool._in_use_connections)) # noqa: SLF001
REDIS_POOL_MAX.set(pool.max_connections)
# --- Info-метрика обнаруженного железа (install.sh, ADR-004) ---------------
HOST_INFO = Gauge(
@@ -158,7 +257,16 @@ async def metrics_endpoint(session: AsyncSession = Depends(get_session)) -> Resp
ценой одного SELECT (группировка по `pipeline_status`) и `LLEN` на
каждую из 4 отслеживаемых очередей per запрос — Prometheus скрейпит
редко (обычно раз в 1530с), нагрузка пренебрежимо мала.
Порядок важен: метрики о состоянии основного пула БД (`_refresh_db_up_gauge`,
`_refresh_db_pool_gauges`) считаются первыми и не зависят от самого пула
(см. докстринг модуля) — они гарантированно попадут в ответ, даже если
следующий за ними `_refresh_pipeline_sessions_gauge` (основной пул) зависнет
или упадёт под нагрузкой.
"""
await _refresh_db_up_gauge()
_refresh_db_pool_gauges()
_refresh_redis_pool_gauges()
await _refresh_pipeline_sessions_gauge(session)
await _refresh_celery_queue_depth_gauge()
_refresh_host_info_gauge()