宝塔服务器面板，一键全能部署及管理，送你10850元礼包，点我领取

性能监控主要通过数据采集-数据分析-数据展示-故障报警来实现，其中数据采集是性能监控的第一步，也是最重要的一步。

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

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

日志类型：日志类的数据源有两种，一种是传统物理设备上的日志文件，该日志文件可以提供的数据格式、数据精细度、数据内容由各设备制造商预先设定。 另一个是在程序开发过程中或之后，为了捕获程序或系统自身的动作信息而开发的日志系统。 日志系统本身并不是主动访问APP，只是随着程序的执行发送相关的执行数据，大部分日志系统发送的是机器本身或程序执行的状态信息。

代理流程：代理通常通过在安装了APP的服务上部署适当的插件或在程序中嵌入适当的代码来获取数据。 代理获取数据的方法是主动获取数据。 由于代理部署在服务器内部，可以主动检测APP应用，所以代理方式经常可以获取许多程序的基础执行数据，反映了代码级程序的执行情况。

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

三大性能监控流派综合对比

在这里，从部署周期、数据完整性、对APP的影响、风险、可扩展性等几个维度，综合比较了三个性能监视类别，简单了解了各自性能监视类别的优缺点，并根据具体情况进行了相应的性能比较

部署周期：日志系统和代理的部署周期较长，以年或月为单位，网络流量分析周期较短，以周或月为单位。

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

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

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

对APP的影响和风险：日志系统和代理系统会消耗很多主机资源，存在兼容性风险。

网络流量分析采用的旁路方式不需要改变现有的网络架构或改变现有的业务系统，因此不影响APP系统本身，风险为零，重要的业务系统和核心服务器等重要服务器

可扩展性：日志系统和代理系统的扩展难度很大，一般来说，二次开发涉及的网络流量分析只需要分析新访问的数据包就可以实现，因此完全向前兼容。

Gartner：网络数据将在 IT 可用性和性能管理上发挥关键作用

综上所述，网络流量分析在部署周期、可扩展性、数据全面性等方面具有比较优势，天旦性能监测采用的就是这种数据采集方式。

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

虽然不是偶然的，但Gartner也关注互联网数据的应用价值。 2016年宣布，在未来五年，互联网数据将在IT可用性和性能管理中扮演非常重要的角色。 凭借过硬的技术实力和在这一领域的突出业绩，天旦成为唯一一家入选Gartner性能分析领域最酷厂商报告《Cool Vendor in Performance Analysis，2017》的中国企业。

根据Gartner的报告，天旦的产品利用网络数据提供了多层关联功能。 这样，天旦的产品就可以实现以服务为导向的绩效管理与分析、故障定位、通过报告实现绩效的重要指标。

与传

统应用性能监控工具不同，基于网络流量分析的天旦业务性能监控产品BPC关注的是业务量、业务走势、业务成功与失败情况等，即从业务视角出发，关注业务的平稳运行；而应用性的监控关注的是系统和应用的运行状况等，虽然两者的关注点不同，但是最终的目的都是为了保障业务的平稳运行。

案例：一种故障场景，3种技术流派的不同排障表现

那么，面对同一运维故障，这三大流派都是如何进行监控呢？下面与大家分享一个实际案例：

某保险公司核心服务器出现宕机，经排查发现是网厅触发核心系统高并访问所致。正常情况下，当用户发起一笔交易，从F5到WEB、F5再到核心，收到的对应交易数量应该也都是一笔。但当时情况是，当用户提交一笔交易，核心调用数量却高达2-5笔。

当时应用部门配备了日志和Agent工具，通过这两个工具看到，从WEB发出的1笔交易，到了核心服务器变成了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 CLIENT小程序，它负责将APP封装好的请求通过网络发出去，该程序的默认配置是只要发出的请求被异常中断就会retry（重试）。因此，每当交易请求300秒超时异常中断后，该程序就会再次发出请求，直到最终将核心服务器拖垮。

基于BPC提供的数据分析，天旦技术人员最终还原了故障形成过程：

1、应用服务器发出交易请求，由于交易所需执行时间为12分钟，大于F5超时时间设置300秒，交易被中断

2、应用服务器底层的JAVA HTTP CLIENT小程序重新发出交易请求

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

4、JAVA HTTP CLIENT再次retry……

在实际业务性能监控中，基于网络流量分析的BPC关注的是应用与其他组件、应用与应用之间的数据交互，即各环节之间究竟发生了什么。因而能够看到日志、Agent工具看不到的地方，为故障排查提供更多参考数据。

↓点击下方「了解更多」了解业务性能监控工具 BPC更多功能