linux 网络丢包监控 linux ping丢包_linux 局域网内互ping丢包

D-SMART的雷达图上看到操作系统扣分十分严重,打开一看,原来是网络丢包量十分严重。后来换了根网线,这个问题就消失了,看样子真的和网络有关。

这两天一个客户那边有几套系统,我们的D-SMART总是报警网络有丢包,高峰的时候会达到每秒几百个。一般情况下,每秒有十个八个丢包是不会报警的,不过如果比较高的时候,必须做一个分析,否则心里总觉得不安心。于是我们就在INTEL等朋友的帮助下边学边干,工作过程中发现LINUX的网络分析武器库还是十分强大的,如果我们能够用好,完全是可以解决目前的大多数问题的。

linux 网络丢包监控 linux ping丢包_丢包_02

linux上网络排查的武器库还是挺完备的,从最简单的ifconfig,到netstat(linux 7可以使用增强版的工具ss),再到网络接口工具ethtool,网络抓包工具tcpdump,网络路由跟踪工具mrt等待。一般来说通过这些工具就能够抓取到我们所需要的诊断数据了。


ifconfig


ifconfig是最为常用的网卡诊断工具。除了可以看网卡绑定的IP地址以及状态外,还可以查看报错信息。

linux 网络丢包监控 linux ping丢包_数据_03

通过errors/dropped/overruns这几个指标我们可以了解网卡的工作情况,error是出现了网络错误,dropped是出现了格式不正确被丢弃的包,overruns 驱动缓冲不足或者网络中断处理不及时导致的缓冲溢出的数量


ethtool


ethtool是网卡诊断最为重要的工具,大多数的网卡上面的问题都可以通过这个工具来检查。下面一套系统的网络丢包问题比较严重,通过ethtool很明显就发现了问题。

linux 网络丢包监控 linux ping丢包_linux 局域网内互ping丢包_04

rx_errors的错误数量和rx_crc_errors的数量差不多。主要是crc导致的问题。一般crc_errors是level 1的错误,和网络介质、网卡、交换机端口等物理设备有关。所以可以直接交给网络组去进一步分析了。

ethtool -k可以查看网卡上的各个开关的状态,有时候调整这些开关可以起到优化的作用。

linux 网络丢包监控 linux ping丢包_linux_05

ethtool -g可以查看ring buffer的状态,网络流量过大,ring buffer不足会导致大量的overruns和dropped的包产生。(明天的另外一篇文章里,老白会详细介绍网络诊断的一些常用流程)。

linux 网络丢包监控 linux ping丢包_linux 网络丢包监控_06


netstat


netstat -in可以大体上看到各个网卡的情况,包括ERR/DRP/OVR等的计数。

linux 网络丢包监控 linux ping丢包_linux_07

通过netstat -in看,RX-DRP的数量比较高,而且还在不断的增长。这就说明目前网络包的dropped一直在发生。

而通过netstat -s看到的统计数据中,各种错误的统计:


linux 网络丢包监控 linux ping丢包_丢包_08

ss

 Linux 7开始提供的一个socket分析工具,包含绝大多数netstat的功能,并能够提供更为详细的数据。socket分析的利器。


linux 网络丢包监控 linux ping丢包_linux_09


/proc/net/dev这个文件里我们可以采集到netstat -in中所有的信息,监控软件之间读取里面的数据就可以很方便的完成相关的采集了。其中的fifo的含义和overruns类似,不过更为底层,就是ring buffer出现fifo丢弃的次数,此指标不为零说明ring buffer存在不足的问题。


linux 网络丢包监控 linux ping丢包_linux_10


tcpdump最为强大的抓包分析工具之一。如果需要一些专业分析的时候可以使用。比如分析一下是否存在超过MTU大小的包:tcpdump -v -c 10 -ni enp26s0f0 -ttt greater 1532


linux 网络丢包监控 linux ping丢包_linux 网络丢包监控_11


mtrmtr(mytraceroute)是一个端到端网络连通性分析的重要工具。


linux 网络丢包监控 linux ping丢包_linux 网络丢包监控_12

如果要分析网络端到端的质量,可以直接使用mtr -r 在报告中可以看到所有网络跳转的统计信息,包括丢包率,ping的延时,以及方差。如果你看到中间的某一跳的丢包率较高,并不意味着这一跳一定存在问题,因为有可能这一跳的设备上对icmp做了限流,你看到的最后一跳的结果是最终的结果,因此如果某一跳存在问题,后续的各跳都正常了,那么不一定问题就存在。