feat(monitoring): метрики CPU/RAM/диска хоста и контейнеров

Дашборд «Пайплайны пост-обработки» покрывал только прикладную логику —
нехватка памяти/CPU на сервере была видна только косвенно, по латентности API.

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

deploy/monitoring/alerts.yml

@@ -60,3 +60,58 @@ groups:
       #       суммаризация встанет (задачи будут копиться в очереди summarize,
       #       см. также алерт QueueGrowing). Проверить
       #       `docker compose ps llm` / `llm-gpu` и `docker compose logs llm`.
+
+  # Железо хоста (job `node` — node-exporter). Пороги подобраны под
+  # конкретный сервер 1gb: 8 ГБ RAM, 4 CPU, 50 ГБ диска — если сервер
+  # сменится, пересчитать.
+  - name: vidconf-host
+    rules:
+      # MemAvailable — уже честная оценка Linux с учётом того, что легко
+      # освобождаемый page cache/buffers не в счёт (в отличие от naive
+      # used = total - free). 10% от 8 ГБ ≈ 800 МБ — `for: 10m`, чтобы не
+      # дёргать на кратковременный всплеск (например, разовый всплеск
+      # transcribe/summarize), но успеть среагировать до OOM killer.
+      - alert: HostMemoryLow
+        expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100 < 10
+        for: 10m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Мало свободной памяти на хосте"
+          description: >-
+            Свободно {{ $value | printf "%.1f" }}% RAM дольше 10 минут
+            (порог 10% ≈ 800 МБ из 8 ГБ). Смотреть, какой контейнер ест
+            память — дашборд «Хост и контейнеры», топ по памяти (cAdvisor).
+
+      # 50 ГБ диска — 10% ≈ 5 ГБ. `for: 15m` (не мгновенно): диск не растёт
+      # так же резко, как память, ложные срабатывания на всплеск не грозят,
+      # но и разовая проверка на границе некритична — 15 минут отсекает шум.
+      - alert: HostDiskLow
+        expr: (node_filesystem_avail_bytes{mountpoint="/",fstype!="tmpfs"} / node_filesystem_size_bytes{mountpoint="/",fstype!="tmpfs"}) * 100 < 10
+        for: 15m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Мало места на диске хоста"
+          description: >-
+            Свободно {{ $value | printf "%.1f" }}% диска дольше 15 минут
+            (порог 10% ≈ 5 ГБ из 50 ГБ). Частые причины на этом проекте —
+            записи транскрибации (`recordings`), логи docker, образы/слои
+            после пересборки — проверить `docker system df`.
+
+      # 4 CPU. Порог 90% и `for: 15m` — сознательно строже по времени, чем
+      # у памяти/диска: кратковременные пики от пайплайна пост-обработки
+      # (транскрибация/суммаризация) — это ожидаемая, не аварийная нагрузка,
+      # алерт должен ловить именно устойчивую перегрузку, а не обычный всплеск.
+      - alert: HostCpuHigh
+        expr: 100 - (avg(rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 90
+        for: 15m
+        labels:
+          severity: warning
+        annotations:
+          summary: "Устойчиво высокая загрузка CPU хоста"
+          description: >-
+            Загрузка CPU {{ $value | printf "%.1f" }}% дольше 15 минут
+            подряд (порог 90% из 4 ядер). Смотреть топ контейнеров по CPU
+            (дашборд «Хост и контейнеры», cAdvisor) и латентность API —
+            возможно, не хватает уровня AI/ресурсов под нагрузку.