《CSNA网络分析认证专家实战案例》课件-第4章

第4章某供电局营销应用服务中断问题分析案例4.1故障描述4.2问题分析过程4.3分析结论

4.1.1故障现象

某供电局随着业务的拓展，信息水平不断提升，信息化应用越发突显其关键价值。尽管经过严格测试，各业务用户在上线后还是会遇到许多无法预测的问题。网络带宽、网元健康状况、网络策略、终端性能、用户使用习惯、服务器性能、程序设计等众多相互关联的因素，都会影响到业务的质量，任何一种环境的改变都可能造成业务质量的下降。4.1故障描述某供电局作为供电企业最关键业务应用之一的营销应用出现了多次偶发性死机现象，对该局电网业务造成极大影响。信息部门希望通过这次分析服务，排查故障期间访问过营销系统服务器的主机行为，协助对异常现象进行分析定位，并为网络与应用的运行管理提供优化依据。

下面结合科来网络产品，对该供电局信息部门的网络应用系统的故障问题进行详细分析。4.1.2网络拓扑

用户的网络环境示意图如图4-1所示。

图4-1本案例中部署科来回溯分析系统的目的是对网络进行全面的监控和分析，并不是单纯为了解决营销服务器的问题，因此采用的是核心交换全端口镜像的方式。如果单纯为解决营销服务器的问题，只需要镜像服务器区接口的双向流量就可以实现。

2013年某日下午17时00分左右，营销系统服务器无法访问。通过FTP登录到服务器，发现磁盘空间已经被两个heapdump文件占满。删除heapdump文件，重启营销weblogicserver，服务于17时20分恢复正常。4.2问题分析过程4.2.1服务器流量分析

我们获取营销服务器的访问流量并进行分析(如图4-2所示)，发现从16时48分开始流量持续下降，至17时10分流量达到最低值，接近于0。

图4-2

图4-3这段时间共有251个客户端访问了营销服务器，其中流量最大的是客服中心的两台客户端10.XXX.XXX.165和10.XXX.XXX.157，流量分别达到408.77MB和269.25MB；流量第三的是服务器10.XXX.XXX.121，达到184MB；需要注意的是，流量使用前15名的主机中，多是属于客服中心网段的客户端，大多数流量均超过100MB；大部分访问营销服务器的用户流量不会太高，在8MB左右，如图4-4所示。

图4-44.2.2客户端流量分析

故障发生期间，流量最大的客户端是10.XXX.XXX.165和10.XXX.XXX.157，我们针对其流量作了进一步的分析。

客户端10.XXX.XXX.165使用流量情况如图4-5所示。

图4-5如上图所示，在异常发生期间，客户端10.XXX.XXX.165和营销服务器10.XXX.XXX.11共产生了3591个会话，会话流量从数十KB至数百KB不等，按会话产生的流量进行排序，如图4-6所示。

图4-6流量最大的客户端通过4530端口访问服务器7001端口的会话，共产生了2665个数据报文，流量为2.259MB，对其进行解码时发现了异常情况，如图4-7所示。

图4-7如图4-7所示，该会话过程持续了25秒，会话开始客户端与营销服务器10.XXX.XXX.11建立连接后，客户端在0.017秒后发送了GET请求，请求内容为

GET/j2yd/_assembleLib/systim/fmGrid/lookAndFell/image/btn.jpg

服务器在0.001秒内进行了应答，并开始传输数据，数据内容在0.03秒内传输完毕，客户端又发起了相同的请求，如图4-8所示。

图4-8如图4-8的①处所示，对比上一次的发送时间可知，每隔0.03秒客户端会向服务器发起一个重复的GET请求，请求的对象是“btn.jpg”文件。

我们对相关的会话过程进行了排查整理，发现3591个会话过程中，有3330个会话都一直在请求该文件，剩余261个会话都是故障发生期间客户端发起的TCP连接请求。如此大量的请求数据，客户端是在做什么呢？

“jpg”是以24位颜色存储单个光栅图像的一种图片格式，同时我们发现某些客户端请求相同的文件，却并没有同样的异常行为，见图4-9。

图4-9如图4-9所示，该客户端请求相同的对象，但是仅重复了3次，会话过程没有出现前文所述的异常。

如果不了解应用特征，则很有可能找错方向。供电局负责营销应用的工程师为我们讲述了该文件的作用：从某供电局营销系统应用的角度来看，这些请求的发出，代表的是营销应用客户端模拟点击按钮的操作，我们知道请求了“btn.jpg”文件，要找到其关联的“.do”或者“.js(p)”文件。通过数据解码，如图4-10中②处所示，我们发现该请求是

referer：“1:7001/j2yd/dfScatterRecomShouldAction.do?actionType=GENSHOULD”。也就是说该动作导致了客户端发起“GET…btn.jpg”指令。

图4-10为了得到更直观的指向，我们针对所有会话进行了排查，发现在某些会话过程中(如图4-11所示)，开始期间客户端与服务器的数十次的请求应答，双方行为都较为正常可是到第33次请求的时候，客户端向服务器发送“POSTj2yd/dfScatterRecomShouldAction.do”的请求，收到服务器200OK应答后，就开始了不断地请求btn.jpg文件。

图4-11因此我们认为，这些大量的异常重复的“GET…btn.jpg”的请求，与j2yd/dfScatterRecomShouldAction.do有关。

另外，客户端10.XXX.XXX.157和10.XXX.XXX.149与服务器的会话情况分别如图4-12、图4-13所示。

图4-12

图4-13我们发现，只要“GET…btn.jpg”是referer：“http://10.XXX.XXX.11:7001/j2yd/dfScatterRecomShouldAction.do”的操作，均会出现前文所述的不断密集重复请求的异常。

大量的异常请求，很有可能导致应用系统的异常，建议管理员对该操作进行排查。

(从英文字符的意思来看，df表示电费，Scatter表示分散，Recom含义不详)4.2.3营销应用其他服务器的排查

相同的异常在营销应用的其他服务器上也有体现。如图4-14所示，某些客户端流量远高于与这台服务器相连接的两台数据库服务器10.XXX.XXX.14和10.XXX.XXX.16的流量。

图4-14这些客户端也是在向服务器大量重复请求“btn.jpg”文件，见图4-15。

图4-15

4.3.1故障说明

经过排查，定位出错的程序为“电费管理系统”的“分散复核明细查询”功能模块。4.3分析结论4.3.2优化后监测

我们在监测后期看到各客户端访问营销服务器的流量持续下降，异常流量的减少，很有可能与故障发生后系统管理员对营销应用进行了一系列的优化调整有关，如图4-16所示。

图4-16发生故障时，