应直接用ip -s link show dev 网卡名查看RX/TX errors：rx_errors是物理层错误总和（含crc/frame/length等），持续增长指向网线、光模块或双工问题；tx_errors罕见，非零需查carrier/aborted类错误；rx_dropped/tx_dropped属内核主动丢弃，非硬件故障。
直接用 ip -s link show dev 看聚合错误数，但不分类
执行 ip -s link show dev ens33（把 ens33 换成你的真实网卡名）后，RX 块里第一行的 rx_errors 是总和，它包含 CRC、frame、length、symbol 等多种错误，但不告诉你哪一类在涨。这个值非零且持续上升，基本可断定是物理层或驱动问题——比如网线松动、光模块衰减、双工不匹配，而不是配置错误。
别信 ifconfig ens33 或 cat /proc/net/dev 里的 errs 列：前者已废弃，后者统计口径旧、部分驱动不刷新，可能长期为 0 即使实际错包很多。
ethtool -S 才能查到具体错误类型
ethtool -S ens33 输出的是网卡驱动从硬件寄存器读出的原始计数，字段名因芯片而异（Intel igb 和 Broadcom bnxt 完全不同），必须结合 ethtool ens33 先确认 Link、Speed、Duplex 是否正常，再查错误。
-
rx_crc_errors > 0→ 线缆接触不良、交换机端口故障或电磁干扰 -
rx_missed_errors或rx_no_buffer持续涨 → ring buffer 太小或软中断处理不过来，需调ethtool -G ens33 rx 4096 -
rx_over_errors高 → 接收 FIFO 溢出，常和 CPU 负载高、RPS/RFS 绑定不合理强相关 -
tx_carrier_errors非零 → 对端链路反复断连（如光纤闪断、交换机端口 flapping）
过滤常用字段可用：ethtool -S ens33 | grep -E "(crc|miss|over|carrier|aborted)"，但别只搜关键词——先看完整输出，确认字段是否存在。
为什么 sar -n EDEV 不适合实时错误分类
sar -n EDEV 1 确实能输出每秒的 RX/TX errors，但它只给聚合值，和 ip -s link 同源，没有底层寄存器级细分。更关键的是：sar 默认不采集 EDEV 数据，需手动启用 —— 编辑 /etc/default/sysstat 把 ENABLED="false" 改成 "true"，再重启 sysstat 服务，否则跑出来全是 0。
而且 sar 的采样间隔（哪怕设成 1 秒）本质是轮询快照，无法捕捉瞬时 burst 错误；真正要定位根因，还是得靠 ethtool -S 的寄存器快照 + 时间差比对。
监控脚本里怎么安全提取错误字段
直接用 awk 解析 ethtool -S 输出风险很高——字段顺序不固定、空格数量不一、某些网卡甚至用下划线分隔（如 rx__missed_errors）。稳妥做法是：
- 先用
ethtool -S ens33 | awk '/^rx_.*errors/ {print $1}'列出所有疑似错误字段名 - 对每个字段单独取值：
ethtool -S ens33 | awk -F ': ' '$1 ~ /^rx_crc_errors$/ {print $2+0}'（+0强制转数值，避免空字符串报错） - 两次采样做差时，注意有些字段是只增计数器（如
rx_crc_errors），有些是瞬时值（如某些厂商的rx_error_rate），混用会得出荒谬结果
最易被忽略的一点：rx_dropped 和 rx_errors 完全不是一回事。rx_dropped 是内核主动丢弃（比如 net.core.netdev_max_backlog 溢出），rx_errors 才是硬件/驱动层真实错包。两者同时上涨，大概率是不同层面的问题，不能合并归因。
