网络流量 应用性能分析 故障定位分析项目.docx

网络流量 应用性能分析 故障定位分析项目.docx

《网络流量 应用性能分析 故障定位分析项目.docx》由会员分享，可在线阅读，更多相关《网络流量 应用性能分析 故障定位分析项目.docx（46页珍藏版）》请在冰豆网上搜索。

网络流量应用性能分析故障定位分析项目

XX省农信社

基于产品的网络流量、应用性能分析、故障定位分析项目测试报告

2020年2月26日

1概述

随着大量新兴技术和业务趋势的推动，用户的网络架构、业务系统和数据流量日趋庞大、复杂。

为了保证网络和业务系统运行的稳定和畅通，我们需要对网络及业务系统进行全方位监测，以确保网络及应用系统可以正常、持续地运行。

应用性能管理是一个新兴的市场，其解决方案通过监控应用系统的性能、用户感知，在应用出现异常故障时，帮助用户快速的定位和解决故障，其标准的需求如下：

Ø通过网络流量分析工具，掌握各级网络运行的趋势和规律，主动、科学地进行网络规划和策略调整，将网络管理的模式从被动变为主动：

Ø通过网络流量分析工具，实时监控网络中出现的非法流量，及时采取管控措施，保障应用系统的安全运行；

Ø应用系统出现问题（如运行缓慢或意外中断时，）通过网络流量分析工具可回溯历史网络流量，快速找出问题的根本原因并及时解决。

Ø网络拥堵时，通过网络流量分析工具快速判断是正常应用系统占用了带宽还是异常流量占用了带宽，立即执行相应、有效的控制措施。

Ø从最终用户感知的角度，提供多维度的应用性能监控，实时掌握应用系统的性能状况；

Ø7×24小时实时监控各区域用户的真实使用体验，及时发现用户体验下降，并及时作出相应的处理，提升用户满意度。

Ø当故障发生时，快速定位故障域，缩短故障分析时间，降低故障对最终用户造成的影响，提高系统的运维质量。

年APM市场全球分析报告与魔力象限分析，Riverbed（OPNET）公司已经成为全球这个领域的领导者。

OPNET公司的客户群体非常广泛，国内的用户包括中国移动、中国网通、中国电信、信息产业部电信规划研究院，中国农业银行总行，民生银行，新华人寿，中国海关总署，银河证券，国信证券，电信设备供应商中包括华为、大唐电信、摩托罗拉、中兴电子及西门子等。

2测试方案

OPNET网络应用性能监控设备，及OPNET应用性能深度分析，提供了业界最优秀的最终用户体验监控与预警、应用SLA监控与违反预警、应用性能瓶颈定位、应用性能问题根源分析、未知/异常流量发现、流量成分分析、流量流向分析、及应用预部署仿真系统。

XX省农信社的应用服务器目前主要部署在核心机房，大致分为3个区域，生产区域、广域网区域、网银区域。

当应用出现问题或柜面用户出现无法使用业务系统时很难快速确定问题出现在网络问题、服务器问题还是应用本身问题。

为了能够快速了解客户端运行业务的性能问题的变化状况，快速了解应用可能出现的问题区域，建议分别在XX省农信社生产区域、广域网区域、网银区域的核心交换机上通过端口镜像的方式将流量监控起来，当出现应用性能问题时能够通过关联分析了解整个应用流程的性能变化状况和快速提取出现性能问题时的故障现场，快速了解出现网络异常和网络性能问题的原因，快速确定故障域。

同时快速了解XX省农信社整个交易的性能状况，及时发现可能存在的问题，预警可能出现的性能问题，主动进行交易系统的应用性能管理，避免不必要的用户投诉。

当用户出现应用投诉时，能够及时利用这套监控方法重现用户投诉时的故障现场，及时发现出现用户投诉时的客户的访问行为，分析并确认客户投诉的根本原因，提升客户满意度和交易系统的应用性能。

根据XX省农信社的要求，本次Opnet提供的测试设备为ARX3700，ARX3700监控采用非侵入式的监控方式，通过交换机端口镜像的方式在网络上进行流量采集实现端到端的应用性能分析和故障定位。

并通过ATX深度分析确认出现故障原因的根本原因------如客户端、网络、服务器还是服务器上的页面处理慢、应用交互次数多等。

ARX/ATX提供了业界最优秀的最终用户体验监控与预警、应用等级SLA监控、SLA违反预警、应用性能瓶颈定位、应用性能问题根源分析、未知/异常流量发现、流量成分分析、流量流向分析、及应用预部署仿真系统，保障银行各项关键业务的运行通畅。

