一文读懂三大性能监控流派的区别

Posted 2022-01-14 程序员二黑

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

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

日志、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关注的是业务量、业务走势、业务成功与失败情况等，即从业务视角出发，关注业务的平稳运行；而应用性能监控关注的是系统和应用的运行状况等，虽然两者的关注点不同，但是最终的目的都是为了保障业务的平稳运行。

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

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

故障现象：

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

当时应用部门配备了日志和Agent工具，通过这两个工具看到，从Web发出的1笔交易，到了核心服务器变成了2-5笔。因此，应用部判断问题出在网络部门。

但从技术角度来讲，F5所做的只是从左手到右手的转发工作，永远不可能做复制。网络部百思不解之下，便找到天旦客户服务人员，希望能够通过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秒超时异常中断后，该程序就会再次发出请求，直到最终将核心服务器拖垮。

现在就有这么一个机会，我邀请你进入我们的软件测试学习交流群：642830685，备注“csdn”大家可以一起探讨交流软件测试，共同学习软件测试技术、面试等软件测试方方面面，还会有免费直播课，收获更多测试技巧，我们一起进阶Python自动化测试/测试开发，走向高薪之路。

送给大家一句话，共勉：当我们能力不足的时候，首先要做的是内修！当我们能力足够强大的时候，就可以外寻了！

最后也为大家准备了一份配套的学习资源，你能在 公众号：【程序员二黑】免费获取一份216页软件测试工程师面试宝典文档资料。以及相对应的视频学习教程免费分享！，其中资料包括了有基础知识、Linux必备、Shell、互联网程序原理、mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。

往期回顾：

在职阿里6年，一个29岁女软件测试工程师的心声

公司新来的阿里p8，看了我做的APP和接口测试，甩给了我这份文档…

腾讯二面：web测试问题被虐哭了，直到学长给了我这些知识点…