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

不同数据采集方式获得的数据类型和颗粒度是不同的，不同的数据源能够分析出的指标类型也是不同。根据数据采集方式的不同，便产生了不同的性能监控流派。其中较有代表性的流派有三个，分别是：日志、Agent和网络流量分析。今天，我们就来聊一聊这三大性能监控流派有什么不同？

日志、Agent和网络流量分析流派分别是如何采集数据的？

日志流派：日志类的数据来源有两类，一种是传统物理设备上的日志文件，这种日志文件能够提供的数据格式、数据精细度、数据内容都是各个设备厂商预先设定的。另外一种是程序开发过程之中或之后，为捕获程序或者系统本身的运行信息开发出来的日志系统。日志系统本身不对应用程序发起主动式访问，只是伴随着程序的运行，将相关的运行数据输送出来，大部分日志系统输送出来的都是机器本身或者程序运行的状态信息。

Agent流派：Agent一般通过在装有应用程序的服务器上面部署相应插件或者在程序中植入相应代码的方式获取数据。Agent获取数据的方式是主动取数。由于Agent部署在服务器内部，并且可以主动探测应用程序，所以Agent方式能够获取到很多程序底层运行的数据，更多的是反应了代码级别的程序运行状况。

网络流量分析流派：即通过交换机镜像的方式获取数据中心内部业务系统各组件之间交互的数据包，即网络流量数据。交换机镜像是目前所有商用交换机都具备的标准功能，它可以将交换机上传输的数据复制一份送出来。数据包送到分析服务器之后，通过对数据包的解析便可以达到业务性能监控的目的。

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

下面我们将从部署周期、数据全面性、对应用的影响、风险性、扩展性等几个维度，对三大性能监控流派进行综合对比，帮助大家简单了解各个性能监控流派的优缺点，以便根据自身情况选取适合的性能监控工具。

部署周期：日志系统和Agent部署周期都比较长，一般以年或月为单位，而网络流量分析周期相对比较短，一般以周或月为单位；

数据全面性：日志系统相对较全面，但也存在一定盲区，例如证券集中交易系统中，通讯服务器KCXP作为通讯中间件，数据在这个节点并没有落地，导致日志等监控方式无法在这个节点采集到每一笔交易的细节数据。再比如，证券极速交易系统为了追求性能最大化通常不会开启日志功能。

Agent模式由于无法在交换机、路由器、防火墙、负载均衡等传统物理设备上安装相应插件或代码，所以数据全面性有所局限；

网络流量分析则相对更加全面一些。

对应用的影响和风险性：日志系统和Agent系统需要占用较多的主机资源，而且有一定的兼容性风险。

而网络流量分析所采用的旁路抓包方式，不需要改变现有的网络架构、不需要对现有的业务系统进行变更，因此不会影响应用系统本身，可以说是零风险的，更适用于关键业务系统、核心服务器等重要系统。

扩展性：日志系统和Agent系统扩展的难度较大，一般都会涉及到二次开发；而网络流量分析只需对新接入的数据包进行分析即可实现，因此是全面向前兼容的。

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

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

自创立之初，天旦就理解到网络数据的重要性，开创性地通过对网络数据进行加工，转换成高价值的互联数据，进而应用在业务性能监控、网络性能监控等领域。

无独有偶，Gartner对于网络数据的应用价值也十分看好，曾在2016年发表观点称，未来 5 年，网络数据将在 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小程序重新发出交易请求（JAVA HTTP CLIENT小程序负责将APP封装好的请求通过网络发出去，该程序的默认配置是只要发出的请求被异常中断就会retry重试）。

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

4、JAVA HTTP CLIENT再次retry

……

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

更多文章详见：http://www.magedu.com/xwzx/linuxxx