linux 局域网内互ping丢包_LINUX下的网络分析武器库

以前遇到过不少因为网络丢包导致数据库故障的情况，所以在开发D-SMART的时候引入了网络丢包指标。在一些用户现场还真发挥了一些作用。有一个客户的某个半夜执行的批量抽数应用突然变慢了，平时5分钟完成的工作经常半小时还跑不完。查看执行计划、SQL的执行开销，表的数据量等都没有任何差异。Oracle原厂工程师发现的唯一疑点就是SQL *NET MORE DATA TO CLIENT等待的数量变大了，其他并无发现。

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

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

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

ifconfig

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

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

ethtool

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

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

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

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

netstat

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

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

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

ss

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

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

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

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

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