nmcli 本身不能监控网卡丢包计数，仅用于确认网卡是否被正确识别和启用；真正排查物理链路隐患需结合 ethtool 和 /proc/net/dev 查看 rx_fifo_errors、rx_crc_errors 等硬件计数器，并通过 ethtool 检查链路状态、速率、双工模式及自动协商结果。
直接用 nmcli 本身不能监控网卡丢包计数——它不提供底层统计功能，只管理网络连接配置。要排查物理链路隐患（如线缆松动、光衰、协商失败、FEC错误等），必须结合系统级工具读取网卡硬件和驱动层的丢包指标。nmcli 的作用是辅助确认网卡是否被正确识别和启用，为后续监控打基础。
先确认网卡状态是否正常（nmcli 可做）
丢包常始于物理层未就绪。用 nmcli 快速验证：
-
nmcli device status：看目标网卡（如 eth0）状态是否为 connected 或 unmanaged；若显示 unmanaged，说明 NetworkManager 未接管该接口，需检查配置或服务冲突 -
nmcli device show eth0 | grep -E "(GENERAL.STATE|GENERAL.CONNECTION)"：确认是否已绑定有效连接，且状态为 100（connected） - 若网卡未列出，运行
ip link show eth0确认内核是否识别到设备；若存在但 nmcli 不见，大概率是配置文件丢失或 network.service 干扰
真正监控丢包资源计数，靠 ethtool 和 /proc/net/dev
物理链路隐患会直接反映在网卡硬件计数器中，关键字段包括：
-
rx_fifo_errors（Ring Buffer 溢出）：执行
ethtool -S eth0 | grep -i "fifo\|drop"，持续增长说明接收缓冲区填满，常见于高流量+低配CPU或中断集中 -
rx_errors / rx_crc_errors / rx_frame_errors：执行
cat /proc/net/dev查看 eth0 行的 errs 列，或ethtool -S eth0 | grep -E "(crc|frame|rx_errors)"；非零值强烈提示物理链路异常（线缆质量差、模块光衰、双工不匹配、端口损坏） -
rx_overruns：在
ifconfig eth0输出中对应 “overruns” 字段，本质是 NIC 内部 FIFO 溢出，与rx_fifo_errors含义一致，但更偏底层硬件行为
联动检查物理协商与驱动健康
仅看计数不够，要定位隐患源头：
- 运行
ethtool eth0，重点确认：
• Link detected: yes（物理链路连通）
• Speed: 与对端设备一致（如都为 1000Mb/s）
• Duplex: 均为 Full，避免半双工导致冲突丢包
• Auto-negotiation: on 且成功；若显示 failed，需手动协商或更换线缆 - 查驱动异常：
dmesg | grep -i "eth0\|firmware\|nic" | tail -20，关注 DMA timeout、reset failed、link down 等关键词 - 对比两端设备：登录交换机/路由器，查看对应端口的 input errors、runts、giants、buffer overflows，若双方均升高，基本锁定物理链路问题
建立简易丢包监控（可脚本化）
把关键指标聚合起来，每5秒刷新一次：
示例命令（保存为 monitor-drop.sh）：watch -n 5 'echo "== ethtool stats =="; ethtool -S eth0 | grep -E "(rx_fifo|rx_crc|rx_frame|rx_errors)"; echo; echo "== /proc/net/dev =="; cat /proc/net/dev | grep eth0; echo; echo "== ethtool link =="; ethtool eth0 | grep -E "(Link|Speed|Duplex|Auto)"'
重点关注输出中数值是否随时间**单调递增**——稳定不变是正常的，跳变或持续涨就是隐患信号。
