Fluke Networks:ERP 应用问题的快速诊断

壹佰电子仪器

    在一个企业里，大部分的应用问题都是由用户提出的，这是因为对于应用质量一直都没有一个好方法来评估，光是对流量监测已经不能判别应用运行时的性能。 应用监测是一个比较新的网络性能监测手段，他通过长期监测，组成智能基线，方便分割应用问题的源头。以下是一个通过应用分析，对用户投诉ERP系统出现问题时，诊断时的流程实例：
    第一：问题是什么？
    一个ERP 系统可以由多层的服务器来支持。在出现问题时，需要知道问题是在哪一层。应用性能监测仪如福禄克网络公司的SuperAgent 可以可以同时监测多层应用的性能。在图一上，可以看到ERP 的问题，只发生在ERP System 应用上(用户界面)，与其它应用无关。
    第二：确认是网络、服务器还是应用出毛病呢？
    这么一个简单的问题，却可能由于各个维护小组相互指责，引起浪费时间。SuperAgent的响应时间构成图，可以清楚的提供实际的证据，证明是哪一方的问题。在图二，绿色代表网络往返时间（Netwk RTT）,深蓝色代表平均的重发报时间（Retran），金色代表数据传输或网页下载时间（Data Xfer）, 红色是服务器响应时间（Srv Resp）和浅蓝色的TCP 连接建立时间（Conn Time）。 在图上可以看到在出事时9：10 左右，总响应时间是4 秒种，服务器的响应时间特长是主要原因。我们可以深入分析每一个响应时间的部件。在图三，可以看到在过去8 小时，服务器响应时间的中间值（50% percentile）是0.12 秒,平均值是0.24 秒。但出毛病时响应时间长达3 秒，增加了30 倍。要留意的是SuperAgent和大部分长期监测工具的报告都是平均值（5 分钟），所以可能只是有小量的长响应时间，影响这平均值结果，要找出根源，需要进一步确认。
    第三：问题有意义吗（有多小有问题的情况）
    究竟有很多的应用对话受影响呢？在图三上的灰色线代表SuperAgent 在计算平均值时，用上的测试个数数量。通过这灰色线，可以明确的显示问题是否由于应用率改变，影响响应时间的统计结果。如果测试个数数量在出问题前或同时突然增加，很有可能是网络资源甬塞或冲突。 如果测试个数数量大量减低，应用的衰减可能改变了正常的应用模式，也要可能只一些小的响应时间衰退，例如在3:00am，只有一个用户，他的对话比较慢，是否值得探讨呢？为了了解正常的应用模式，SuperAgent 提供4 个不同的分析时间模板的趋势图：8 小时，一天，一周和一个月。这样让您很容易看到出问题时比正常的情况是超过还是低于，而且是否会定期发生。在我们的案例上，
    第四：问题严重吗
    有多小应用对话受影响呢？SuperAgent 提供统计分析，可以提供每一个影响响应时间部分的90 百分点，75 百分点和50 百分点情况。如果在90 个百分点没有响应时间的增加，代表只有不超过10%的对话受影响。如果75 百分点又突然增加，但50 百分点却没有，哪是25%-50%的对话受影响。在图四上，我们看到ERP 的50 百分点图。服务器响应时间（红色曲线）有明显的增高，这代表超过50%的对话的性能受影响 – 一个严重、需要立刻处理的问题。
    第五：问题的范围
    了解影响范围有多广，只有一个服务器受影响？还是影响多个服务器？SuperAgent 的性能图可以提供很有效的分析。在图五上，可以方便的看到每一个服务器个别的服务器响应时间，我们看到其中两个被SuperAgent监测的服务器的响应时间都是很长，着代表这两个服务器组都有问题，而不是单一个的服务器。另外，服务器间的响应时间差异不小，如果服务器间有基于响应时间实现负载平衡的设备的话，这设备的效能可能有问题。

    第六：其他的分析

    一些其它的分析数据，可以加速故障诊断，如流量统计、进程报告，QoS,和响应数据大小等。

    总结：
    对于多层ERP 应用，通过监测应用性能，很快便可分割出问题出在ERP 的用户界面，与其他后台应用层无关,这比动态应用性能测试方便得多。而且通过应用响应时间的分析,可以定位在服务器上。然后证实问题是严重的，而且影响大.问题不是在某一个服务器，而是其中两个ERP 服务器组。在深入了解时，发觉问题的原因不是由于用户太多,也不是对话太多,初步怀疑是负载平衡设备的问题。这些数据都是可以提交给相关的部门来处理的和做更深入的分析。回想一下如果没有如SuperAgent这样的应用响应监测工具，您会用什么方法、时间来解决这个ERP 的问题呢？


该贴已经同步到 壹佰电子仪器的微博