docs(deploy): правило ufw для скрейпа node-exporter из docker-сети

node-exporter переведён в host-сеть (иначе отдавал сетевые метрики
контейнера вместо серверных), и порт 9100 теперь слушается на хосте —
а значит Prometheus из docker-сети упирается в политику ufw по умолчанию.
Без этого правила таргет `node` остаётся down с `context deadline exceeded`.

Правило узкое: только из внутренних docker-подсетей (172.16.0.0/12 не
маршрутизируется в интернете) и только на 9100. Снаружи порт закрыт.

Инсталлятор firewall не настраивает — это ручной шаг документации,
поэтому строка добавлена именно сюда, иначе на новой инсталляции
мониторинг хоста молча останется без сетевых метрик.

deploy/docker-compose.yml

@@ -662,6 +662,12 @@ services:
       - ./monitoring/prometheus.yml:/etc/prometheus/prometheus.yml:ro
       - ./monitoring/alerts.yml:/etc/prometheus/alerts.yml:ro
       - prometheus_data:/prometheus
+    # node-exporter живёт в host-сети (см. комментарий у него) и по имени
+    # сервиса в docker-сети больше не резолвится. `host-gateway` — штатный
+    # способ дать контейнеру адрес хоста, не завязываясь на конкретный IP
+    # docker-моста.
+    extra_hosts:
+      - "host.docker.internal:host-gateway"
     # Loopback-only: админ-доступ по ssh-туннелю, наружу не публикуется.
     ports:
       - "127.0.0.1:9090:9090"
@@ -711,13 +717,27 @@ services:
 
   node-exporter:
     # Метрики железа хоста (CPU, память, диск, сеть, load average) — то,
-    # чего нет ни в одном из приложенческих экспортеров выше. Без
+    # чего нет ни в одном из приложенческих экспортеров выше.
-    # `network_mode: host` (не нужен: читаем /proc,/sys,/ хоста через
+    #
-    # bind-mount, а Prometheus достаёт их по имени сервиса во внутренней
+    # `network_mode: host` ОБЯЗАТЕЛЕН, и вот почему (проверено 2026-07-28,
-    # сети compose — так безопаснее, не расширяет сетевой доступ контейнера).
+    # до этого экспортер работал в bridge-сети и отдавал неверные данные).
+    # Bind-mount'а `/proc` достаточно для CPU, памяти и диска, но НЕ для сети:
+    # `/proc/net` — это симлинк на `self/net`, который резолвится в сетевом
+    # namespace ЧИТАЮЩЕГО процесса. В bridge-сети экспортер видел собственные
+    # `lo` и `eth0` (56 МБ трафика) вместо хостового `enp3s0` (39.8 ГБ), то
+    # есть `node_network_*` показывал трафик контейнера, а не сервера. При
+    # разборе нагрузочного теста 28.07 сетевых метрик хоста не оказалось
+    # вовсе — см. .forcc/LOAD-FINDINGS.md.
+    #
+    # Порт 9100 при этом слушается на хосте. Наружу он не торчит: ufw
+    # пропускает только 22/80/443/3478/7881/51820 и UDP-диапазон LiveKit
+    # (проверено `ufw status`). Prometheus обращается к нему через
+    # `host.docker.internal` (см. `extra_hosts` у сервиса prometheus и
+    # таргет `node` в deploy/monitoring/prometheus.yml).
     image: prom/node-exporter:v1.8.2
     restart: unless-stopped
     pid: host
+    network_mode: host
     volumes:
       - /proc:/host/proc:ro
       - /sys:/host/sys:ro
@@ -727,9 +747,8 @@ services:
       - '--path.sysfs=/host/sys'
       - '--path.rootfs=/rootfs'
       - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($$|/)'
-    # Не публикуем порт наружу вообще (не 127.0.0.1:9100, а совсем без
+    # Секции `ports` нет и с host-сетью быть не может: контейнер слушает
-    # ports) — Prometheus ходит к нему по внутренней сети compose
+    # прямо на интерфейсах хоста. От внешнего мира порт закрывает ufw.
-    # (`node-exporter:9100`), публикация на хост для этого не нужна.
     healthcheck:
       test: ["CMD-SHELL", "wget -q -O- http://127.0.0.1:9100/metrics >/dev/null || exit 1"]
       interval: 10s

deploy/monitoring/prometheus.yml

