Agent VS 网络数据，云中业务性能监控有何不同？

首页

CLOUD

by Netis | Jun 17, 2021

“大流行证实了云的价值主张。” “使用按需，可扩展的云模型来实现成本效益和业务连续性的能力，为组织快速推动其数字业务转型计划提供了动力。公共云服务使用的增加使云的采用比以往任何时候都更加成为“新常态”。”

——Gartner《2021年十大云计算趋势报告》

云中业务运维难题

为降本增效，促进业务发展，实现数字化转型，越来越多的企业将业务迁移至云上。上云后，鉴于云环境内网络与业务架构的模糊性，业务服务节点从传统物理环境下的百级上升至万级甚至百万级，运维管理难度可想而知。同时，随着运维管理规模的增加，业务系统的连续性必须保持稳定，且强监管需求不降反增，运维人员的配置未能跟上业务上云的脚步，业务稳定性难以保障。

无论是云环境还是传统物理环境，保障业务连续性、可用性、稳定性都是运维的核心价值与意义。云时代，企业的IT环境变得异常复杂，从跨越物理环境与云环境到跨越公有云与私有云，尽管云供应商可以为企业提供部分基础设施的监管与维护，但仍需要运维进行业务系统监控、业务故障恢复等性能管理工作。因此，构建云中业务性能监控体系，保障云中应用可靠性与运行质量成为运维部门的工作难点。

云中业务性能监控，Agent VS 网络数据

目前，市场上主流的云应用性能监控方案主要基于两种技术方式：一类是基于Agent（即插码）的技术实现形式，包括Skywalking、Jaeger、Zipkin等开源工具，以及一些商用软件。目前官方有两种部署方式：一是DaemonSet方式；二是Sidecar方式。Agent采用全自动探针或者手动探针对中间件、Open Tracing组件甚至是私有化组件进行监控，除部分软件工具（Skywalking）使用字节流等方式外，均需要在服务器上进行部署或者在代码中嵌入SDK。在Agent之外，还有另一类基于网络数据（网络流量）的技术实现形式，通过采用VM微探针或虚拟探针的方式，同时兼容公有云与私有云，对容器内的网络流量实现无侵入的实时转发，实现低开销、高性能的网络流量捕获，对云环境实现无感式监控。

Agent，自下而上式的云中应用性能监控

基于Agent的技术方案主要监测代码间的调用关系与时延，可以看到代码层面的应用节点，因此获取的应用指标偏底层。在进行业务性能监控时，试图通过聚合值发现底层错误或故障，将问题指标在影响到上层应用之前提前定位。但是，在实际操作中面临两大考验：

云环境中，底层基础设施与服务器之间存在异常分配，譬如资源共享不稳定导致监控服务器异常复杂等；
云环境中，一个应用由多个组件构成，需要监控越来越多的模块，在实际监控场景中将这些信息关联并找到根源非常困难。

此外，基于agent的分布式链路追踪所调取的Metrics指标也是基于服务器等底层架构，当底层数据产生异常告警时，很难通过分析快速定位到受影响的业务应用。

网络数据，自上而下式的云中应用性能监控

基于网络数据的技术方案主要监测业务的应用节点与部分网络节点，可以看到业务的应用层指标，譬如交易量、响应率、成功率等，因此获取的应用指标直接反映了业务的健康度。在进行业务性能监控时，通过监控上层聚合数据，从顶层的业务问题出发深入钻取底层指标。该方式在实际操作中同样面临以下挑战：

为防止在系统层面出现问题进而影响用户体验，分布式系统可能会内置容错机制延时故障和错误，因此需要通过技术手段实现智能化的故障定位，直接锁定故障根因；
从发生故障到扩散至整个系统可能会经历较长的时间间隔，当注意到上层故障时可能为时已晚，因此需要通过实时的监测机制控制延迟。

即时的故障告警与定位对云中业务性能监控十分重要。由于当前云环境基本都采用微服务架构，当众多的微服务交织在一起时，故障定位就变得棘手。因此，无论是基于Agent还是基于网络数据的技术方案基本都采用分布式架构，通过对分布式调用链进行追踪，及时分析性能状况，可以快速定位与解决故障。

