用监控工具找故障

笔者单位客服系统运行中频繁出现卡顿现象：每个坐席在不定时段都会出现，具有一定的普遍性。经过简短分析，认为有两种可能，一是网络问题造成的，二是软件系统本身造成。

首先检查网络，在不同坐席的电脑上Ping网关一段时间，都发现有丢包现象，于是断定是网络丢包造成的系统卡顿。接下来结合该系统的网络架构与各种监控工具进行追查，寻找问题的解决方式。下面介绍网络检查，排除故障的过程。

使用Ping命令初步检查网络

使用Ping大包的方式查看网络是否有丢包现象。很多时候普通Ping不丢包，而Ping大包时则发现开始丢包，证明网络确实存在问题。

图1 客服系统网络架构图

-l后的参数（size）为数据包，范围0到65500，与-l一起使用，控制每次Ping发送的字节数。不使用这套参数时，默认Ping发送数据包为32byte。-t参数表示一直Ping，直到手动终止。使用Ctrl + C可以立刻终止，并提供这段时间的Ping包统计信息，包括发送包数、接受包数、丢失包数、丢失率等信息。

用两台坐席电脑分别Ping内网核心交换机（即内网网关）若干小时，获取数据进行分析：Ping大包丢失率达到20%，Ping普通包丢失率3%。说明网络质量不佳，传输数据量越大丢包率越高。另外提供佐证，当把客服核心交换机组下带的几路视频监控线路去除掉时，Ping大包的丢包率有明显下降。

使用流量监控程序分析问题

公司的网络管理软件已经对客服系统核心交换机组进行流量监控。调出最近的数据，对客服核心交换机组的三台交换机进行分析。

客服交换机组的级联方式如图1所示。其中交换机B与C直接连接到A上，而A则通过光纤收发器连接到机房的内网核心交换机上。系统对A、B、C的级联接口都进行了流量监控。分析这些接口的流量监控图，发现交换机A的上联口最能反映出问题所在（如图2）。上联口错包数非常多，丢包数也非常多。当把几路客服视频监控重新连接上之后，在流速与带宽利用率曲线图中有明显的波峰，但峰值并不高——带宽利用率不到15%，可分析出此次网络问题并非是带宽不足造成的。交换机A的错包问题，在其他几个交换机是不存在的，在A本身的下联口中也不存在。初步定位交换机A上联口有问题。

图2 客服核心交换机A流量监控图

图3 局域网抓包信息

排查客服交换机

根据上一步的分析对交换机组进行逐一排查，进行验证，找到问题原因。

首先，将笔记本分别连接在交换机B与C上，Ping内网核心交换机，发现都有丢包。然后连接到交换机A上继续Ping，同样有丢包，且发现这几次测试的丢包率与普通坐席Ping的丢包率接近。因此，可排除交换机B与C损坏所致。

然后，将笔记本直接连接客服端的光纤收发器电口上，Ping依旧丢包，且丢包率与上面几次测试都接近。可以基本断定非交换机组的设备问题，而是光的收发与传输问题。

排查光传输设备

使用光功率计分别测量机房与客服两处的光纤收发器一发一收的光功率，并计算出光衰减，机房到客服光衰减为-5db；客服到机房光衰减为-6db；根据此数据判断，光衰减在正常范围之内。但经过光纤收发器之后就有丢包，推断是光纤收发器有问题。

因现在的内网核心交换机与客服核心交换机A都具有光口，可以直接使用光模块连接，于是弃用光纤收发器，改用两个千兆光模块直连光纤，并开启全双工模式。命令：

speed 1000

duplex full

更换光模块后，再Ping包，发现没有丢包现象发生。测光功率，计算光衰减，也有一定改善。问题基本解决。

后续观察

运维人员继续观察，使用坐席电脑Ping 24小时，然后追查LOG，发现没有丢包现象。查看流量监控图，发现错包数为0，丢包数几乎为0。至此，故障完全排除。

补充：抓包分析网络数据

现实的排除故障过程中，怀疑过是否因为局域网里出现网络风暴。于是使用WireShark工具，进行网络抓包然后分析数据。

经过对抓取数据的分析，确实网络中有一些坏包、错包，但这种数据不多，也没有网络风暴（如图3中黑色数据行），可以判断不是这个原因所致。