@@ -38,9 +38,16 @@ scrape_configs:
   # — сервис node-exporter). Единственный источник, который покажет
   # нехватку памяти/CPU на сервере, если она не проявится как рост
   # латентности API (см. дашборд host.json).
+  #
+  # Адрес `host.docker.internal`, а не `node-exporter:9100`: с 2026-07-28
+  # экспортер работает в host-сети и по имени сервиса в docker-сети не
+  # резолвится. Причина перевода — сетевые метрики: `/proc/net` это симлинк
+  # на `self/net`, поэтому в bridge-сети экспортер отдавал трафик
+  # собственного `eth0` вместо хостового `enp3s0`. Имя резолвится через
+  # `extra_hosts: host-gateway` у сервиса prometheus (deploy/docker-compose.yml).
   - job_name: node
     static_configs:
-      - targets: ["node-exporter:9100"]
+      - targets: ["host.docker.internal:9100"]
 
   # Метрики по каждому контейнеру (CPU/память/сеть отдельно у backend,
   # worker, postgres и т.д. — профиль monitoring, сервис
@@ -53,6 +60,32 @@ scrape_configs:
     static_configs:
       - targets: ["container-exporter:9419"]
 
+  # LiveKit SFU (профиль `media`). Порт объявлен в самом LiveKit —
+  # `deploy/livekit/livekit.yaml.template`, секция `prometheus: port: 6789`;
+  # наружу он не публикуется, скрейп идёт по имени сервиса внутри docker-сети.
+  #
+  # Почему это важно отдельно от `container-exporter`: тот показывает CPU,
+  # память и суммарный трафик контейнера, но ничего не знает о том, ЧТО внутри
+  # этого трафика. Разбор нагрузочного теста 28.07.2026 пришлось делать по
+  # логам именно потому, что job'а здесь не было (см. .forcc/LOAD-FINDINGS.md).
+  #
+  # Ключевое, что отсюда появляется:
+  #   livekit_track_subscribed_total / livekit_track_published_total —
+  #     подписки против публикаций, то есть прямой эффект adaptiveStream;
+  #   livekit_participant_total, livekit_room_total — нагрузка в участниках;
+  #   livekit_quality_score, livekit_packet_loss_percent, livekit_rtt_ms,
+  #     livekit_jitter_us, livekit_nack_total, livekit_pli_total — качество
+  #     связи у клиентов, а не догадки по событиям congestion в логах;
+  #   livekit_webhook_queue_length, livekit_webhook_dispatch_total — очередь
+  #     доставки вебхуков в backend (на тесте она росла до 56 секунд).
+  #
+  # Профиль `media` входит в дефолтный набор COMPOSE_PROFILES (см. .env.example),
+  # поэтому job включён, а не закомментирован, как `llm`. На инсталляции без
+  # профиля `media` таргет не резолвится — закомментируйте секцию.
+  - job_name: livekit
+    static_configs:
+      - targets: ["livekit:6789"]
+
   # Локальный LLM-сервер (llama.cpp, LLAMA_ARG_ENDPOINT_METRICS=1). Адрес
   # `llm:8080` разрешается ОДНИМ из двух compose-сервисов в зависимости от
   # выбранного при установке пресета — `llm` (CPU, профиль `llm`, уровни

docs/deploy/DEPLOYMENT.md

@@ -85,6 +85,17 @@ ufw allow 54000:54100/udp   # LiveKit WebRTC media (ICE), см. docker-compose.y
 # TURN (coturn) — только если включаете раздел 8:
 # ufw allow 3478/tcp
 # ufw allow 3478/udp
+
+# Мониторинг (профиль `monitoring`): node-exporter работает в host-сети —
+# иначе он отдаёт сетевые метрики собственного контейнера вместо метрик
+# сервера (`/proc/net` — симлинк на `self/net`, bind-mount `/proc` этого не
+# обходит; см. комментарий у сервиса в deploy/docker-compose.yml). Порт
+# слушается на хосте, поэтому Prometheus в docker-сети упирается в
+# политику ufw по умолчанию. Правило разрешает скрейп ТОЛЬКО из внутренних
+# docker-подсетей — снаружи 9100 остаётся закрыт (172.16.0.0/12 не
+# маршрутизируется в интернете):
+ufw allow from 172.16.0.0/12 to any port 9100 proto tcp comment 'node-exporter: скрейп Prometheus из docker-сети'
+
 ufw enable
 ```