Agent采集数据分析定位的方法

无需加好友免费技术支持

前言

网络慢、ping延迟大或丢包是网络运维中常见的故障之一。如何准确定位故障原因是困难和可行的。类似的故障不能通过网络管理系统或Agent采集数据分析定位的方法。

本案例是高校门户网站间歇性故障分析过程，涉及数据包重传输分析，现整理分享，希望对运维人员有所帮助和启发。

摘要

通过前面的多点采集分析，确定故障原因不是WAF所致。

本节进一步结合服务器端收集的报纸进行对比分析。

分析精确定位到故障对象，并详细剖析和解答了为何出现故障，以及故障又是如何恢复，为解决问题提供了明确指导和参考。

调整数据采集点

为了进一步准确定位问题的位置，本分析采用了多点数据采集的方法。如下图所示，服务器、服务器汇聚交换机和WAF数据采集在三个位置，如核心交换机。

便于记录，这里分别命名采集点1、采集点2和采集点3。

故障分析

数据采集设置完成后，系统持续采集数据包。

以下是2019年11月4日17:20左右故障分析。

如下图。

故障发生时，针对同一个故障TCP对会话流数据，我们对三点采集报文进行了比较分析。发现以下结果：

采集点1:主动发送TCP连接请求，无响应，继续重新传输；收集点2：收集交换机，看到收集点1发送的请求信息，也看到相应的响应数据信息，继续重新传输；收集点3：看到与收集点2相同的信息，并继续重新传输。详细的比较图如下。

在222.111.66.在180(虚假地址)故障期间，我们分析了同一网段其他主机的通信情况。下图为222.111.66.此时251(虚假地址)网络传输正常。

这说明故障只发生在网关(汇聚交换机)和服务器22.111.66.180中间。

深入分析

通过对相关数据包的深入分析，我们发现网关222发生故障.111.66.1 ARP表中没有了222.111.66.180条目，或有但不正确。

这说明网关找不到服务器222.111.66.180，进而导致丢包。

如下图所示，在故障期间，从收集点2可以看到网关22.111.66.1上的ARP表信息发生变化，网关无法获取服务器22.111.66.180的MAC地址。

网关多次广播查询服务器MAC地址，均无结果。

接着，我们从采集点1看，即在服务器上看。

服务器看到了下图框选择的内容并寻找它ARP请求，但没有回应。ARP信息和收集点2一模一样。

在这里，由于服务器本身，故障。

那么，如何恢复故障呢？

经过一段时间的数据包重传，服务器180主动更新一次ARP信息。下图Frame 274表示服务器询问网关MAC地址，Frame 275网关立即回应，告诉自己物理地址。

故障立即消失。

由于服务器本身的动作，应用程序恢复正常。

分析结论

故障范围已大大缩小；

故障对象为应用服务器；

故障的原因是网关找不到服务器MAC地址；

服务器看到了网关ARP请求，无响应；

故障恢复的原因是服务器主动启动ARP更新请求，得到网关响应；

当出现故障时，同一网段的其他服务器通信正常。

建议解决问题

由于故障对象被锁定为服务器本身。

接下来，发现问题相对简单。

故障对象包括：服务器和交换机两端的网卡及设置、传输介质质量等，建议检查这部分，可采用替换对象的方法排除。

解决和验证故障

根据分析结论，服务器是导致故障的对象。

网络管理人员试图重启网卡，但在重启网卡时，他们无法重启网卡。

然后重启操作系统，网卡恢复正常，故障不再发生。

系统连接信息验证

下图显示了故障解决后系统网络运行的视图。

在故障恢复前，应用服务器每隔一段时间发送的连接数显著下降，故障数相应上升。

故障恢复后，连接数没有下降。

ARP数据分析验证

同样，我们通过采集点2和采集点3ARP数据分析。服务器本身没有出现。ARP请求回应问题，故障不再发生。