问题记录：Prometheus 的 node target 2/3 up（VM2 采集不到）
实训04 监控与运维工具部署 · 环境：Debian 12，三台 VM 同处教室共享二层网络 VM1=10.4.0.1（网关，172.16.30.208 物理） / VM2=10.4.0.10 / VM3=10.4.0.20（Prometheus 9090 所在）
一、现象
Prometheus Targets 页面显示 node (2/3 up)，http://10.4.0.10:9100/metrics（VM2）状态为 DOWN：
Get "http://10.4.0.10:9100/metrics": dial tcp 10.4.0.10:9100: connect: connection refused而 VM1（10.4.0.1）、VM3（10.4.0.20）两个 target 都是 UP。
但 VM2 本机检查一切正常：node_exporter 在跑、监听 *:9100、curl http://localhost:9100/metrics 能拿到数据。
二、排查过程（关键证据链）
- VM2 防火墙不是原因：在 VM2 上
nft monitor trace抓包，grep 'ip saddr 10.4.0.20'计数为 0 —— VM3 发来的 SYN 根本没到达 VM2 的 INPUT 链，说明不是 VM2 侧拦的。 - 冒充设备暴露：在 VM3 上
tcpdump -i ens33 'host 10.4.0.10 and tcp port 9100'，发现发往 10.4.0.10:9100 的 SYN 收到 RST，但 RST 的源 MAC 是00:0c:29:3b:ee:8d，并非 VM2 的真实 MAC00:0c:29:0e:8c:a5—— 有另一台设备冒充 10.4.0.10 在应答。 - 同一 IP 两个 MAC：VM1 的 ARP 表里
10.4.0.10同时出现两条：00:0c:29:3b:ee:8d（ens33 侧）和00:0c:29:0e:8c:a5（ens37 侧），说明两个设备争用同一个 IP。 - ARP 互被毒化：
- VM3 ARP：
10.4.0.10 → 00:0c:29:3b:ee:8d（毒化，应为00:0c:29:0e:8c:a5） - VM2 ARP：
10.4.0.20 → 00:0c:29:d0:c3:c1（VM3 的 IP 也被邻居抢走）
- VM3 ARP：
- 确认是邻居设备：VM2 只有一块网卡 ens33（MAC
00:0c:29:0e:8c:a5），所以00:0c:29:3b:ee:8d必然是隔壁同学的克隆 VM。 - 排除其他假设：
- 不是 node_exporter 配置问题：VM2 服务卸载重装后依旧 DOWN。
- 不是 IPv6 绑定问题：服务绑
*:9100，在bindv6only=0下 IPv4 也能正常接入（VM1 同样[::]:9100但能通）。 - 不是防火墙：见证据 1。
三、根因
共享教室二层网络（同一 L2 广播域）的 ARP/IP 地址冲突。 隔壁同学的克隆 VM 也使用了 10.4.0.10 / 10.4.0.20，导致我们的 VM3 的 ARP 表被毒化——它认为 10.4.0.10 的 MAC 是邻居机的 00:0c:29:3b:ee:8d，于是发往 10.4.0.10:9100 的采集请求被送到邻居机器，邻居没开 9100，回 connection refused。
四、解决方法（VM 内临时 workaround）
在 VM2 和 VM3 上把 ARP 静态钉死到正确 MAC（重启前一直有效；重启后需重钉，可写进 rc.local 固化）：
# ===== VM2 (10.4.0.10) =====
sudo ip neigh replace 10.4.0.1 lladdr 00:0c:29:eb:81:5f nud permanent dev ens33
sudo ip neigh replace 10.4.0.20 lladdr 00:0c:29:1e:12:16 nud permanent dev ens33
# ===== VM3 (10.4.0.20) =====
sudo ip neigh replace 10.4.0.1 lladdr 00:0c:29:eb:81:5f nud permanent dev ens33
sudo ip neigh replace 10.4.0.10 lladdr 00:0c:29:0e:8c:a5 nud permanent dev ens33MAC 对照表：
| 角色 | IP | 正确 MAC |
|---|---|---|
| VM1（网关） | 10.4.0.1 | 00:0c:29:eb:81:5f |
| VM2 | 10.4.0.10 | 00:0c:29:0e:8c:a5 |
| VM3 | 10.4.0.20 | 00:0c:29:1e:12:16 |
钉完后等 Prometheus 约 30s 自动刷新，target 即从 2/3 up 变为 3/3 up 全绿。
五、根治方案（可选）
ARP 钉是 VM 内的临时绕过。真正的根治是在 VMware / 虚拟化层 把这三台 VM 划分到独立的 port group / 私有网络，与教室其他同学的 VM 隔离广播域，从物理上消除 IP 冲突。
附：涉及的相关脚本
04 企业监控与运维工具部署/scripts/pin_arp.sh—— 钉 ARP 的封装脚本（含上述三条ip neigh replace）。04 企业监控与运维工具部署/scripts/reinstall_node_exporter_vm2.sh—— 本次为排除”服务配置”假设而做的一次干净重装（确认不是服务问题）。
Comments NOTHING