APM 原理与框架

APM 原理与框架

三丰 soft张三丰

APM简介

随着微服务架构的流行，一次请求每每须要涉及到多个服务，所以服务性能监控和排查就变得更复杂：

不一样的服务可能由不一样的团队开发、甚至可能使用不一样的编程语言来实现 服务有可能布在了几千台服务器，横跨多个不一样的数据中心 所以，就须要一些能够帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，可以快速定位和解决问题，这就是APM系统，全称是（Application Performance Monitor，固然也有叫 Application Performance Management tools）

AMP最先是谷歌公开的论文提到的 Google Dapper。Dapper是Google生产环境下的分布式跟踪系统，自从Dapper发展成为一流的监控系统以后，给google的开发者和运维团队帮了大忙，因此谷歌公开论文分享了Dapper。

谷歌Dapper介绍

在google的首页页面，提交一个查询请求后，会经历什么：

•可能对上百台查询服务器发起了一个Web查询，每个查询都有本身的Index
•这个查询可能会被发送到多个的子系统，这些子系统分别用来处理广告、进行拼写检查或是查找一些像图片、视频或新闻这样的特殊结果
•根据每一个子系统的查询结果进行筛选，获得最终结果，最后汇总到页面上
•总结一下：
一次全局搜索有可能调用上千台服务器，涉及各类服务。用户对搜索的耗时是很敏感的，而任何一个子系统的低效都致使致使最终的搜索耗时 若是一次查询耗时不正常，工程师怎么来排查究竟是由哪一个服务调用形成的？

•首先，这个工程师可能没法准确的定位到此次全局搜索是调用了哪些服务，由于新的服务、乃至服务上的某个片断，都有可能在任什么时候间上过线或修改过，有多是面向用户功能，也有多是一些例如针对性能或安全认证方面的功能改进
•其次，你不能苛求这个工程师对全部参与此次全局搜索的服务都了如指掌，每个服务都有多是由不一样的团队开发或维护的
•再次，这些暴露出来的服务或服务器有可能同时还被其余客户端使用着，因此此次全局搜索的性能问题甚至有多是由其余应用形成的
从上面能够看出Dapper须要：

无所不在的部署，无所不在的重要性不言而喻，由于在使用跟踪系统的进行监控时，即使只有一小部分没被监控到，那么人们对这个系统是否是值得信任都会产生巨大的质疑 持续的监控

Dapper的三个具体设计目标

性能消耗低

APM组件服务的影响应该作到足够小。服务调用埋点自己会带来性能损耗，这就须要调用跟踪的低损耗，实际中还会经过配置采样率的方式，选择一部分请求去分析请求路径。在一些高度优化过的服务，即便一点点损耗也会很容易察觉到，并且有可能迫使在线服务的部署团队不得不将跟踪系统关停。

应用透明，也就是代码的侵入性小

即也做为业务组件，应当尽量少***或者无***其余业务系统，对于使用方透明，减小开发人员的负担。

对于应用的程序员来讲，是不须要知道有跟踪系统这回事的。若是一个跟踪系统想生效，就必须须要依赖应用的开发者主动配合，那么这个跟踪系统也太脆弱了，每每因为跟踪系统在应用中植入代码的bug或疏忽致使应用出问题，这样才是没法知足对跟踪系统“无所不在的部署”这个需求。

可扩展性

一个优秀的调用跟踪系统必须支持分布式部署，具有良好的可扩展性。可以支持的组件越多固然越好。或者提供便捷的插件开发API，对于一些没有监控到的组件，应用开发者也能够自行扩展。

数据的分析

数据的分析要快 ，分析的维度尽量多。跟踪系统能提供足够快的信息反馈，就能够对生产环境下的异常情况作出快速反应。分析的全面，可以避免二次开发。

Dapper的分布式跟踪原理

基本方法

例以下图这样的调用关系：

•黑盒方案：假定须要跟踪的除了上述信息以外没有额外的信息，这样使用统计回归技术来推断二者之间的关系。须要一些额外的数据来得到足够精度。
•基于标注的方案：依赖于应用程序或中间件明确地标记一个全局ID，从而链接每一条记录和发起者的请求。缺点是有代码***。

跟踪树和span

在Dapper跟踪树结构中，树节点是整个架构的基本单元，而每个节点又是对span的引用。节点之间的连线表示的span和它的父span直接的关系。虽然span在日志文件中只是简单的表明span的开始和结束时间，他们在整个树形结构中倒是相对独立的。这里span是跟踪术结构的基本单元，也表示一小段的时间。下图是5个span在Dapper跟踪树种短暂的关联关系

