php宕机怎么查找问题,网络故障分析案例-如何找出偶发性系统宕机的根源

1.1   问题描述

随着某供电局业务拓展，信息水平不断提升，信息化应用越发突显其关键价值。尽管经过严格测试，各业务应用在上线后总是会遇到各种无法预测的问题：网络带宽、网元健康状况、网络策略、终端性能、用户使用习惯、服务器性能、程序设计……众多相互关联的因素都会影响到业务的质量，任何一个环境都可能造成业务质量的下降。

在某供电局，作为供电企业最关键业务应用之一的营销应用出现了多次偶发性down机现象，对业务造成极大影响，信息部门希望通过这次网络分析服务排查故障期间访问过营销系统服务器的主机行为，协助对异常现象进行分析定位，并为网络与应用的运行管理提供优化依据。

该用户的网络环境示意图如下：

图 1‑1

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

1.1   分析过程

某日下午17点00分左右，发现营销系统服务器无法访问，通过ftp登陆到服务器，发现磁盘空间已经被两个heapdump文件占满，进行删除heapdump文件，重启营销weblogic server，于17:20分服务恢复正常。

1.1.1 客户端流量分析

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

客户端10.XXX.XXX.165：

图 1‑2

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

图 1‑3

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

图 1‑4

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

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

服务器在0.001秒内进行了应答，并开始传输数据，数据内容在0.03秒内传输完毕，客户端又发起了相同的请求；

图 1‑5

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

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

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

图 1‑6

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

如果不了解应用特征，则很有可能找错方向；

供电局负责营销应用的工程师讲述了该文件的作用：从某供电局营销系统应用的角度来看，这些请求的发出，代表的是营销应用客户端模拟点击按钮的操作，我们知道请求了btn.jpg文件，要找到其关联的.do 或者.js(p)文件；

通过数据解码，如下图红字②所示，我们发现该请求是referer to ：

http://10.XXX.XXX.11:7001/j2yd/dfScatterRecomShouldAction.do?actionType=GENSHOULD

图 1‑7

也就是说该动作导致了客户端发起的“GET  …btn.jpg”指令；

为了更直观的指向，我们针对所有会话进行了排查，发现在某些会话过程中，如下图所示：

图 1‑8

在上图的会话过程中，开始期间客户端与服务器的数十次的请求应答，双方行为都较为正常；到第33次请求的时候，165客户端向客户端发送：

POST j2yd/dfScatterRecomShouldAction.do请求，收到服务器200 OK应答后，就开始了不断地请求btn.jpg文件；

因此我们认为，这些大量的异常重复的Get btn.jpg的请求，与j2yd/dfScatterRecomShouldAction.do 有关；

其他流量较大的客户端：

客户端 10.XXX.XXX.157：

图 1‑9

客户端 10.XXX.XXX.149：

图 1‑10

我们发现只要Get … btn.jpg是referer:

http://10.XXX.XXX.11:7001 /j2yd/dfScatterRecomShouldAction.do的操作，均会出现前文所述的不断密集重复请求的异常；

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

(从英文字符的意思来看，df = 电费，Scatter =分散，Recom =？)

1.1.1 营销应用其他服务器排查

相同的异常在营销应用的其他服务器上也有体现；

某些客户端流量远高于与这台服务器相连接的两台数据库服务器10.XXX.XXX.14和16的流量：

图 1‑11

这些客户端也是在向服务器大量重复请求btn.jpg：

图 1‑12

1.2   分析结论

经过排查，出现故障的原因是由于客户在业务系统中存在一个因代码bug导致客户端产生大量重复请求导致服务器响应异常。

经系统维护人员修改代码后系统恢复正常

1.3   价值

通过网络分析技术，可帮助用户快速定位到业务系统访问过程中存在的异常。尤其是客户端与服务端交互是正常的协议交互，通过网络分析可快速定位到具体的原因，极大程度上提升IT的运维效率，提升了系统运行的稳定性和高效性。