根据要求，测试要求达到下列目标：

●对于不同的业务交易提供实时的业务流量和业务性能变化的状况，快速了解是否已经出现应用性能瓶颈.

●提供业务系统整个流程流量原始裸数据包保存，能够保证快速提取相关问题的原始数据包。

●对于WEB业务交易的性能变化状况和业务交易性能提供统计报告，包括交易的交易量，交易的响应时间，交易的4xx错误，交易5xx错误，慢的交易数量及页面的大小等参数，了解整个业务的交易情况.

●设置主动运维的报警，自动报警出现交易性能问题的交易，自动保存故障前5分钟的数据，方便运维人员及时提取相关的报警数据，回放故障现场的数据，确定故障的原因.

●针对投诉的客户能够重现客户当时访问的交易并提取客户投诉时间段的原始数据，根据原始数据进行客户投诉现场的分析确定客户投诉的原因.

●利用RTCC------响应时间组成图，快速确认响应时间延迟发生的部位，提供依据，对根本原因进行排查；

●提供自动化端到端诊断，包括瓶颈的发现、解决或优化建议；

●SLA服务质量------利用SLA服务水平，掌握各个不同的区域客户的运行状况，随时能够了解不同区域的用户的网络质量的变化和业务质量的变化状况，对随时出现故障的影响区域，进行有效的主动管理和故障分析及定位.

●网络整体服务质量------利用Networkperformance仪表板查看网络性能监控，查看网络上的延迟和重传，保证业务健康运行.

●网络上应用的分布状况及服务质量------了解整个系统应用流量和性能的变化趋势，了解整个系统的日常基准，随时自动追踪流量和性能变化，报警可能出现的网络攻击和异常的变化，主动进行分析和解决出现的异常，按天、周及月等时间跨度进行流量统计.

●服务器的服务质量------利用SlowServer-IP仪表板查看性能差的服务器（交易处理较慢的服务器IP地址）。

自动记录不同业务组中的服务器对外提供的服务质量，快速定位出现应用性能问题的服务器，及时解决问题，保证正常的业务服务。

如果出现用户投诉的现象，利用分析软件确定相应时间慢的瓶颈，确定优化的步骤和措施.

●网络异常攻击和蠕虫防病毒监控------利用Wormhunt仪表板（发现三次握手失败的连接），自动记录出现网络连接失败次数高的应用和通讯对。

了解网络上连接数的变化状况，避免由于网络攻击造成的对业务的影响，快速定位攻击的来源和对象，避免业务损失.

●网络线路延迟监控------利用HighNetworkLatency-IP仪表板（延迟比较长的IP），自动统计业务组的网络延迟，网络延迟最大的组为Internet，延迟最大的网络区域和IP，查找延迟大的原因，发现潜在的网络延迟区域，发现潜在的网络拥塞，主动进行相关的网络故障分析和故障排除，保证网络正常运行.

●网络丢包率监控------利用HighPacketLoss-IP仪表板（丢包较高的组别），可以看到各个子网的丢包变化状况。

查看网络上丢包状况，及时定位丢包率高的网络，修复出现的网络故障，保证业务健康运行.

●内置智能告警------利用内置的智能告警，自动识别异常告警和用户自定义的阀值，发现网络上出现异常的现象，主动进行网络上的故障分析和故障定位.

●事件驱动的数据采集和保存------利用RollingBuffer和事件驱动的网络全包数据采集能力，记录全部的数据全包和事件驱动的全包数据采集保存，方便客户进行事后的故障现场分析和故障定位.

3Opnet测试情况汇总

根据XX省农信社应用的特点及实际情况，分别在生产区域、广域网区域、网银区域依次部署ARX3700设备。

根据用户的要求，尽量不影响现有的应用和服务器性能状况，采用无代理监控的方式进行日常应用性能的监控。

ARX3700设备采用非侵入式、全透明的监控方式，是透过本身的监控端口，收集从核心交换机镜像的流量来实现，不需要在任何服务器安装代理服务。

此外，ARX3700设备配置一个10/100/1000电口，作为远程管理、登录监控界面时使用，并能实现带外管理。

因此，设备对网络不造成任何影响与干扰，安装时不中断网络，不对任何网络设备造成压力，也不造成任何延时，对网络及业务零影响，能够在一般的机房环境中正常执行监控工作。

ARX3700设备本身带有4个监控端口，当镜像的端口数量超过4个时可以采用流量聚合设备进行流量的合并，然后将合并后的流量接到流量监控设备上进行相关数据的分析和故障定位.。