上图说明了span在一个大的跟踪过程当中是什么样的。Dapper记录了span名称，以及每一个span的ID和父ID，以重建在一次追踪过程当中不一样span之间的关系。若是一个span没有父ID被称为root span。全部span都挂在一个特定的跟踪上，也共用一个跟踪id（在图中未示出）。全部这些ID用全局惟一的64位整数标示。在一个典型的Dapper跟踪中，咱们但愿为每个RPC对应到一个单一的span上，并且每个额外的组件层都对应一个跟踪树型结构的层级。

上图给出了一个更详细的典型的Dapper跟踪span的记录点的视图。在图中这种某个span表述了两个“Helper.Call”的RPC(分别为server端和client端)。span的开始时间和结束时间，以及任何RPC的时间信息都经过Dapper在RPC组件库的植入记录下来。若是应用程序开发者选择在跟踪中增长他们本身的注释（如图中“foo”的注释）(业务数据)，这些信息也会和其余span信息同样记录下来。

埋点

1.追踪的上下文信息在ThreadLocal中进行存储。
2.当计算过程是延迟调用的或是异步的，google经过通用的控制流来回调，确保全部的回调能够存储此次跟踪的上下文信息。当回调函数被触发时，此次跟踪的上下文会与适当的线程关联上。在这种方式下，Dapper可使用trace ID和span ID来辅助构建异步调用的路径。
3.google的全部进程通讯是创建在一个RPC框架上。在RPC框架自己中来埋点从而定义全部span。
4.dapper容许用户在Dapper跟踪的过程当中添加额外的信息，以监控更高级别的系统行为，或帮助调试问题。咱们容许用户经过一个简单的API定义带时间戳的Annotation，核心的示例代码以下图所示。
5.dapper支持以下图的文本annotation也支持key-value映射的Annotation。如持续的计数器，二进制消息记录和在一个进程上跑着的任意的用户数据等。

跟踪收集

下图演示了Dapper收集管道：

由上图可知，Dapper的跟踪记录和收集管道的过程分为三个阶段: span数据写入本地日志文件中。而后Dapper的守护进程和收集组件把这些数据从生产环境的主机中拉出来 写到Dapper的Bigtable仓库中。一次跟踪被设计成Bigtable中的一行，每一列至关于一个span。Bigtable的支持稀疏表格布局正适合这种状况，由于每一次跟踪能够有任意多个span。Dapper还提供了一个API来简化访问咱们仓库中的跟踪数据。Google的开发人员用这个API，以构建通用和特定应用程序的分析工具。

APM组件选型

市面上的全链路监控理论模型大多都是借鉴Google Dapper论文，重点关注如下三种APM组件：

•Zipkin：由Twitter公司开源，开放源代码分布式的跟踪系统，用于收集服务的定时数据，以解决微服务架构中的延迟问题，包括：数据的收集、存储、查找和展示。
•Pinpoint：一款对Java编写的大规模分布式系统的APM工具，由韩国人开源的分布式跟踪组件。
•Skywalking：国产的优秀APM组件，是一个对JAVA分布式应用程序集群的业务运行状况进行追踪、告警和分析的系统。

对比项

主要对比项：

探针的性能

主要是agent对服务的吞吐量、CPU和内存的影响。微服务的规模和动态性使得数据收集的成本大幅度提升。

collector的可扩展性

可以水平扩展以便支持大规模服务器集群。

全面的调用链路数据分析

提供代码级别的可见性以便轻松定位失败点和瓶颈。

对于开发透明，容易开关

添加新功能而无需修改代码，容易启用或者禁用。

完整的调用链应用拓扑

自动检测应用拓扑，帮助你搞清楚应用的架构

如何采集数据

APM是经过采集探针采集应用数据的。采集探针是经过字节码加强技术进行埋点，生成调用数据。调用数据被采集代理ICAgent所获取并处理，而后上报并呈如今界面中。关系以下图所示：

采集哪些数据

APM仅采集应用的业务调用链数据、资源信息、资源属性、内存检测信息、调用请求的KPI数据，不涉及我的隐私数据。所采集的数据仅用于APM性能分析和故障诊断，不会用于其余商业目的。下表为数据采集范围和用途。

行业分析

目前APM市场在海外主要有两类的核心企业。一类是四大传统IT巨头（IBM、HP、CATechnologies、BMC），另外一类是ITOM市场新创企业，包括Dynatrace、NewRelic、AppDynamics、Splunk等。随着市场成熟度的不断提升，APM市场的市场格局与ITOM总体的市场格局同样，呈现初创企业加速发展，开始占据市场主导的市场趋势。

根据调查数据显示，NewRelic、AppDynamics以及Dynatrace做为新创企业依旧保持在APM市场的领导者象限，这三家公司是当前全球APM市场的标杆企业。

在国内，博睿、听云、OneAPM、云智慧在国内市场的占用额较大