“天旦教你读懂三大性能监控流派的区别”

不同的数据收集方法得到的数据类型和颗粒度不同，不同的数据源可以分解析出的指标类型也不同。 不同的数据收集方法产生了不同的性能监测流派。 其中具有代表性的流派有三个，分别是日志、代理、互联网流量的分解。 今天，我们来谈谈这三种绩效监控类型的区别。

三大性能监控流派分别是如何收集数据的？

日志类型:日志类的数据源有两种，一种是以前传递到物理设备的日志文件，该日志文件可以提供的数据样式、数据精细度、数据副本都是每个设备制造商预先设定的。 另一个是在程序开发过程中或之后，为了捕捉程序或系统自身的运行新闻而开发的日志系统。 日志系统本身并不是主动访问应用程序，只是随着程序的执行发送相关的执行数据，大部分日志系统发送的是机器本身或程序运行状态的新闻。

代理流程:代理通常通过在安装了应用程序的服务器上部署适当的插件或在程序中嵌入适当的代码来获取数据。 代理获取数据的方法是主动获取数据。 由于代理部署在服务器内部，可以主动检测应用程序，因此代理方法可以获取许多程序的底层执行数据，并越来越多地反映代码级程序的执行情况。

internet流量分解方法:通过交换机镜像获取在数据中心内业务系统的各个组件之间交换的数据包，即internet流量数据。 交换机镜像是当前所有商用交换机的标准功能，可以复制和发送交换机发送的数据。 数据包发送到分解服务器后，可以通过分析数据包来达到业务性能监控的目的。

三大性能监视流派综合对象

在此，从部署周期、数据完整性、对应用程序的影响、风险、可扩展性等几个维度，综合考虑三个性能监视类别，简单了解各自性能监视类别的优缺点，根据具体情况进行适当分析

部署周期:日志系统和代理的部署周期长于时间，通常以年或月为单位。 另一方面，互联网流量的分解周期相对较短，通常是每周或每月。

数据完整性:代理模式无法在以前传递的物理设备(如交换机、路由器、防火墙和负载均衡)上安装适当的插件和代码，因此数据完整性有限。

日志系统对代理人很全面，但也有死角。 例如，在证券集中交易系统中，通信服务器kcxp作为通信中间件发挥作用，数据没有落入该节点，因此通过日志等监视方法无法在该节点收集各交易的详细数据。 例如，证券超高速交易系统不会开启记录功能以追求性能的最大化。

与日志系统和代理相比，互联网流量分解在数据的全面性方面更加普遍适用。

应用程序影响和风险:日志系统和代理系统会占用大量主机资源，存在兼容性风险。

用于分解互联网流量的旁路扫描方法不需要改变现有的互联网架构，也不需要对现有的业务系统进行改变。 可以说这不会影响应用系统本身，所以风险为零，适合重要的业务系统和核心服务器等重要的系统。

可扩展性:日志系统和代理系统的扩展难度较大，通常涉及二次开发； 互联网流量的分解只需要对新访问的数据包进行分解就可以实现。 这是因为全面向前兼容。

gartner :互联网数据在it可用性和性能管理中起着重要的作用

综上所述，互联网流量分解在部署周期、可扩展性、数据全面性等方面具有比较特点，用于天旦性能监测的就是这种数据采集方法。

从创立之初，天旦就明白互联网数据的重要性，独创地通过加工互联网数据，转化为高价值的互联数据，应用于业务性能监控、互联网性能监控等行业。

独特的是，gartner还关注互联网数据的应用价值，去年宣布，未来五年，互联网数据将在it可用性和性能管理中扮演非常重要的角色。 凭借过硬的技术实力和在业界的突出业绩，天旦成为唯一入选gartner性能分解行业最酷制造商报告《Coolvendorinperformance Analysis，》的中国公司。

根据gartner的报告，天旦的产品利用互联网数据提供多层相关的能力。 这样，天旦的产品就可以通过面向服务的性能管理和分解、故障定位、报告来实现体现性能的重要指标。

与之前流传的应用性能监控工具不同，基于互联网流量分解的天旦业务性能监控产品bpc关注业务量、业务动向、业务成功与失败情况等。 也就是说，从业务的角度关注业务的顺利运行； 应用监控关注的是系统和应用的运行情况等，虽然两者的关注点不同，但最终的目的是保障业务的顺利运行。

例:一种故障场景，三种技术流派不同的排障表现

那么，对于同样的运输故障，这三个流派是如何监控的呢？ 让我给你举个实际的例子。

一家保险企业的核心服务器瘫痪，故障排除后发现，互联网大厅导致了核心系统的高度和访问。 通常，客户开始交易时，从f5到web、f5再到核心，收到的对应交易数量也应该是1个。 但是，顾客提交交易时，核心呼叫数量达到了2~5起。

当时，应用程序部门配备了日志和代理工具。 在这两个工具中，从web发布的一个事务在成为核心服务后变成了2~5个。 因此，应用部的评价问题出在互联网部门。

但是，从技术角度来说，f5做的只是从左手到右手的传输工作，绝对不能制作拷贝。 互联网部困惑地发现了当时在这家保险公司进行poc测试的天旦bpc技术人员，想通过bpc看看发生了什么。

根据bpc的说法，从web到f5的交易数量确实是2-5件，问题的来源是web服务器。 另外，bpc发现，web端发送的2-5件没有响应，各自的间隔时间固定为300秒。

丰富的经验表明，天旦技术人员很快请互联网部调查f5的tcp超时限制时间，发现超时设定确实为300秒。 也就是说，如果在发出请求后300秒内没有响应，系统将自动重复启动。

为什么开始的交易会超时呢？ 为了进一步验证问题，技术人员将问题交易的交易编号输入日志管理系统，发现该业务在核心服务器上运行的时间为12分钟，远远超过300秒。 也就是说，这笔交易从开始的时候就注定了无法完成。

为什么交易不响应会重复开始呢？ 具体是谁送的？ 在web应用程序的基础上，有一个Java http客户端小程序，它通过互联网发出封装在应用程序中的请求。 如果发出的请求异常中断，该程序的默认设置将重试。 因为，每次事务请求超时300秒而异常中断时，程序都会再次发出请求，最终破坏核心服务。

基于bpc提供的数据观察，天旦技术人员最终恢复了故障形成过程:

1、应用服务器发出了交易要求，但交易所需的执行时间为12分钟，因此设定为比f5超时时间长300秒，交易被中断

2、应用服务器下级的Java http客户端小程序重新发出事务请求

3、交易再次超时，异常中断

4、Java http客户端再次重试

在实际的业务性能监测中，基于互联网流量分解的bpc关注的是应用和其他组件、应用和应用之间的数据交换，即各个环节之间发生了什么。 因此，通过日志和代理工具可以看到看不到的地方，为故障诊断提供了越来越多的参考数据。

本文：《“天旦教你读懂三大性能监控流派的区别”》