监控设备的接入方式采用端口镜像的方式实现，镜像是由交换机的背板（backplane）进行。

因此，镜像完全不影响源镜像口所在的板卡，不影响目的镜像口所在的板卡，也不对有关的板卡造成额外压力或延时。

因为镜像是在背板进行，背板速度一般在100Gbps以上，因此，对设备本身的影响微不足道.

3.1生产区域

3.1.1网络质量监控

3.1.1.1网络总体性能监控

查看网络上总体性能的变化状况，了解各个部门的网络占用状况和应用性能的变化状况，制定合理的网络升级计划，保证业务健康运行。

设备安装上架并配置完成后，即可从ARX的监控界面中查看整体网络流量状态，可监控的参数包括包括吞吐量、RTT、丢包（入站、出站）、TCP数等指标。

如图发现9:

00-10:

00之间有较高的吞吐量，选中进行分析。

双击打开详细信息，深入分析得出，该时间段内吞吐量达到

3.1.1.2网络连接数监控

了解网络上连接数的变化状况，避免网络攻击，快速定位攻击的来源和对象，避免业务损失。

在ARX的管理界面中，可查看网络流量中的TCP连接状态，可TOP显示出连接数最频繁的ip通信对及通信端口、协议等信息。

利用Wormhunt仪表板（发现三次握手失败的连接），自动记录出现网络连接失败次数高的应用和通讯对。

3.1.1.3网络性能监控

查看网络上的延迟和重传，保证业务健康运行。

ARX的管理界面，可实时展示出，网络流量中，延迟最高的IP通信对，及应用的名称。

登录ARX的Console管理界面，利用Network performance仪表板（识别关于某个应用、组、IP等在ARX部署位置两边的网络延迟和重传）可以看到各个子网的网络性能变化状况。

利用RTT时间可以看到网络的服务质量的变化。

3.1.1.4网络带宽占用监控

了解网络上应用带宽的占用状况，合理分配网络资源，避免不必要的资源浪费，保证业务健康运行。

通过ARX的管理界面，实时展示出网络中，产生流量最大的IP通信对及使用的协议、端口信息。

登录ARX的Console管理界面，利用Bandwithhogs-ip仪表板（流量比较多的主机），自动记录流量大应用和流量大的通讯对。

3.1.2应用服务质量监控

3.1.2.1用户体验时间监控功能

了解系统一周内的变化状况，根据不同的交易时间设置交易响应时间的报警，获取交易故障时间的故障数据，便于事后的故障分析和故障定位，进行主动的事件管理和故障分析及故障解决。

对较为重要/频繁的应用进行定义。

定义完成后，即可在ARX的管理界面中，查看用户访问应用的性能状态。

登录ARX的Console管理界面，查看RCTT交易响应时间组成图，可以看到不同交易的响应时间分布状况。

3.1.2.1.1信管响应时间

在应用表格

中选择信管业务，然后点击RTCC

图标，产生信管业务的响应时间构成图。

3.1.2.1.2财管响应时间

在应用表格

中选择财管业务，然后点击RTCC

图标，产生财管业务的响应时间构成图。

3.1.2.2服务器响应时间监控

查看网络上响应时间慢的服务器，主动进行服务器故障的定位和排差，保证服务器提供正常的业务。

对服务器区的服务器进行定义后，即可在ARX的管理界面中，实时展示各服务器的响应性能状态。

利用Slowserver-ip仪表板（交易处理较慢的服务器IP地址），自动记录不同业务组中的服务器对外提供的服务质量，快速定位出现应用性能问题的服务器，及时解决问题保证正常的业务服务。

3.1.2.3应用性能监控

掌握网络上运行应用的变化状况，制定合理的网络应用服务质量，主动进行应用性能管理，避免不必要的客户投诉。

3.1.2.3.1关键业务-信管

3.1.2.3.2关键业务-财管

3.1.2.3.3网站性能分析

利用WebTransactionDashboard仪表板，自动统计流量大的前几个Web应用的性能状况，了解不同应用的性能变化状况.ARX的管理界面可在一个界面中展示，当应用响应异常如应用出现大量HTTP500报错时，主动发出告警。

利用WebTransactionDashboard仪表板，自动统计流量大的前几个Web应用的性能状况，了解不同应用的性能变化状况.

最慢页面访问平均时间为2.217秒，网址为。

展开看每一次用户访问，最慢的一次访问发生在2013年6月26日上午11点13分36秒，用户ip地址为11.24.199.121，页面打开时间高达83.22秒。

对该用户的访问情况进行故障现场回放，利用AppTransactionXpert分析解码，可得网络传输占据了总时间的69.9%，

