From a53ba7c82773e74f54a8e89cae93a5aff5912879 Mon Sep 17 00:00:00 2001 From: Max Ronzhin Date: Tue, 28 Jul 2026 19:22:36 +0300 Subject: [PATCH] =?UTF-8?q?fix(monitoring):=20node-exporter=20=D0=BE=D1=82?= =?UTF-8?q?=D0=B4=D0=B0=D0=B2=D0=B0=D0=BB=20=D1=81=D0=B5=D1=82=D0=B5=D0=B2?= =?UTF-8?q?=D1=8B=D0=B5=20=D0=BC=D0=B5=D1=82=D1=80=D0=B8=D0=BA=D0=B8=20?= =?UTF-8?q?=D0=BA=D0=BE=D0=BD=D1=82=D0=B5=D0=B9=D0=BD=D0=B5=D1=80=D0=B0=20?= =?UTF-8?q?=D0=B2=D0=BC=D0=B5=D1=81=D1=82=D0=BE=20=D1=85=D0=BE=D1=81=D1=82?= =?UTF-8?q?=D0=B0?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `node_network_*` показывал трафик собственного `eth0` экспортера (56 МБ) вместо хостового `enp3s0` (39.8 ГБ). При разборе нагрузочного теста 28.07 сетевых метрик хоста не оказалось вовсе — весь анализ трафика пришлось вести по метрикам контейнеров. Причина не в конфигурации экспортера, а в устройстве procfs: bind-mount `/proc` хоста достаточен для CPU, памяти и диска, но `/proc/net` — это симлинк на `self/net`, который резолвится в сетевом namespace читающего процесса. Никакое монтирование это не обходит, нужен host network namespace. Прежний комментарий в compose утверждал обратное — исправлен. Порт 9100 теперь слушается на хосте, наружу не торчит: ufw пропускает только 22/80/443/3478/7881/51820 и UDP-диапазон LiveKit. Prometheus обращается к экспортеру через `host.docker.internal` (`extra_hosts: host-gateway`), потому что по имени сервиса в docker-сети он больше не резолвится. Дашборд `host.json` правок не требует: сетевые панели фильтруют интерфейсы по исключению (`device!~"lo|veth.*|docker.*|br-.*"`), под которое `enp3s0` не подпадает. Алерты на имя instance не завязаны. --- deploy/docker-compose.yml | 33 +++++++++++++++++++++++++------- deploy/monitoring/prometheus.yml | 9 ++++++++- 2 files changed, 34 insertions(+), 8 deletions(-) diff --git a/deploy/docker-compose.yml b/deploy/docker-compose.yml index e35545c..b286be9 100644 --- a/deploy/docker-compose.yml +++ b/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 достаёт их по имени сервиса во внутренней - # сети compose — так безопаснее, не расширяет сетевой доступ контейнера). + # чего нет ни в одном из приложенческих экспортеров выше. + # + # `network_mode: host` ОБЯЗАТЕЛЕН, и вот почему (проверено 2026-07-28, + # до этого экспортер работал в 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) — Prometheus ходит к нему по внутренней сети compose - # (`node-exporter:9100`), публикация на хост для этого не нужна. + # Секции `ports` нет и с host-сетью быть не может: контейнер слушает + # прямо на интерфейсах хоста. От внешнего мира порт закрывает ufw. healthcheck: test: ["CMD-SHELL", "wget -q -O- http://127.0.0.1:9100/metrics >/dev/null || exit 1"] interval: 10s diff --git a/deploy/monitoring/prometheus.yml b/deploy/monitoring/prometheus.yml index 9f70fd0..9355baa 100644 --- a/deploy/monitoring/prometheus.yml +++ b/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, сервис