release: версия 0.0.32

feat(monitoring): алерты на недоступность БД и исчерпание пулов + дашборд
DatabaseUnavailable (vidconf_db_up == 0, for: 30s, critical) и DbConnectionPoolNearExhaustion/RedisConnectionPoolNearExhaustion (занято > 80% дольше минуты, warning) — сигнал оператору, не автолечение: healthcheck backend'а по решению оператора остаётся мягким, рестарт при недоступной БД оборвал бы WS у всех, кто в конференциях. Дашборд Grafana «БД и пулы соединений» — занятость пулов на графике, следующий нагрузочный тест будут смотреть глазами.
2026-08-09 02:40:10 +03:00 · 2026-08-09 02:40:06 +03:00 · 2026-08-09 02:39:59 +03:00
11 changed files with 543 additions and 8 deletions
--- a/.env.example
+++ b/.env.example
@@ -128,7 +128,7 @@ SMTP_TIMEOUT_S=30
 # --- Версия инстанса (релиз v0.0.1) ---
 # install.sh копирует значение из корневого файла VERSION при каждой
 # установке/обновлении — руками менять не нужно.
-VIDCONF_VERSION=0.0.31
+VIDCONF_VERSION=0.0.32

 # --- Профили compose. Дефолт ниже (`media,monitoring`) — только для ручного
 # `docker compose up` БЕЗ install.sh: медиа (LiveKit+coturn) + мониторинг,
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -3,6 +3,52 @@
 Формат основан на [Keep a Changelog](https://keepachangelog.com/ru/1.1.0/),
 проект придерживается [семантического версионирования](https://semver.org/lang/ru/).

+## [0.0.32] — 2026-08-09
+
+Метрики состояния БД и пулов соединений + алерты в Prometheus — по решению
+оператора на отказ БД реагируем сигналом, а не автолечением (перезапуск
+контейнера при недоступной БД оборвал бы WS у всех, кто в конференциях).
+См. разбор инцидента 07.08.2026 (0.0.31): `/api/health` во время отказа
+отдавал 200 с `db: false`, а Prometheus скрейпит `/metrics`, где метрик
+состояния БД не было вообще — строить алерт было не на чем.
+
+### Добавлено
+- **`vidconf_db_up`** — доступность БД (1/0), проверяется отдельным от
+  основного пула соединением с коротким таймаутом. Позволяет отличить
+  «БД лежит» от «основной пул занят под нагрузкой» — это два разных
+  состояния, и до этого релиза их нечем было различить.
+- **`vidconf_db_pool_size`/`_max_overflow`/`_checked_out`** — конфигурация
+  и занятость основного пула SQLAlchemy. Читаются синхронно из объекта
+  пула (`engine.pool`), без единого запроса к БД — это единственный
+  способ получить сигнал именно в момент, когда пул исчерпан.
+- **`vidconf_redis_pool_in_use`/`_max_connections`** — занятость пула
+  Redis (второй потолок того же рода, закрыт в 0.0.31).
+- Алерты `deploy/monitoring/alerts.yml` (группа `vidconf-db`):
+  `DatabaseUnavailable` (`vidconf_db_up == 0`, `for: 30s`, critical) и
+  `DbConnectionPoolNearExhaustion`/`RedisConnectionPoolNearExhaustion`
+  (занято > 80% дольше минуты, warning) — ранний сигнал: в инциденте
+  07.08 пул заполнялся постепенно по мере входа участников в комнату,
+  а не рывком от HTTP-нагрузки.
+- Дашборд Grafana **«БД и пулы соединений»**
+  (`deploy/monitoring/grafana/dashboards/db-pool.json`).
+
+### Технические детали
+- `GET /metrics` больше не падает и не виснет при недоступности основного
+  пула БД: gauge'и о состоянии пула читаются первыми и не зависят от него
+  (отдельное NullPool-соединение для `db_up`, синхронный снимок для
+  занятости пула), а зависящий от основного пула `vidconf_pipeline_sessions`
+  обёрнут таймаутом (2с) — при недоступности оставляет прежнее значение,
+  не роняя остальные метрики. Полностью развести его с основным пулом не
+  стали: тестовый харнесс подменяет `get_session` на savepoint-сессию
+  (`tests/conftest.py`), отдельное соединение не увидело бы несознанные
+  тестом данные — тот же компромисс, что и в 0.0.31 для `api/chat.py`.
+- Проверено вживую на локальном стенде (не только по синтаксису конфига):
+  остановка Postgres → `vidconf_db_up` = 0, `/metrics` продолжает отвечать,
+  алерт `DatabaseUnavailable` переходит в `firing`; временно урезанный
+  пул под нагрузкой → `DbConnectionPoolNearExhaustion` переходит в
+  `firing` ровно через заявленный `for: 1m`; снятие нагрузки/восстановление
+  БД — алерты гаснут.
+
 ## [0.0.31] — 2026-08-09

 Разбор провала входа на нагрузочном тесте 07.08.2026: комната держала
--- a/2
+++ b/2
@@ -1 +1 @@
-0.0.31
+0.0.32
--- a/backend/api/metrics.py
+++ b/backend/api/metrics.py
@@ -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 скрейпит
    редко (обычно раз в 15–30с), нагрузка пренебрежимо мала.
+
+    Порядок важен: метрики о состоянии основного пула БД (`_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()
--- a/backend/core/config.py
+++ b/backend/core/config.py
@@ -38,6 +38,13 @@ class Settings(BaseSettings):
    # и показывает проблему, а не висит полминуты, делая вид, что всё живо.
    db_pool_timeout: int = 10

+    # --- Проверка доступности БД вне основного пула (`core/db.py::check_db_up`) ---
+    # Таймаут TCP/auth отдельного соединения-пробы (не путать с
+    # `db_pool_timeout` выше — тот про очередь на основной пул). Дефолт
+    # asyncpg — 60с, для сигнала мониторинга это неприемлемо долго: пусть
+    # `vidconf_db_up` станет 0 за секунды, а не через минуту.
+    db_probe_timeout_s: float = 3.0
+
    # --- Пул соединений с Redis ---
    # Считается по УЧАСТНИКАМ, а не по запросам: каждое WS-подключение комнаты
    # (`api/chat.py`) держит собственное pub/sub-соединение всё время, пока
--- a/backend/core/db.py
+++ b/backend/core/db.py
@@ -1,13 +1,16 @@
 """Настройка асинхронного движка SQLAlchemy и сеанса."""

 from collections.abc import AsyncGenerator
+from typing import cast

+from sqlalchemy import text
 from sqlalchemy.ext.asyncio import (
    AsyncEngine,
    AsyncSession,
    async_sessionmaker,
    create_async_engine,
 )
+from sqlalchemy.pool import NullPool, QueuePool

 from core.config import get_settings

@@ -31,3 +34,45 @@ async def get_session() -> AsyncGenerator[AsyncSession, None]:
    """Зависимость FastAPI, возвращающая `AsyncSession`."""
    async with async_session_maker() as session:
        yield session
+
+
+# --- Проверка доступности БД вне основного пула (сессия 33) ----------------
+#
+# Отдельный движок с `NullPool`: каждый вызов открывает новое соединение и
+# закрывает его сразу после — бюджет соединений не пересекается с
+# `engine.pool` (10 + 10 overflow × число воркеров uvicorn). Это единственный
+# способ отличить «БД лежит» от «основной пул занят под нагрузкой»: проверка
+# через `get_session()` в момент исчерпания пула сама встала бы в очередь на
+# `db_pool_timeout` и не смогла бы ответить, пока не появится случайно
+# освободившееся место — то есть не отличила бы два принципиально разных
+# состояния. Короткий `timeout` на соединение (не путать с `db_pool_timeout`
+# основного пула) — чтобы зависший, а не оборванный TCP (Postgres отвечает,
+# но не может продвинуться) не держал проверку до дефолтных 60 секунд asyncpg.
+_probe_engine: AsyncEngine = create_async_engine(
+    settings.database_url,
+    poolclass=NullPool,
+    connect_args={"timeout": settings.db_probe_timeout_s},
+)
+
+
+async def check_db_up() -> bool:
+    """`True`, если БД отвечает на `SELECT 1` по отдельному от основного пула соединению."""
+    try:
+        async with _probe_engine.connect() as connection:
+            await connection.execute(text("SELECT 1"))
+    except Exception:  # noqa: BLE001
+        return False
+    return True
+
+
+def db_pool_checked_out() -> int:
+    """Число соединений основного пула, занятых прямо сейчас — без обращения к БД.
+
+    SQLAlchemy держит счётчик в памяти самого объекта пула (`engine.pool`),
+    поэтому его можно прочитать в любой момент, даже когда все соединения
+    заняты или БД недоступна — именно это нужно алерту на исчерпание пула
+    (метрика не должна зависеть от того, что измеряет). Размер и лимит
+    overflow — конфигурация (`Settings.db_pool_size`/`db_max_overflow`),
+    их не нужно снимать с объекта пула отдельно.
+    """
+    return cast(QueuePool, engine.pool).checkedout()
--- a/backend/tests/test_metrics_api.py
+++ b/backend/tests/test_metrics_api.py
@@ -59,6 +59,12 @@ async def test_metrics_endpoint_returns_prometheus_exposition_format(
    assert "vidconf_pipeline_sessions" in families
    assert "vidconf_celery_queue_depth" in families
    assert "vidconf_host_info" in families
+    assert "vidconf_db_up" in families
+    assert "vidconf_db_pool_size" in families
+    assert "vidconf_db_pool_max_overflow" in families
+    assert "vidconf_db_pool_checked_out" in families
+    assert "vidconf_redis_pool_in_use" in families
+    assert "vidconf_redis_pool_max_connections" in families


 async def test_metrics_host_info_gauge_reflects_settings(
@@ -129,6 +135,72 @@ async def test_metrics_pipeline_sessions_gauge_reflects_new_session(
    assert after == before + 1


+async def test_metrics_db_up_gauge_reflects_real_connectivity(client: httpx.AsyncClient) -> None:
+    """Против реального тестового Postgres (см. докстринг conftest) `vidconf_db_up` == 1."""
+    response = await client.get("/metrics")
+    value = _sample_value(_samples(response.text, "vidconf_db_up"), suffix="vidconf_db_up")
+    assert value == 1
+
+
+async def test_metrics_db_up_gauge_reports_down_without_crashing_endpoint(
+    client: httpx.AsyncClient, monkeypatch: pytest.MonkeyPatch
+) -> None:
+    """Недоступность БД (проверка вне пула не удалась) не роняет `/metrics` — отдаёт 0, не 500."""
+
+    async def _fail() -> bool:
+        return False
+
+    monkeypatch.setattr(metrics_module, "check_db_up", _fail)
+
+    response = await client.get("/metrics")
+
+    assert response.status_code == 200
+    value = _sample_value(_samples(response.text, "vidconf_db_up"), suffix="vidconf_db_up")
+    assert value == 0
+
+
+async def test_metrics_db_pool_gauges_reflect_settings_not_usage(
+    client: httpx.AsyncClient,
+) -> None:
+    """`vidconf_db_pool_size`/`_max_overflow` — конфигурация из `Settings`, не текущая занятость."""
+    settings = get_settings()
+    response = await client.get("/metrics")
+
+    samples_size = _samples(response.text, "vidconf_db_pool_size")
+    samples_overflow = _samples(response.text, "vidconf_db_pool_max_overflow")
+    size = _sample_value(samples_size, suffix="vidconf_db_pool_size")
+    max_overflow = _sample_value(samples_overflow, suffix="vidconf_db_pool_max_overflow")
+
+    assert size == settings.db_pool_size
+    assert max_overflow == settings.db_max_overflow
+
+
+async def test_metrics_endpoint_survives_pipeline_gauge_failure(
+    client: httpx.AsyncClient, monkeypatch: pytest.MonkeyPatch
+) -> None:
+    """Падение/таймаут основного пула на одном gauge не роняет весь `/metrics`.
+
+    Симулирует ровно ситуацию инцидента 07.08 (`api/metrics.py` падал вместе
+    со всем остальным при исчерпанном пуле): `count_by_pipeline_status`
+    поднимает исключение — `vidconf_db_up`/`vidconf_db_pool_*` (не зависящие
+    от основного пула) при этом всё равно приходят в ответе.
+    """
+
+    async def _raise(*args: object, **kwargs: object) -> dict[str, int]:
+        raise TimeoutError("основной пул занят (симуляция теста)")
+
+    monkeypatch.setattr(
+        "repositories.conferences.ConferenceSessionRepository.count_by_pipeline_status",
+        _raise,
+    )
+
+    response = await client.get("/metrics")
+
+    assert response.status_code == 200
+    db_up = _sample_value(_samples(response.text, "vidconf_db_up"), suffix="vidconf_db_up")
+    assert db_up == 1
+
+
 async def test_metrics_celery_queue_depth_gauge(
    client: httpx.AsyncClient, monkeypatch: pytest.MonkeyPatch
 ) -> None:
--- a/deploy/docker-compose.yml
+++ b/deploy/docker-compose.yml
@@ -89,7 +89,7 @@ services:
      MEDIA_ROOT: ${MEDIA_ROOT:-/app/media}
      # Версия инстанса (релиз v0.0.1) — install.sh копирует значение
      # из файла VERSION (корень репозитория) в .env; отдаётся в GET /api/health.
-      VIDCONF_VERSION: ${VIDCONF_VERSION:-0.0.31}
+      VIDCONF_VERSION: ${VIDCONF_VERSION:-0.0.32}
      # Число процессов uvicorn (см. backend/Dockerfile). Дефолт 2 рассчитан
      # на 4-ядерный сервер, где ядра делятся с LiveKit. Поднимая значение,
      # проверьте бюджет соединений с БД: каждый воркер держит свой пул
--- a/deploy/monitoring/alerts.yml
+++ b/deploy/monitoring/alerts.yml
@@ -61,6 +61,89 @@ groups:
      #       см. также алерт QueueGrowing). Проверить
      #       `docker compose ps llm` / `llm-gpu` и `docker compose logs llm`.

+  # Состояние БД и пулов соединений (сессия 33, разбор инцидента 07.08 —
+  # `.forcc/session-results/32-loadtest-07-08-debug.md`). `/api/health`
+  # отдавал 200 с `db: false` во время отказа — Prometheus его не скрейпит и
+  # не умеет разобрать JSON-тело, поэтому оба сигнала строятся на метриках
+  # `backend/api/metrics.py`, которые читаются вне основного пула.
+  - name: vidconf-db
+    rules:
+      # `vidconf_db_up` — отдельное соединение вне основного пула
+      # (`core/db.py::check_db_up`), поэтому 0 означает именно «БД не
+      # отвечает», а не «пул занят» (для второго см. DbConnectionPoolNearExhaustion
+      # ниже — раздельные метрики нарочно, см. «Главное требование» промпта
+      # сессии 33). `for: 30s` — два цикла скрейпа (`scrape_interval: 15s`),
+      # чтобы не среагировать на одиночный неудачный `connect()` (сеть/GC-пауза),
+      # но не тянуть с сигналом дольше: это самый критичный алерт в проекте.
+      - alert: DatabaseUnavailable
+        expr: vidconf_db_up == 0
+        for: 30s
+        labels:
+          severity: critical
+        annotations:
+          summary: "БД недоступна"
+          description: >-
+            vidconf_db_up == 0 дольше 30 секунд — backend не может открыть
+            отдельное (вне основного пула) соединение с Postgres. НЕ значит
+            автоматически «нужен рестарт контейнера» — по решению оператора
+            от 09.08 healthcheck backend'а остаётся мягким (не хардфейлится
+            на недоступной БД — рестарт-петля в разгар инцидента оборвала бы
+            WS у всех, кто в конференциях), это сигнал оператору, не
+            автолечение. Смотреть
+            `docker compose ps postgres`, `docker compose logs postgres`,
+            `pg_isready`.
+
+      # Раннее предупреждение — тот самый сигнал, которого не хватило
+      # 07.08: пул заполнялся постепенно (idle in transaction 3→8→16→26→35→
+      # 39→40 участников комнаты, см. session 32), а `up{job="backend"}`
+      # ничего не показывал, потому что backend отвечал исправно вплоть до
+      # самого потолка. Порог 80% — предложение из промпта сессии 33,
+      # `for: 1m` — фильтр от секундных всплесков (короткий пик параллельных
+      # запросов рассасывается за секунды, устойчивый рост участников
+      # комнаты — нет). На нагрузочном тесте 07.08 от пересечения 80% до
+      # исчерпания пула прошло по грубой оценке меньше двух минут — порог
+      # НЕ даёт большого запаса и это осознанный компромисс, а не идеал:
+      # цель — успеть до 500-х у пользователей, а не за много минут
+      # заранее. Перепроверить оба числа на следующем нагрузочном тесте
+      # (см. .forcc/session-results/33-db-health-alert.md) и подстроить,
+      # если реальный запас окажется у́же ожидаемого.
+      - alert: DbConnectionPoolNearExhaustion
+        expr: >-
+          (vidconf_db_pool_checked_out
+            / (vidconf_db_pool_size + vidconf_db_pool_max_overflow)) * 100 > 80
+        for: 1m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Основной пул соединений с БД близок к исчерпанию"
+          description: >-
+            Занято {{ $value | printf "%.0f" }}% основного пула БД дольше
+            минуты (порог 80%). Частая причина в этом проекте — долгоживущие
+            WS-подключения комнат (`api/chat.py`) держат соединение на
+            каждого сидящего в конференции; смотреть
+            `vidconf_db_pool_checked_out` и число открытых WS чата в логах,
+            не только текущую HTTP-нагрузку.
+
+      # Тот же класс отказа, что у пула БД (см. выше), только пул Redis —
+      # закрыт в 0.0.31 (`451c18e`) заданием явного max_connections, но без
+      # метрики занятости прошлый потолок нашёлся только руками на
+      # нагрузочном тесте. Бонус к задаче сессии 33 («потолки в этом
+      # проекте стоят лесенкой»), не отдельно запрошен промптом — пороги
+      # взяты по аналогии с пулом БД, не проверялись отдельным нагрузочным
+      # тестом именно на Redis.
+      - alert: RedisConnectionPoolNearExhaustion
+        expr: (vidconf_redis_pool_in_use / vidconf_redis_pool_max_connections) * 100 > 80
+        for: 1m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Пул соединений Redis близок к исчерпанию"
+          description: >-
+            Занято {{ $value | printf "%.0f" }}% пула Redis дольше минуты
+            (порог 80%). Каждое WS-подключение комнаты держит собственную
+            pub/sub-подписку из этого же пула — смотреть число открытых WS
+            чата, не только команды Celery/кэша.
+
  # Железо хоста (job `node` — node-exporter). Пороги подобраны под
  # конкретный сервер 1gb: 8 ГБ RAM, 4 CPU, 50 ГБ диска — если сервер
  # сменится, пересчитать.
--- a/deploy/monitoring/grafana/dashboards/db-pool.json
+++ b/deploy/monitoring/grafana/dashboards/db-pool.json
@@ -0,0 +1,173 @@
+{
+  "title": "БД и пулы соединений",
+  "description": "Доступность БД (vidconf_db_up) и занятость основных пулов (SQLAlchemy/БД, Redis) — метрики читаются вне самих пулов, доступны и при их исчерпании (сессия 33, разбор инцидента 07.08 — .forcc/session-results/32-loadtest-07-08-debug.md). Пороги алертов см. deploy/monitoring/alerts.yml (группа vidconf-db).",
+  "uid": "vidconf-db-pool",
+  "editable": false,
+  "timezone": "browser",
+  "schemaVersion": 39,
+  "version": 1,
+  "time": { "from": "now-1h", "to": "now" },
+  "refresh": "10s",
+  "tags": ["vidconf", "db", "pool"],
+  "panels": [
+    {
+      "id": 1,
+      "title": "БД доступна",
+      "description": "vidconf_db_up — отдельное соединение вне основного пула (core/db.py::check_db_up). Алерт DatabaseUnavailable, for: 30s.",
+      "type": "stat",
+      "gridPos": { "h": 4, "w": 6, "x": 0, "y": 0 },
+      "datasource": { "type": "prometheus", "uid": "prometheus" },
+      "fieldConfig": {
+        "defaults": {
+          "mappings": [
+            { "type": "value", "options": { "0": { "text": "DOWN", "color": "red" }, "1": { "text": "UP", "color": "green" } } }
+          ],
+          "thresholds": { "mode": "absolute", "steps": [{ "color": "red", "value": null }, { "color": "green", "value": 1 }] }
+        },
+        "overrides": []
+      },
+      "targets": [
+        { "datasource": { "type": "prometheus", "uid": "prometheus" }, "expr": "vidconf_db_up", "refId": "A" }
+      ]
+    },
+    {
+      "id": 2,
+      "title": "Занятость пула БД сейчас, %",
+      "description": "vidconf_db_pool_checked_out / (vidconf_db_pool_size + vidconf_db_pool_max_overflow) * 100. Порог алерта DbConnectionPoolNearExhaustion — 80% дольше минуты.",
+      "type": "stat",
+      "gridPos": { "h": 4, "w": 6, "x": 6, "y": 0 },
+      "datasource": { "type": "prometheus", "uid": "prometheus" },
+      "fieldConfig": {
+        "defaults": {
+          "unit": "percent",
+          "min": 0,
+          "max": 100,
+          "thresholds": { "mode": "absolute", "steps": [{ "color": "green", "value": null }, { "color": "orange", "value": 60 }, { "color": "red", "value": 80 }] }
+        },
+        "overrides": []
+      },
+      "targets": [
+        {
+          "datasource": { "type": "prometheus", "uid": "prometheus" },
+          "expr": "(vidconf_db_pool_checked_out / (vidconf_db_pool_size + vidconf_db_pool_max_overflow)) * 100",
+          "refId": "A"
+        }
+      ]
+    },
+    {
+      "id": 3,
+      "title": "Занятость пула Redis сейчас, %",
+      "description": "vidconf_redis_pool_in_use / vidconf_redis_pool_max_connections * 100. Порог алерта RedisConnectionPoolNearExhaustion — 80% дольше минуты.",
+      "type": "stat",
+      "gridPos": { "h": 4, "w": 6, "x": 12, "y": 0 },
+      "datasource": { "type": "prometheus", "uid": "prometheus" },
+      "fieldConfig": {
+        "defaults": {
+          "unit": "percent",
+          "min": 0,
+          "max": 100,
+          "thresholds": { "mode": "absolute", "steps": [{ "color": "green", "value": null }, { "color": "orange", "value": 60 }, { "color": "red", "value": 80 }] }
+        },
+        "overrides": []
+      },
+      "targets": [
+        {
+          "datasource": { "type": "prometheus", "uid": "prometheus" },
+          "expr": "(vidconf_redis_pool_in_use / vidconf_redis_pool_max_connections) * 100",
+          "refId": "A"
+        }
+      ]
+    },
+    {
+      "id": 4,
+      "title": "Активных алертов группы vidconf-db",
+      "description": "ALERTS{alertname=~\"DatabaseUnavailable|.*PoolNearExhaustion\", alertstate=\"firing\"} — снимок того, что прямо сейчас видит Alertmanager/страница Alerts.",
+      "type": "stat",
+      "gridPos": { "h": 4, "w": 6, "x": 18, "y": 0 },
+      "datasource": { "type": "prometheus", "uid": "prometheus" },
+      "fieldConfig": {
+        "defaults": {
+          "thresholds": { "mode": "absolute", "steps": [{ "color": "green", "value": null }, { "color": "red", "value": 1 }] }
+        },
+        "overrides": []
+      },
+      "targets": [
+        {
+          "datasource": { "type": "prometheus", "uid": "prometheus" },
+          "expr": "count(ALERTS{alertname=~\"DatabaseUnavailable|.*PoolNearExhaustion\", alertstate=\"firing\"}) OR on() vector(0)",
+          "refId": "A"
+        }
+      ]
+    },
+    {
+      "id": 5,
+      "title": "Занятость пула БД (соединений)",
+      "description": "vidconf_db_pool_checked_out на фоне вместимости (size + max_overflow) — эта картина должна расти под нагрузочным тестом до срабатывания алерта. Ранний сигнал: в инциденте 07.08 занятость росла постепенно по мере входа участников в комнату, а не рывком от общей HTTP-нагрузки.",
+      "type": "timeseries",
+      "gridPos": { "h": 8, "w": 12, "x": 0, "y": 4 },
+      "datasource": { "type": "prometheus", "uid": "prometheus" },
+      "fieldConfig": {
+        "defaults": { "custom": { "drawStyle": "line", "fillOpacity": 10 } },
+        "overrides": []
+      },
+      "targets": [
+        { "datasource": { "type": "prometheus", "uid": "prometheus" }, "expr": "vidconf_db_pool_checked_out", "legendFormat": "занято", "refId": "A" },
+        { "datasource": { "type": "prometheus", "uid": "prometheus" }, "expr": "vidconf_db_pool_size + vidconf_db_pool_max_overflow", "legendFormat": "вместимость (size+overflow)", "refId": "B" }
+      ]
+    },
+    {
+      "id": 6,
+      "title": "Занятость пула Redis (соединений)",
+      "description": "vidconf_redis_pool_in_use на фоне vidconf_redis_pool_max_connections. Второй потолок того же класса, что у БД (закрыт в 0.0.31, redis-py 8 сменил дефолт max_connections на 100).",
+      "type": "timeseries",
+      "gridPos": { "h": 8, "w": 12, "x": 12, "y": 4 },
+      "datasource": { "type": "prometheus", "uid": "prometheus" },
+      "fieldConfig": {
+        "defaults": { "custom": { "drawStyle": "line", "fillOpacity": 10 } },
+        "overrides": []
+      },
+      "targets": [
+        { "datasource": { "type": "prometheus", "uid": "prometheus" }, "expr": "vidconf_redis_pool_in_use", "legendFormat": "занято", "refId": "A" },
+        { "datasource": { "type": "prometheus", "uid": "prometheus" }, "expr": "vidconf_redis_pool_max_connections", "legendFormat": "вместимость", "refId": "B" }
+      ]
+    },
+    {
+      "id": 7,
+      "title": "БД доступна во времени",
+      "description": "vidconf_db_up как временной ряд — удобно видеть провал целиком (начало/длительность отказа), не только текущее состояние.",
+      "type": "timeseries",
+      "gridPos": { "h": 6, "w": 12, "x": 0, "y": 12 },
+      "datasource": { "type": "prometheus", "uid": "prometheus" },
+      "fieldConfig": {
+        "defaults": {
+          "min": 0,
+          "max": 1,
+          "custom": { "drawStyle": "line", "fillOpacity": 20, "lineInterpolation": "stepAfter" },
+          "mappings": [
+            { "type": "value", "options": { "0": { "text": "DOWN" }, "1": { "text": "UP" } } }
+          ]
+        },
+        "overrides": []
+      },
+      "targets": [
+        { "datasource": { "type": "prometheus", "uid": "prometheus" }, "expr": "vidconf_db_up", "legendFormat": "db_up", "refId": "A" }
+      ]
+    },
+    {
+      "id": 8,
+      "title": "Сеансы failed / очереди Celery (для сверки с общей нагрузкой)",
+      "description": "Тот же контекст, что на дашборде «Пайплайны пост-обработки» — здесь рядом с пулами, чтобы не переключаться между дашбордами при разборе инцидента.",
+      "type": "timeseries",
+      "gridPos": { "h": 6, "w": 12, "x": 12, "y": 12 },
+      "datasource": { "type": "prometheus", "uid": "prometheus" },
+      "fieldConfig": {
+        "defaults": { "custom": { "drawStyle": "line", "fillOpacity": 5 } },
+        "overrides": []
+      },
+      "targets": [
+        { "datasource": { "type": "prometheus", "uid": "prometheus" }, "expr": "vidconf_pipeline_sessions{status=\"failed\"}", "legendFormat": "сеансов failed", "refId": "A" },
+        { "datasource": { "type": "prometheus", "uid": "prometheus" }, "expr": "sum(vidconf_celery_queue_depth)", "legendFormat": "глубина очередей (сумма)", "refId": "B" }
+      ]
+    }
+  ]
+}
--- a/deploy/monitoring/prometheus.yml
+++ b/deploy/monitoring/prometheus.yml
@@ -4,7 +4,8 @@
 # сервис `prometheus`).
 #
 # Имена метрик backend (`vidconf_http_request_duration_seconds`,
-# `vidconf_pipeline_sessions`, `vidconf_celery_queue_depth`) — КОНТРАКТ с
+# `vidconf_pipeline_sessions`, `vidconf_celery_queue_depth`, `vidconf_db_up`,
+# `vidconf_db_pool_*`, `vidconf_redis_pool_*`) — КОНТРАКТ с
 # `backend/api/metrics.py`; правила в `alerts.yml` используют их буквально —
 # при переименовании метрик в backend поправить оба файла одновременно.
 global:
@@ -1 +1 @@
 .0.31
 .0.32