分布式链路追踪体系里有三个重要的概念，即Metrics、Tracing与Logging。Metrics即指标，主要反映组件实时状况与健康度；Tracing 即链路，反映单次请求范围内如何处理信息；Logging即日志，反映离散的事件或过程。在云性能监控领域，tracing通常作为优化系统、排查问题的高阶方法，logging被视为排障的主要依据。由于agent是一个网络守护进程，监听通过UDP发送过来的spans并将其批量送给collector，因此基于Agent的监控方案更偏向于通过Tracing的形式进行链路追踪，而基于网络数据的监控方案更偏向于通过Metrics进行故障反馈；通过Tracing模式可以查找到链路上出现问题的环节，通过查日志可以定位系统问题，并不意味着Metrcis监控的有效程度最低。相反，实时的监控机制、智能的告警配置同样可以快速定位故障根因。

（Metrics、Tracing、Logging三者间的关系示意图）

此外，由于底层应用数据的告警量往往很大，且存在海量误告等状况，从底层应用数据指标推演受影响的业务难度极大，因此基于Agent的技术方案在进行业务性能监控时，很难快速感知业务实时运行过程中的异动；而上层应用数据与业务应用高度关联，譬如响应率、及时率、成功率等指标直接呈现业务运行连续性，运维人员可快速感知业务的实时运行状态。

基于网络数据的性能监控，白盒监控与黑盒监控双管齐下

应用性能监控按照不同维度的应用指标与监控意图可以划分为：白盒监控与黑盒监控。白盒监控主要关注原因，通过暴露系统内部的相关指标了解系统内部的实际运行状态，自下而上式的监控可以直接预判问题根因；而黑盒监控主要关注现象，自上而下式的监控在系统或者服务发生故障时快速告警，通知运维人员进行处理，及时排障。在以业务为核心的运维体系架构中，业务性能监控更侧重于黑盒监控。

由于云环境应用系统监控的目标是提供对复杂信息系统的全面监控，反映云资源池的健康状况与可用性，构建一个可控、可预测的云环境，支持云业务安全、稳定、高效、持续运行。因此，为及时掌握系统资源现状与运行信息，业务性能监控在做好黑盒监控的基础上，也需要具备白盒监控的能力。

云计算通过云平台与虚拟化技术实现资源池统一化管理，在支持自服务与资源弹性伸缩的同时也给云中的流量采集带了新的挑战。流量采集作为监控的前提，与生产网络一样，其准确性、稳定性与可靠性直接影响黑、白盒监控的分析结果：

在传统网络环境下，网络流量采集主要通过交换机镜像和分光器的方式进行全量、实时、精准的采集；在云环境下，同一物理机不同虚机之间的业务交互的东西流量不再经过网络物理交换机，而将面临虚机监控的缺失；
云环境里计算、存储、网络等物理资源被池化和虚拟化，云中的虚机上下线、扩容、迁移、切换等均需通过自动化实现，镜像策略无法随虚机的切换实现同步部署。

因此，基于云平台的动态性特点，云环境下的流量采集势必要突破传统交换机镜像的方式，通过灵活、自动化采集和监控部署，实现虚拟机间东西向流量的采集，并加强过载保护机制做到对服务器无感或最小感知。

基于网络数据的业务性能监控技术通过虚拟交换机利用微探针或SDN引流的方式，实现全流量、实时、精准的跨多云网络环境、多网络区域的采集，通过自动化部署、集中管控采集器，动态感知云中流量资源和业务应用资源的变更联动，并通过云上、云下一体化的全链路监控体系实现对业务应用“黑盒监控”，动态感知交易量等业务指标的异动；通过搭建智能化的故障告警与定位系统，定位业务故障根因，实现应用性能的“白盒监控”。

天旦业务性能管理BPC基于网络数据，通过安全可靠的采集技术实现跨多云环境的流量采集，同时支持分布式架构和集中管控，实现云上、云下一体化的全链路业务性能监控，被客户誉为“业务监控状态的第一感知源”。

– end –