 在上一期的专栏文章中，提到了NetScout“KPI-to-Flow-to-Packet”（简称KFP）分析方法，它遵循从KPI关键性能指标（比如应用响应时间或者错误），到应用数据流（比如利用率、会话、使用者排名），再到数据包解码细节（如果需要）逐步向下追踪的分析步骤，帮助企业IT部门快速发现和定位问题。那么本期专栏将给大家带来的是一个真实的KFP方法案例分析。
某银行的业务应用改造之后，网络管理部门注意到nGenius性能管理器发出很多KPI告警，显示在最近的时段发生了很多响应时间超过阈值的KPI事件。在此同时，他们也接到用户的投诉，说业务应用的网页响应速度很慢，几乎需要10多秒钟才能完成一个操作。
于是网管人员立即从KPI告警关联到Flow层，右键单击其中一个告警选择证据，果然验证了用户的投诉，服务器IP地址和HTTP应用类型完全符合用户投诉内容。
再点击告警证据，得到客户端与服务器之间的HTTP应用响应时间历史，注意到按照15分钟清晰度，HTTP应用的响应时间峰值达到了5.8秒，该通信对的峰值流量是600Kbps。
到此为止，我们已经在Flow的层面定位到通信对，并且发现了HTTP应用响应时间慢的现象，要进一步分析导致应用响应时间慢的原因，就需要再向下层关联到数据包层面解码分析。继续右键单击选择数据包分析和协议解码，即选出了这一个响应时间慢的会话对，接着继续选择跳动图表。
跳动图表展示了整个HTTP应用会话中数据包传输过程，其中Delta Time一列显示了每两个数据包之间的时间间隔，从上面的跳动图表中可以清晰的看到服务器得到一个HTTP POST请求之后作出响应，再返回数据包的间隔时间达到11.488秒，从而帮助我们定位到导致性能问题的HTTP应用层事件。
上面的案例展示了NetScout独特的KPI-to-Flow-to-Packet分析方法，从用户接收到KPI告警，再直接关联到Flow层面定位发生问题的通信对，再到数据包解码层面调查取证，最终找到问题的根源。可见，KPF方法在IT部门急需评估和诊断网络和应用问题时，为用户提供早期预警和深入的可视化分析能力，为实时故障诊断和迅速恢复服务提供了有力保障。
下一期中将介绍NetScout独创的K2早期预警平台在网络管理中发挥的重要作用。K2能够在web视图中根据定义的应用或者服务自动drill-down并且定位问题所在。
若有疑问，请联系jiangsuxiaj@sohu.com
|