应用医生分析可得，潜在的瓶颈为，网络传输瓶颈，重传以及包乱序是导致时延较大的主要原因。

另外，外部网站部分网页有较多的HTTP400错误，集中在、等页面：

附：

常见的HTTP400s错误

401-访问被拒绝。

403-禁止访问

404-未找到

405-用来访问本页面的HTTP谓词不被允许（方法不被允许）

406-客户端浏览器不接受所请求页面的MIME类型。

407-要求进行代理身份验证。

412-前提条件失败。

413–请求实体太大。

414-请求URI太长。

415–不支持的媒体类型。

416–所请求的范围无法满足。

417–执行失败。

423–锁定的错误。

3.1.2.4未知应用监控

了解网路上还有哪些正在使用的端口和通讯对，记录和研究这些端口和通讯对，保障正常应用的带宽使用和性能.ARX设备的管理界面可显示出，网络中所有未知应用的IP通信、通信端口、流量大小等信息。

利用OtherApplicationDiscovery仪表板，自动记录网络未被定义的应用和通讯对，确认异常流量，剔除异常流量，避免不必要的资源浪费。

3.1.3故障深度分析功能

3.1.3.1用户行为重现

ARX与ATX结合使用，可以对较慢的应用进行深入解码分析：

上图中最长的延迟为30秒，执行的操作是：

Connection8:

11.32.122.39-->11.0.2.80（2frames）

POST/cognos8/cgi-bin/cognos.cgiHTTP/1.1Accept:

*/*Accept-Language:

zh-cnReferer:

http:

//11.0.2.80/cognos8/cgi-bin/cognos.cgiContent-Type:

application/x-www-form-urlencodedAccept-Encoding:

gzip,deflateUser-Agent:

Mozilla/4.0（compatible;MSIE6.0;WindowsNT5.1;SV1;.NETCLR2.0.50727）Host:

11.0.2.80Content-Length:

2681Connection:

Keep-AliveCache-Control:

no-cacheCookie:

cam_passport=101:

a9466f11-f92a-9698-abd1-8a776fd19214:

18446744070027857162;cea-ssa=false;usersessionid=AQgAAAAKgNNRAAAAAAoAAAByIvvHNEodoBXjFAAAAIwKzgPREHb9ysXTZnsSMzDrE9+7FAAAAAbv2L3N+asxI5vFUP1cyGwCl/M4;CRN=listViewSeparator%3Dnone%26showOptionSummary%3Dtrue%26contentLocale%3Dzh-cn%26displayMode%3Dlist%26format%3DHTML%26showWelcomePage%3Dtrue%26skin%3Dcorporate%26automaticPageRefresh%3D30%26productLocale%3Dzh-cn%26linesPerPage%3D15%26timeZoneID%3DAsia%252FShanghai%26columnsPerPage%3D3%26showHiddenObjects%3Dfalse%26useAccessibilityFeatures%3Dfalse%26;userCapabilities=d%3B8f0700fa%26ARQAAACMCs4D0RB2%2FcrF02Z7EjMw6xPfu%2Fh5dbRAvYoly5avzEsTVpoDVVtr;cc_session=s_cc:

|s_conf:

na|s_sch:

td|s_hd:

sa|s_serv:

na|s_disp:

na|s_set:

|s_dep:

na|s_dir:

na|s_sms:

dd|s_ct:

sa|s_cs:

sa|s_so:

sa|e_hp:

CAMID（*22CBS*3au*3aadmin90603*22）|e_proot:

*e5*85*ac*e5*85*b1*e6*96*87*e4*bb*b6*e5*a4*b9|prootid:

i27EA3A4AE2E241278C52DFF12459DB3F|e_mroot:

*e6*88*91*e7*9a*84*e6*96*87*e4*bb*b6*e5*a4*b9|mrootid:

i7CAEC246686C4EC69C6B420B052A5350|e_mrootpath:

CAMID（*22CBS*3au*3aadmin90603*22）*2ffolder*5b*40name*3d*27*e6*88*91*e7*9a*84*e6*96*87*e4*bb*b6*e5*a4*b9*27*5d|e_user:

admin90603|cl:

zh-cn|dcid:

i27EA3A4AE2E241278C52DFF12459DB3F|show_logon:

true|uig:

|ui:

h1h2h3t4|write:

true|eom:

0|pp:

18446744070027857162;cogbktbsug_cctab=mtoc

我们可以重现图片为如下，这样，就知道用户当时产生的页面响应时延高达30秒的原因，最大限度的还原了故障现场，并找到了影响性能的根因，客户端请求一个cognos.cgi的文件，文件打开是一个代码包，如下

当然，为了保证用户信息的私密，我们也可以采取只采集数据包头，不采集payload信息，以及提供抓包数据库的访问权限密码控制等方式，确保用户信息不被泄漏。

3.1.3.2响应时延构成图

当应用系统出现性能问题时，管理员最希望知道的就是时延发生在哪里？

而响应时延构成图则是回答这个最关键问题。

可在ARX管理界面中，针对用户关心的服务器进行流量和性能分析：

3.1.3.3应用瓶颈自动分析

ATX可自动对故障现场的数据包进行分析，并直接指出性能瓶颈所在。

可在ARX管理界面中，找出异常的IP通信对，如时延较高的IP通信对，并通过ATX的应用引擎，找出其瓶颈所在。

用ATX打开故障现场数据并点击应用医生按钮，之后即可查看瓶劲分析报告。

本次测试中发现10.150.60.12和10.150.180.93的响应时间达到12.3秒，系统自动把响应时间分解成客户端时间、网络传送时间和服务器处理时间，图中看到大部分时间花在10.150.180.93。

3.1.3.4中文故障报告自动生成

故障解决后，需要完成故障报告。

ATX在打开故障现场数据包后，可自动生成详细的中文故障分析报告，该报告支持内容的自定制，可自己选择报告需要写入的内容，报告的格式支持word、html等多种格式。

在分析异常的数据后，可通过ATX软件自动产生中文的故障分析报告。

用ATX打开任意故障现场数据后即可生成中文报告。

3.1.4异常流量分析

3.1.4.1流量分布分析

通过关键业务监控视图，可以看到宁德、泉州、省联社有使用稽核系统业务，可以看到宁德使用稽核系统的流量大小，响应时间等信息：

3.1.4.2流量分析

3.1.4.2.1泉州流量分析

地址段为11.24.0.0-11.27.255.255的终端，从2013-06-2714:

21到2013-06-2715:

21的流量分布：

3.1.4.2.2宁德流量分析

3.2广域网区域

3.2.1网络质量监控

3.2.1.1网络总体性能监控

以下为从7月11日从7月18日广域网区域一周的流量情况：

3.2.1.2网络连接数监控

以下为从7月11日从7月18日广域网区域一周各业务组TCP握手连接失败的情况：

2张图对比可以看出在宁德业务组主要的TCP三次握手失败是发生在宁德业务组连接Microsoft-DS（445CIFS文件共享）应用，由于三次握手未完成，故而无法看到连接的对端IP。

以宁德非资金业务组连接Microsoft-DS（445CIFS文件共享）应用为例：

以其中一个IP为例：

截取其中2013年7月18日8:

00-18:

00的数据包进行分析：

均为该IP发送SYN包，而对端IP未应答：

3.2.1.3网络性能监控

以下为从7月11日从7月18日广域网区域一周各业务组网络上的延迟和重传情况：

3.2.1.4网络带宽占用监控

以下为从7月11日从7月18日广域网区域一周各业务组的流量情况：

3.2.2应用服务质量监控

3.2.2.1用户体验时间监控功能

针对主要业务设置交易响应时间的报警，获取交易故障时间的故障数据，便于事后的故障分析和故障定位，进行主动的事件管理和故障分析及故障解决。

对较为重要/频繁的应用进行定义（设置为KeyApplication）。

3.2.2.1.1自助终端响应时间

3.2.2.2服务器响应时间监控

以下为从7月11日从7月18日广域网区域一周各业务组的服务器响应时间情况：

3.2.2.3应用性能监控

掌握网络上运行应用的变化状况，制定合理的网络应用服务质量，主动进行应用性能管理，避免不必要的客户投诉。

3.2.2.3.1关键业务-自助终端前置

3.2.2.3.2关键业务-信管

3.2.2.3.3关键业务-新反洗钱

3.2.2.3.4关键业务-国际结算系统

3.3网银区域

3.3.1网络质量监控

3.3.1.1网络总体性能监控

以下为从7月19日从7月25日网银区域一周的流量情况：

3.3.1.2网络连接数监控

以下为7月25日16:

05-17:

05网银各业务组TCP握手连接失败的情况：

其中一个外网客户端120.33.96.26连接失败情况：

3.3.1.3网络性能监控

以下为从7月19日从7月25日网银区域一周各业务组网络上的延迟和重传情况：

3.3.1.4网络带宽占用监控

以下为从7月19日从7月25日网银区域一周各业务组的流量情况：

3.3.2应用服务质量监控

3.3.2.1用户体验时间监控功能

针对主要