什么是 APM 系统？如何设计与实现？

偏执的太偏执、 2022-08-31 04:55 106阅读 0赞

点击上方蓝色“石杉的架构笔记”，选择“设为星标”
    
    回复“PDF”获取独家整理的学习资料！

![20d1646ec989b35cd6debd0b34a0b735.png][]

**![3f57bc58cccf14fc1b3f775ebaba27e3.png][]**

![e2948f7064693cfbe9a5c15f17dad16c.png][]

长按扫描上方一元购买

![6c490f631e50cc0fa004ec9b7314b731.png][]

![91640eb75bf45007c15dca34f3b8d4c0.png][]

前言

![fd70b397874ac25cba1d1cd1e719952e.png][]

本文来说说什么是 APM 系统，也就是大家平时说的监控系统，以及怎么实现一个 APM 系统。因为一些特殊的原因，我在文中会使用 Dog 作为我们的系统名称进行介绍。

我们为 Dog 规划的目标是接入公司的大部分应用，预计每秒处理 500MB-1000MB 的数据，单机每秒 100MB 左右，使用多台普通的 AWS EC2。

因为本文的很多读者供职的公司不一定有比较全面的 APM 系统，所以我尽量照顾更多读者的阅读感受，会在有些内容上啰嗦一些，希望大家可以理解。我会在文中提到 prometheus、grafana、cat、pinpoint、skywalking、zipkin 等一系列工具，如果你没有用过也不要紧，我会充分考虑到这一点。

本文预设的一些背景：Java 语言、web 服务、每个应用有多个实例、以微服务方式部署。另外，从文章的可阅读性上考虑，我假设每个应用的不同实例分布在不同的 IP 上，可能你的应用场景不一定是这样的。

![d60a05b81831f107547350b92f91c548.png][]

APM 简介

![3e0b876a520b4c12613944fd10fe7c64.png][]

APM 通常认为是 Application Performance Management 的简写，它主要有三个方面的内容，分别是 Logs(日志)、Traces(链路追踪) 和 Metrics(报表统计)。以后大家接触任何一个 APM 系统的时候，都可以从这三个方面去分析它到底是什么样的一个系统。

> 有些场景中，APM 特指上面三个中的 Metrics，我们这里不去讨论这个概念。

这节我们先对这 3 个方面进行介绍，同时介绍一下这 3 个领域里面一些常用的工具。

**1、首先 Logs 最好理解，就是对各个应用中打印的 log 进行收集和提供查询能力。**

Logs 系统的重要性不言而喻，通常我们在排查特定的请求的时候，是非常依赖于上下文的日志的。

以前我们都是通过 terminal 登录到机器里面去查 log（我好几年都是这样过来的），但是由于集群化和微服务化的原因，继续使用这种方式工作效率会比较低，因为你可能需要登录好几台机器搜索日志才能找到需要的信息，所以需要有一个地方中心化存储日志，并且提供日志查询。

Logs 的典型实现是 ELK (ElasticSearch、Logstash、Kibana)，三个项目都是由 Elastic 开源，其中最核心的就是 ES 的储存和查询的性能得到了大家的认可，经受了非常多公司的业务考验。

Logstash 负责收集日志，然后解析并存储到 ES。通常有两种比较主流的日志采集方式，一种是通过一个客户端程序 FileBeat，收集每个应用打印到本地磁盘的日志，发送给 Logstash；另一种则是每个应用不需要将日志存储到磁盘，而是直接发送到 Kafka 集群中，由 Logstash 来消费。

Kibana 是一个非常好用的工具，用于对 ES 的数据进行可视化，简单来说，它就是 ES 的客户端。

![78c0be0fa4c418a2d0b52f00a998ed4e.png][]

我们回过头来分析 Logs 系统，Logs 系统的数据来自于应用中打印的日志，它的特点是数据量可能很大，取决于应用开发者怎么打日志，Logs 系统需要存储全量数据，通常都要支持至少 1 周的储存。

每条日志包含 ip、thread、class、timestamp、traceId、message 等信息，它涉及到的技术点非常容易理解，就是日志的存储和查询。

使用也非常简单，排查问题时，通常先通过关键字搜到一条日志，然后通过它的 traceId 来搜索整个链路的日志。

> 题外话，Elastic 其实除了 Logs 以外，也提供了 Metrics 和 Traces 的解决方案，不过目前国内用户主要是使用它的 Logs 功能。

**2、我们再来看看 Traces 系统，它用于记录整个调用链路。**

前面介绍的 Logs 系统使用的是开发者打印的日志，所以它是最贴近业务的。而 Traces 系统就离业务更远一些了，它关注的是一个请求进来以后，经过了哪些应用、哪些方法，分别在各个节点耗费了多少时间，在哪个地方抛出的异常等，用来快速定位问题。

经过多年的发展，Traces 系统虽然在服务端的设计很多样，但是客户端的设计慢慢地趋于统一，所以有了 OpenTracing 项目，我们可以简单理解为它是一个规范，它定义了一套 API，把客户端的模型固化下来。

当前比较主流的 Traces 系统中，Jaeger、SkyWalking 是使用这个规范的，而 Zipkin、Pinpoint 没有使用该规范。限于篇幅，本文不对 OpenTracing 展开介绍。

下面这张图是我画的一个请求的时序图：

![0e4a9fbeebfaf43ac83cdbf00b1a1151.png][]

从上面这个图中，可以非常方便地看出，这个请求经过了 3 个应用，通过线的长短可以非常容易看出各个节点的耗时情况。通常点击某个节点，我们可以有更多的信息展示，比如点击 HttpClient 节点我们可能有 request 和 response 的数据。

下面这张图是 Skywalking 的图，它的 UI 也是蛮好的：

![322baa5726af74c8c4d3199c8b1802c7.png][]

SkyWalking 在国内应该比较多公司使用，是一个比较优秀的由国人发起的开源项目，已进入 Apache 基金会。

另一个比较好的开源 Traces 系统是由韩国人开源的 Pinpoint，它的打点数据非常丰富，这里有官方提供的 Live Demo，大家可以去玩一玩。

![72d7d74234902cdebcddf4e2c81c9cd2.png][]

最近比较火的是由 CNCF(Cloud Native Computing Foundation) 基金会管理的 Jeager：

![4e0cc3d27f49ac9beee60a1e928c358c.png][]

当然也有很多人使用的是 Zipkin，算是 Traces 系统中开源项目的老前辈了：

![a7c8408324d07dcaaecefcd8155e6b40.png][]

上面介绍的是目前比较主流的 Traces 系统，在排查具体问题的时候它们非常有用，通过链路分析，很容易就可以看出来这个请求经过了哪些节点、在每个节点的耗时、是否在某个节点执行异常等。

虽然这里介绍的几个 Traces 系统的 UI 不一样，大家可能有所偏好，但是具体说起来，表达的都是一个东西，那就是一颗调用树，所以我们要来说说每个项目除了 UI 以外不一样的地方。

首先肯定是数据的丰富度，你往上拉看 Pinpoint 的树，你会发现它的埋点非常丰富，真的实现了一个请求经过哪些方法一目了然。

> 但是这真的是一个好事吗？值得大家去思考一下。两个方面，一个是对客户端的性能影响，另一个是服务端的压力。

其次，Traces 系统因为有系统间调用的数据，所以很多 Traces 系统会使用这个数据做系统间的调用统计，比如下面这个图其实也蛮有用的：

![5a7c94e7179bc6ff5f900f55c4d3722f.png][]

另外，前面说的是某个请求的完整链路分析，那么就引出另一个问题，我们怎么获取这个“某个请求”，这也是每个 Traces 系统的不同之处。

比如上图，它是 Pinpoint 的图，我们看到前面两个节点的圆圈是不完美的，点击前面这个圆圈，就可以看出来原因了：

![c01c6f4381e8710731867ccb688d5b0b.png][]

图中右边的两个红圈是我加的。我们可以看到在 Shopping-api 调用 Shopping-order 的请求中，有 1 个失败的请求，我们用鼠标在散点图中把这个红点框出来，就可以进入到 trace 视图，查看具体的调用链路了。限于篇幅，我这里就不去演示其他 Traces 系统的入口了。

还是看上面这个图，我们看右下角的两个统计图，我们可以看出来在最近 5 分钟内 Shopping-api 调用 Shopping-order 的所有请求的耗时情况，以及时间分布。在发生异常的情况，比如流量突发，这些图的作用就出来了。

对于 Traces 系统来说，最有用的就是这些东西了，当然大家在使用过程中，可能也发现了 Traces 系统有很多的统计功能或者机器健康情况的监控，这些是每个 Traces 系统的差异化功能，我们就不去具体分析了。

3、最后，我们再来讨论 Metrics，它侧重于各种报表数据的收集和展示。

在 Metrics 方面做得比较好的开源系统，是大众点评开源的 Cat，下面这个图是 Cat 中的 transaction 视图，它展示了很多的我们经常需要关心的统计数据：

![7f2e540dc49bb1714f0a2eb0b3a6da79.png][]

下图是 Cat 的 problem 视图，对我们开发者来说就太有用了，应用开发者的目标就是让这个视图中的数据越少越好。

![c56462f50148df12f5eda99c4cafe07c.png][]

本文之后的内容主要都是围绕着 [Metrics][] 展开的，所以这里就不再展开更多的内容了。

另外，说到 APM 或系统监控，就不得不提 Prometheus+Grafana 这对组合，它们对机器健康情况、URL 访问统计、QPS、P90、P99 等等这些需求，支持得非常好，它们用来做监控大屏是非常合适的，但是通常不能帮助我们排查问题，它看到的是系统压力高了、系统不行了，但不能一下子看出来为啥高了、为啥不行了。

> 科普：Prometheus 是一个使用内存进行存储和计算的服务，每个机器/应用通过 Prometheus 的接口上报数据，它的特点是快，但是机器宕机或重启会丢失所有数据。
> 
> Grafana 是一个好玩的东西，它通过各种插件来可视化各种系统数据，比如查询 Prometheus、ElasticSearch、ClickHouse、MySQL 等等，它的特点就是酷炫，用来做监控大屏再好不过了。

![5b3dd96a9dd9ce7e9be324f873480dbe.png][]

Metrics 和 Traces

![6f3b36646b2bd72463c2c28db331c423.png][]

因为本文之后要介绍的我们开发的 Dog 系统从分类来说，侧重于 Metrics，同时我们也提供 tracing 功能，所以这里单独写一小节，分析一下 Metrics 和 Traces 系统之间的联系和区别。

使用上的区别很好理解，Metrics 做的是数据统计，比如某个 URL 或 DB 访问被请求多少次，P90 是多少毫秒，错误数是多少等这种问题。而 Traces 是用来分析某次请求，它经过了哪些链路，比如进入 A 应用后，调用了哪些方法，之后可能又请求了 B 应用，在 B 应用里面又调用了哪些方法，或者整个链路在哪个地方出错等这些问题。

不过在前面介绍 Traces 的时候，我们也发现这类系统也会做很多的统计工作，它也覆盖了很多的 Metrics 的内容。

所以大家先要有个概念，Metrics 和 Traces 之间的联系是非常紧密的，它们的数据结构都是一颗调用树，区别在于这颗树的枝干和叶子多不多。在 Traces 系统中，一个请求所经过的链路数据是非常全的，这样对排查问题的时候非常有用，但是如果要对 Traces 中的所有节点的数据做报表统计，将会非常地耗费资源，性价比太低。而 Metrics 系统就是面向数据统计而生的，所以树上的每个节点我们都会进行统计，所以这棵树不能太“茂盛”。

我们关心的其实是，哪些数据值得统计？首先是入口，其次是耗时比较大的地方，比如 db 访问、http 请求、redis 请求、跨服务调用等。当我们有了这些关键节点的统计数据以后，对于系统的健康监控就非常容易了。

我这里不再具体去介绍他们的区别，大家看完本文介绍的 Metrics 系统实现以后，再回来思考这个问题会比较好。

Dog 在设计上，主要是做一个 Metrics 系统，统计关键节点的数据，另外也提供 trace 的能力，不过因为我们的树不是很”茂盛“，所以链路上可能是断断续续的，中间会有很多缺失的地带，当然应用开发者也可以加入手动埋点来弥补。

Dog 因为是公司内部的监控系统，所以对于公司内部大家会使用到的中间件相对是比较确定的，不需要像开源的 APM 一样需要打很多点，我们主要实现了以下节点的自动打点：

*  http 入口：通过实现一个 Filter 来拦截所有的请求；
 *  MySQL: 通过 Mybatis Interceptor 的方式；
 *  Redis: 通过 javassist 增强 RedisTemplate 的方式；
 *  跨应用调用: 通过代理 feign client 的方式，dubbo、grpc 等方式可能需要通过拦截器；
 *  http 调用: 通过 javassist 为 HttpClient 和 OkHttp 增加 interceptor 的方式；
 *  Log 打点: 通过 plugin 的方式，将 log 中打印的 error 上报上来。

打点的技术细节，就不在这里展开了，主要还是用了各个框架提供的一些接口，另外就是用到了 javassist 做字节码增强。

这些打点数据就是我们需要做统计的，当然因为打点有限，我们的 tracing 功能相对于专业的 Traces 系统来说单薄了很多。

![5ed4e5c9e8e6e48a539571ec8fc47f3b.png][]

Dog 简介

![e165fb19172fed6c363a1fd35f1a7b4b.png][]

下面是 DOG 的架构图，客户端将消息投递给 Kafka，由 dog-server 来消费消息，存储用到了 Cassandra 和 ClickHouse，后面再介绍具体存哪些数据。

![97f77e924f33bf585b0311ec32b58375.png][]

1、也有 APM 系统是不通过消息中间件的，比如 Cat 就是客户端通过 Netty 连接到服务端来发送消息的。

2、Server 端使用了 Lambda 架构模式，Dog UI 上查询的数据，由每一个 Dog-server 的内存数据和下游储存的数据聚合而来。

下面，我们简单介绍下 Dog UI 上一些比较重要的功能，我们之后再去分析怎么实现相应的功能。

> 注意：下面的图都是我自己画的，不是真的页面截图，数值上可能不太准确

下图示例 transaction 报表：

![785a3882f73807d0a073f68c585b779d.png][]

点击上图中 type 中的某一项，我们有这个 type 下面每个 name 的报表。比如点击 URL，我们可以得到每个接口的数据统计：

![6c358c00ae4d014e524e04e7cbddb78c.png][]

当然，上图中点击具体的 [name][]，还有下一个层级 status 的统计数据，这里就不再贴图了。Dog 总共设计了 type、name、status 三级属性。上面两个图中的最后一列是 sample，它可以指引到 sample 视图：

![d70965e480491b4bc1693cb9eeb3f423.png][]

Sample 就是取样的意思，当我们看到有个接口失败率很高，或者 P90 很高的时候，你知道出了问题，但因为它只有统计数据，所以你不知道到底哪里出了问题，这个时候，就需要有一些样本数据了。我们每分钟对 type、name、status 的不同组合分别保存最多 5 个成功、5 个失败、5 个慢处理的样本数据。

点击上面的 sample 表中的某个 T、F、L 其实就会进入到我们的 trace 视图，展示出这个请求的整个链路：

![6554fd54bf7c68887e99e5f089ff79cf.png][]

通过上面这个 trace 视图，可以非常快速地知道是哪个环节出了问题。当然，我们之前也说过，我们的 trace 依赖于我们的埋点丰富度，但是 Dog 是一个 Metrics 为主的系统，所以它的 Traces 能力是不够的，不过大部分情况下，对于排查问题应该是足够用的。

对于应用开发者来说，下面这个 Problem 视图应该是非常有用的：

![8b4eb94ba70cf51fc39b48fc1502c399.png][]

它展示了各种错误的数据统计，并且提供了 sample 让开发者去排查问题。

最后，我们再简单介绍下 Heartbeat 视图，它和前面的功能没什么关系，就是大量的图，我们有 gc、heap、os、thread 等各种数据，让我们可以观察到系统的健康情况。

![79de19338aba72d1be38c22b9abaf893.png][]

这节主要介绍了一个 APM 系统通常包含哪些功能，其实也很简单对不对，接下来我们从开发者的角度，来聊聊具体的实现细节问题。

![7c0a084022c248f765be3c0443424c15.png][]

客户端数据模型

![ae4e6843ba535ac37933d8309e81054d.png][]

大家都是开发者，我就直接一些了，下图介绍了客户端的数据模型：

![6a9283bb3d2e7abaf275dc3f4b1243ee.png][]

对于一条 Message 来说，用于统计的字段是 type, name, status，所以我们能基于 type、type+name、type+name+status 三种维度的数据进行统计。

> Message 中其他的字段：timestamp 表示事件发生的时间；success 如果是 false，那么该事件会在 problem 报表中进行统计；data 不具有统计意义，它只在链路追踪排查问题的时候有用；businessData 用来给业务系统上报业务数据，需要手动打点，之后用来做业务数据分析。

Message 有两个子类 Event 和 Transaction，区别在于 Transaction 带有 duration 属性，用来标识该 transaction 耗时多久，可以用来做 max time, min time, avg time, p90, p95 等，而 event 指的是发生了某件事，只能用来统计发生了多少次，并没有时间长短的概念。

Transaction 有个属性 children，可以嵌套 Transaction 或者 Event，最后形成一颗树状结构，用来做 trace，我们稍后再介绍。

下面表格示例一下打点数据，这样比较直观一些：

![f5a011960086e8c3bf435448a2a604e5.png][]

简单介绍几点内容：

*  type 为 URL、SQL、Redis、FeignClient、HttpClient 等这些数据，属于自动埋点的范畴。通常做 APM 系统的，都要完成一些自动埋点的工作，这样应用开发者不需要做任何的埋点工作，就能看到很多有用的数据。像最后两行的 type=Order 属于手动埋点的数据。
 *  打点需要特别注意 type、name、status 的维度“爆炸”，它们的组合太多会非常消耗资源，它可能会直接拖垮我们的 Dog 系统。type 的维度可能不会太多，但是我们可能需要注意开发者可能会滥用 name 和 status，所以我们一定要做 normalize（如 url 可能是带动态参数的，需要格式化处理一下）。
 *  表格中的最后两条是开发者手动埋点的数据，通常用来统计特定的场景，比如我想知道某个方法被调用的情况，调用次数、耗时、是否抛异常、入参、返回值等。因为自动埋点是业务不想关的，冷冰冰的数据，开发者可能想要埋一些自己想要统计的数据。
 *  开发者在手动埋点的时候，还可以上报更多的业务相关的数据上来，参考表格最后一列，这些数据可以做业务分析来用。比如我是做支付系统的，通常一笔支付订单会涉及到非常多的步骤（国外的支付和大家平时使用的微信、支付宝稍微有点不一样），通过上报每一个节点的数据，最后我就可以在 Dog 上使用 bizId 来将整个链路串起来，在排查问题的时候是非常有用的（我们在做支付业务的时候，支付的成功率并没有大家想象的那么高，很多节点可能出问题）。

![030ee209ce4e2af89fd62562f54fef81.png][]

客户端设计

![2fce85eac0797497c89f7d95d1a1730e.png][]

上一节我们介绍了单条 message 的数据，这节我们覆盖一下其他内容。

首先，我们介绍客户端的 API 使用:

public void test() {
      Transaction transaction = Dog.newTransaction("URL", "/test/user");
      try {
        Dog.logEvent("User", "name-xxx", "status-yyy");
    
        // do something
    
        Transaction sql = Dog.newTransaction("SQL", "UserMapper.insert");
        // try-catch-finally
    
        transaction.setStatus("xxxx");    
        transaction.setSuccess(true/false);
      } catch (Throwable throwable) {
        transaction.setSuccess(false);
        transaction.setData(Throwables.getStackTraceAsString(throwable));
        throw throwable;
      } finally {
        transaction.finish();
      }
    }

上面的代码示例了如何嵌套使用 Transaction 和 Event，当最外层的 Transaction 在 finally 代码块调用 finish() 的时候，完成了一棵树的创建，进行消息投递。

我们往 Kafka 中投递的并不是一个 Message 实例，因为一次请求会产生很多的 Message 实例，而是应该组织成 一个 Tree 实例以后进行投递。下图描述 Tree 的各个属性：

![5f2f61dda98d7fa69f41a10fe6b65edb.png][]

Tree 的属性很好理解，它持有 root transaction 的引用，用来遍历整颗树。另外就是需要携带机器信息 messageEnv。

treeId 应该有个算法能保证全局唯一，简单介绍下 Dog 的实现：$\{appName\}-$\{encode(ip)\}-$\{当前分钟\}-$\{自增id\}。

> 下面简单介绍几个 tree id 相关的内容，假设一个请求从 A->B->C->D 经过 4 个应用，A 是入口应用，那么会有：
> 
> 1、总共会有 4 个 Tree 对象实例从 4 个应用投递到 Kafka，跨应用调用的时候需要传递 treeId, parentTreeId, rootTreeId 三个参数；
> 
> 2、A 应用的 treeId 是所有节点的 rootTreeId；
> 
> 3、B 应用的 parentTreeId 是 A 的 treeId，同理 C 的 parentTreeId 是 B 应用的 treeId；
> 
> 4、在跨应用调用的时候，比如从 A 调用 B 的时候，为了知道 A 的下一个节点是什么，所以在 A 中提前为 B 生成 treeId，B 收到请求后，如果发现 A 已经为它生成了 treeId，直接使用该 treeId。
> 
> 大家应该也很容易知道，通过这几个 tree id，我们是想要实现 trace 的功能。

介绍完了 tree 的内容，我们再简单讨论下应用集成方案。

集成无外乎两种技术，一种是通过 javaagent 的方式，在启动脚本中，加上相应的 agent，这种方式的优点是开发人员无感知，运维层面就可以做掉，当然开发者如果想要手动做一些埋点，可能需要再提供一个简单的 client jar 包给开发者，用来桥接到 agent 里。

另一种就是提供一个 jar 包，由开发者来引入这个依赖。

两种方案各有优缺点，Pinpoint 和 Skywalking 使用的是 javaagent 方案，Zipkin、Jaeger、Cat 使用的是第二种方案，Dog 也使用第二种手动添加依赖的方案。

> 通常来说，做 Traces 的系统选择使用 javaagent 方案比较省心，因为这类系统 agent 做完了所有需要的埋点，无需应用开发者感知。

最后，我再简单介绍一下 Heartbeat 的内容，这部分内容其实最简单，但是能做出很多花花绿绿的图表出来，可以实现面向老板编程。

![3efd76104958dd2aa08423aa5c334df6.png][]

前面我们介绍了 Message 有两个子类 Event 和 Transaction，这里我们再加一个子类 Heartbeat，用来上报心跳数据。

我们主要收集了 thread、os、gc、heap、client 运行情况（产生多少个 tree，数据大小，发送失败数)等，同时也提供了 api 让开发者自定义数据进行上报。Dog client 会开启一个后台线程，每分钟运行一次 Heartbeat 收集程序，上报数据。

> 再介绍细一些。核心结构是一个 Map\\<String, Double>，key 类似于 “os.systemLoadAverage”, “thread.count” 等，前缀 os，thread，gc 等其实是用来在页面上的分类，后缀是显示的折线图的名称。

关于客户端，这里就介绍这么多了，其实实际编码过程中，还有一些细节需要处理，比如如果一棵树太大了要怎么处理，比如没有 rootTransaction 的情况怎么处理（开发者只调用了 Dog.[logEvent][name](...)），比如内层嵌套的 transaction 没有调用 finish 怎么处理等等。

![08a6623d38534a19cae42ea760198bf3.png][]

Dog Server 设计

![74d227dc8253db45e267ca2817f812f6.png][]

下图示例了 server 的整体设计，值得注意的是，我们这里对线程的使用非常地克制，图中只有 3 个工作线程。

![ed9ea6f89e07b91a622f4ffbd62880a2.png][]

首先是 Kafka Consumer 线程，它负责批量消费消息，从 kafka 集群中消费到的是一个个 Tree 的实例，接下来考虑怎么处理它。

在这里，我们需要将树状结构的 message 铺平，我们把这一步叫做 deflate，并且做一些预处理，形成下面的结构：

![771445a1910bcca52fde9901b2a65d9b.png][]

接下来，我们就将 DeflateTree 分别投递到两个 Disruptor 实例中，我们把 Disruptor 设计成单线程生产和单线程消费，主要是性能上的考虑。

消费线程根据 DeflateTree 的属性使用绑定好的 Processor 进行处理，比如 DeflateTree 中 List<Message> problmes 不为空，同时自己绑定了 ProblemProcessor，那么就需要调用 ProblemProcessor 来处理。

> 科普时间：Disruptor 是一个高性能的队列，性能比 JDK 中的 BlockingQueue 要好

这里我们使用了 2 个 Disruptor 实例，当然也可以考虑使用更多的实例，这样每个消费线程绑定的 processor 就更少。

我们这里把 Processor 绑定到了 Disruptor 实例上，其实原因也很简单，为了性能考虑，我们想让每个 processor 只有单线程使用它，单线程操作可以减少线程切换带来的开销，可以充分利用到系统缓存，以及在设计 processor 的时候，不用考虑并发读写的问题。

这里要考虑负载均衡的情况，有些 processor 是比较耗费 CPU 和内存资源的，一定要合理分配，不能把压力最大的几个任务分到同一个线程中去了。

核心的处理逻辑都在各个 processor 中，它们负责数据计算。接下来，我把各个 processor 需要做的主要内容介绍一下，毕竟能看到这里的开发者，应该真的是对 APM 的数据处理比较感兴趣的。

![6e88d00835c087773639cde3a02c29c7.png][]

Transaction Processor

![438d289b9e8b519d4f0151528c77696c.png][]

Transaction processor 是系统压力最大的地方，它负责报表统计，虽然 Message 有 Transaction 和 Event 两个主要的子类，但是在实际的一颗树中，绝大部分的节点都是 transaction 类型的数据。

![2c07291ff3adc6b47a8d4142a3131c71.png][]

下图是 transaction processor 内部的一个主要的数据结构，最外层是一个时间，我们用分钟时间来组织，我们最后在持久化的时候，也是按照分钟来存的。

第二层的 HostKey 代表哪个应用以及哪个 ip 来的数据，第三层是 type、name、status 的组合。最内层的 Statistics 是我们的数据统计模块。

![9c3eb8e9a929cafaefe1b00c54fe28b3.png][]

另外我们也可以看到，这个结构到底会消耗多少内存，其实主要取决于我们的 type、name、status 的组合也就是 ReportKey 会不会很多，也就是我们前面在说客户端打点的时候，要避免维度爆炸。

最外层结构代表的是时间的分钟表示，我们的报表是基于每分钟来进行统计的，之后持久化到 ClickHouse 中，但是我们的使用者在看数据的时候，可不是一分钟一分钟看的，所以需要做数据聚合，下面展示两条数据是如何做聚合的，在很多数据的时候，都是按照同样的方法进行合并。

![158452ab54abf66bf1d376cc81096bbc.png][]

> 你仔细想想就会发现，前面几个数据的计算都没毛病，但是 P90, P95 和 P99 的计算是不是有点欺骗人啊？其实这个问题是真的无解的，我们只能想一个合适的数据计算规则，然后我们再想想这种计算规则，可能算出来的值也是差不多可用的就好了。

另外有一个细节问题，我们需要让内存中的数据提供最近 30 分钟的统计信息，30 分钟以上的才从 DB 读取。然后做上面介绍的 merge 操作。

> 讨论：我们是否可以丢弃一部分实时性，我们每分钟持久化一次，我们读取的数据都是从 DB 来的，这样可行吗？
> 
> 不行，因为我们的数据是从 kafka 消费来的，本身就有一定的滞后性，我们如果在开始一分钟的时候就持久化上一分钟的数据，可能之后还会收到前面时间的消息，这种情况处理不了。

比如我们要统计最近一小时的情况，那么就会有 30 分钟的数据从各个机器中获得，有 30 分钟的数据从 DB 获得，然后做合并。

这里值得一提的是，在 transaction 报表中，count、failCount、min、max、avg 是比较好算的，但是 P90、P95、P99 其实不太好算，我们需要一个数组结构，来记录这一分钟内所有的事件的时间，然后进行计算，我们这里讨巧使用了 Apache DataSketches，它非常好用，这里我就不展开了，感兴趣的同学可以自己去看一下。

到这里，大家可以去想一想储存到 ClickHouse 的数据量的问题。app\_name、ip、type、name、status 的不同组合，每分钟一条数据。

![23d43fa65bea84d053b426d03e93a9f5.png][]

Sample Processor

![e5bdf95f4cc4a6d2813640b8505d3477.png][]

sample processor 消费 deflate tree 中的 List<Transaction> transactions 和 List<Event> events 的数据。

我们也是按照分钟来采样，最终每分钟，对每个 type、name、status 的不同组合，采集最多 5 个成功、5 个失败、5 个慢处理。

相对来说，这个还是非常简单的，它的核心结构如下图：

![8f25548c1262df8e07b59389bf000d26.png][]

结合 Sample 的功能来看比较容易理解：

![d853711bd74ca43d9ca7bea9b66d9b9d.png][]

![abd5b0bac0481cb2b19a01a3638fbfb0.png][]

**  ****Problem Processor**

![c8c13015334c4c5d0de47622d42e919d.png][]

在做 deflate 的时候，所有 success=false 的 Message，都会被放入 List<Message> problmes 中，用来做错误统计。

Problem 内部的数据结构如下图：

![432988fd83a7e0af82c808a260fdf8e2.png][]

大家看下这个图，其实也就知道要做什么了，我就不啰嗦了。其中 samples 我们每分钟保存 5 个 treeId。

顺便也再展示下 Problem 的视图：

![213db5640641ac6746feea9d16511658.png][]

关于持久化，我们是存到了 ClickHouse 中，其中 sample 用逗号连接成一个字符串，problem\_data 的列如下：

event_date, event_time, app_name, ip, type, name, status, count, sample

![c9f32f23045bb8c1471ecfdcb73add65.png][]

HeartBeat Processor

![7ad54523113a9ba212a0b9438e30138d.png][]

Heartbeat 处理 List<Heartbeat> heartbeats 的数据，题外话，正常情况下，一颗树里面只有一个 Heartbeat 实例。

前面我也简单提到了一下，我们 Heartbeat 中用来展示图表的核心数据结构是一个 Map<String, Double> 。

收集到的 key-value 数据如下所示：

{
      "os.systemLoadAverage": 1.5,
      "os.committedVirtualMemory": 1234562342,
      "os.openFileDescriptorCount": 800,
      "thread.count": 600,
      "thread.httpThreadsCount": 250,
      "gc.ZGC Count": 234,
      "gc.ZGC Time(ms)": 123435,
      "heap.ZHeap": 4051233219,
      "heap.Metaspace": 280123212
    }

前缀是分类，后缀是图的名称。客户端每分钟收集一次数据进行上报，然后就可以做很多的图了，比如下图展示了在 heap 分类下的各种图：

![333826848ddfa509ab90ec88fc2763b2.png][]

Heartbeat processor 要做的事情很简单，就是数据存储，Dog UI 上的数据是直接从 ClickHouse 中读取的。

heartbeat\_data 的列如下：

event_date, event_time, timestamp, app_name, ip, name, value

![baa4eef1a6223d3d9b1edd19ff99ef60.png][]

MessageTree Processor

![245f55b738e85c24343e1d9a8f9d4b00.png][]

前面我们多次提到了 Sample 的功能，这些采样的数据帮助我们恢复现场，这样我们可以通过 trace 视图来跟踪调用链。

![365db64b44b6a8888cc981cb4f5c0a28.png][]

要做上面的这个 trace 视图，我们需要上下游的所有的 tree 的数据，比如上图是 3 个 tree 实例的数据。

> 之前我们在客户端介绍的时候说过，这几个 tree 通过 parent treeId 和 root treeId 来组织。

要做这个视图，给我们提出的挑战就是，我们需要保存全量的数据。

> 大家可以想一想这个问题，为啥要保存全量数据，我们直接保存被 sample 到的数据不就好了吗？

这里我们用到了 Cassandra 的能力，Cassandra 在这种 kv 的场景中，有非常不错的性能，而且它的运维成本很低。

我们以 treeId 作为主键，另外再加 data 一个列即可，它是整个 tree 的实例数据，数据类型是 blob，我们会先做一次 gzip 压缩，然后再扔给 Cassandra。

![bc67aa92255c621238246f3139c33f5d.png][]

Business Processor

![763886e2892082254b8dabdc29b2c58e.png][]

我们在介绍客户端的时候说过，每个 Message 都可以携带 Business Data，不过只有应用开发者自己手动埋点的时候才会有，当我们发现有业务数据的时候，我们会做另一个事情，就是把这个数据存储到 ClickHouse 中，用来做业务分析。

我们其实不知道应用开发者到底会把它用在什么场景中，因为每个人负责的项目都不一样，所以我们只能做一个通用的数据模型。

![ae446de563147874e4b7e895ea8eae17.png][]

回过头来看这个图，BusinessData 中我们定义了比较通用的 userId 和 bizId，我们认为它们可能是每个业务场景会用到的东西。userId 就不用说了，bizId 大家可以做来记录订单 id，支付单 id 等。

然后我们提供了 3 个 String 类型的列 ext1、ext2、ext3 和两个数值类型的列 extVal1 和 extVal2，它们可以用来表达你的业务相关的参数。

我们的处理当然也非常简单，将这些数据存到 ClickHouse 中就可以了，表中主要有这些列：

event_data, event_time, user, biz_id, timestamp, type, name, status, app_name、ip、success、ext1、ext2、ext3、ext_val1、ext_val2

这些数据对我们 Dog 系统来说肯定不认识，因为我们也不知道你表达的是什么业务，type、name、status 是开发者自己定义的，ext1, ext2, ext3 分别代表什么意思，我们都不知道，我们只负责存储和查询。

这些业务数据非常有用，基于这些数据，我们可以做很多的数据报表出来。因为本文是讨论 APM 的，所以该部分内容就不再赘述了。

![9dfe6614e45b8a7852dc16ec6ca0c639.png][]

其他

![b313e308a42fd36b70af61e1e7878171.png][]

ClickHouse 需要批量写入，不然肯定是撑不住的，一般一个 batch 至少 10000 行数据。

我们在 Kafka 这层控制了，一个 app\_name + ip 的数据，只会被同一个 dog-server 消费，当然也不是说被多个 dog-server 消费会有问题，但是这样写入 ClickHouse 的数据就会更多。

还有个关键的点，前面我们说了每个 processor 是由单线程进行访问的，但是有一个问题，那就是来自 Dog UI 上的请求可怎么办？这里我想了个办法，那就是将请求放到一个 Queue 中，由 Kafka Consumer 那个线程来消费，它会将任务扔到两个 Disruptor 中。比如这个请求是 transaction 报表请求，其中一个 Disruptor 的消费者会发现这个是自己要干的，就会去执行这个任务。

![f6ccd0027d136dcf86657bd57ad086f0.png][]

小结

![b791d73eafd9ac443986918dbae5373e.png][]

如果你了解 Cat 的话，可以看到 Dog 在很多地方和 Cat 有相似之处，或者直接说”抄“也行，之前我们也考虑过直接使用 Cat 或者在 Cat 的基础上做二次开发。

但是我看完 Cat 的源码后，就放弃了这个想法，仔细想想，只是借鉴 Cat 的数据模型，然后我们自己写一套 APM 其实不是很难，所以有了我们这个项目。

行文需要，很多地方我都避重就轻，因为这不是什么源码分析的文章，没必要处处谈细节，主要是给读者一个全貌，读者能通过我的描述大致想到需要处理哪些事情，需要写哪些代码，那就当我表述清楚了。

欢迎大家提出自己的疑问或者想法，有不懂或者我有错漏的地方，欢迎指正~

> 作者：javadoop
> 
> 来源：https://www.javadoop.com/post/apm

[20d1646ec989b35cd6debd0b34a0b735.png]: /images/20220829/3eb55f7dcdbd4d419f186e379befd3e4.png
[3f57bc58cccf14fc1b3f775ebaba27e3.png]: /images/20220829/3850abd9801d4b9b879c395d1ea4dc32.png
[e2948f7064693cfbe9a5c15f17dad16c.png]: /images/20220829/b53a8f4b20f0469383610e509a08ab71.png
[6c490f631e50cc0fa004ec9b7314b731.png]: /images/20220829/b49e04e530fe41cb81371d8080333e77.png
[91640eb75bf45007c15dca34f3b8d4c0.png]: /images/20220829/a3ef4721aaf545859ed50e5c6c789c18.png
[fd70b397874ac25cba1d1cd1e719952e.png]: /images/20220829/56c02c5835094f4ca6041bc45384b334.png
[d60a05b81831f107547350b92f91c548.png]: /images/20220829/fd52a1fa223b4c978b877f2a44caca0e.png
[3e0b876a520b4c12613944fd10fe7c64.png]: /images/20220829/550c2768f0634c38b1ba8fea03ff0f47.png
[78c0be0fa4c418a2d0b52f00a998ed4e.png]: /images/20220829/3490f9bae3b54af38f6d6e8e150fee96.png
[0e4a9fbeebfaf43ac83cdbf00b1a1151.png]: /images/20220829/7edbdd9b91124df38e2439ffd31b3d17.png
[322baa5726af74c8c4d3199c8b1802c7.png]: /images/20220829/b5bb1431f6c647b498b42e45907c27bd.png
[72d7d74234902cdebcddf4e2c81c9cd2.png]: /images/20220829/7072566dcea047f8b21c8d8efb49f9eb.png
[4e0cc3d27f49ac9beee60a1e928c358c.png]: /images/20220829/a307b676cf6a4587b739f6668d259087.png
[a7c8408324d07dcaaecefcd8155e6b40.png]: /images/20220829/c9d6d9640cb1412f99d1c80c44838c10.png
[5a7c94e7179bc6ff5f900f55c4d3722f.png]: /images/20220829/7d1a678ba3a749f681ef1bcaba0453dc.png
[c01c6f4381e8710731867ccb688d5b0b.png]: /images/20220829/8a388579420942da81fd90f450cccf84.png
[7f2e540dc49bb1714f0a2eb0b3a6da79.png]: /images/20220829/353eee66babc4a53b9d763726f4e726e.png
[c56462f50148df12f5eda99c4cafe07c.png]: /images/20220829/e98f8345f02c43d9acee4f5636653f59.png
[Metrics]: http://mp.weixin.qq.com/s?__biz=MzIxMTE0ODU5NQ%3D%3D&chksm=8f5aec39b82d652fbc4f68aecda9960e2e3d9ea93720b0a415d91d608a3acee4df20c04adadb&idx=1&mid=2650244709&scene=21&sn=333d74e765861036510be2e57d2c3681#wechat_redirect
[5b3dd96a9dd9ce7e9be324f873480dbe.png]: /images/20220829/3cb38807d295449fa58a903c4d7c9e51.png
[6f3b36646b2bd72463c2c28db331c423.png]: /images/20220829/d56526709dce46249243b68a368fc875.png
[5ed4e5c9e8e6e48a539571ec8fc47f3b.png]: /images/20220829/5aae605d690b47ca9ec2018b290b1406.png
[e165fb19172fed6c363a1fd35f1a7b4b.png]: /images/20220829/6f0125b88bb24843b39f2b991d54cde4.png
[97f77e924f33bf585b0311ec32b58375.png]: /images/20220829/e82ad098bc5445d9a869565fae3cf7ea.png
[785a3882f73807d0a073f68c585b779d.png]: /images/20220829/d4555d9642044be08922742c85ef1b0e.png
[6c358c00ae4d014e524e04e7cbddb78c.png]: /images/20220829/47c53e4cc5cd410c8b993173146293be.png
[name]: http://mp.weixin.qq.com/s?__biz=MzIxMTE0ODU5NQ%3D%3D&chksm=8f5aec0cb82d651a805c47ded6396f4de3e935da543c73df0fdea7e1eca1605766e3b470ee68&idx=1&mid=2650244688&scene=21&sn=4707496fef3add6d7990cd6c8629ed0b#wechat_redirect
[d70965e480491b4bc1693cb9eeb3f423.png]: /images/20220829/d15df10312004125a6d5b7972ec2fc46.png
[6554fd54bf7c68887e99e5f089ff79cf.png]: /images/20220829/815d978ba0cc4867aab895b4bd39e650.png
[8b4eb94ba70cf51fc39b48fc1502c399.png]: /images/20220829/45bf4c3723b7444da8cbd57f55f0d8d5.png
[79de19338aba72d1be38c22b9abaf893.png]: /images/20220829/11d9b07cb7024aef96d97f5cf10887a1.png
[7c0a084022c248f765be3c0443424c15.png]: /images/20220829/c4e379cd3496492b9adc00627544f6f0.png
[ae4e6843ba535ac37933d8309e81054d.png]: /images/20220829/bb55159abb354ba38e444bc6251a60a6.png
[6a9283bb3d2e7abaf275dc3f4b1243ee.png]: /images/20220829/7736fe5d3f0544f0ad452edab8d3f332.png
[f5a011960086e8c3bf435448a2a604e5.png]: /images/20220829/657b6abc7f27426eb253f56623d6376a.png
[030ee209ce4e2af89fd62562f54fef81.png]: /images/20220829/d7db400fb7df4b8cab7641eca1c21ed5.png
[2fce85eac0797497c89f7d95d1a1730e.png]: /images/20220829/129ce06568284e3da0bb9abd9b7e48f0.png
[5f2f61dda98d7fa69f41a10fe6b65edb.png]: /images/20220829/95adc1c110a64ce7a2200a26798ff28f.png
[3efd76104958dd2aa08423aa5c334df6.png]: /images/20220829/909b419603874a83bd1923b62609beab.png
[08a6623d38534a19cae42ea760198bf3.png]: /images/20220829/8b7b73f2aec949e79b6ba10faffe7012.png
[74d227dc8253db45e267ca2817f812f6.png]: /images/20220829/5243bcd1675445e1891df2418eb9ba40.png
[ed9ea6f89e07b91a622f4ffbd62880a2.png]: /images/20220829/be60fad192114be9966ff2f8c126e43f.png
[771445a1910bcca52fde9901b2a65d9b.png]: /images/20220829/88e9140a882e41d6a3296562ad5d0068.png
[6e88d00835c087773639cde3a02c29c7.png]: /images/20220829/6d7f8c7b425d411aa14ab1d1573cde76.png
[438d289b9e8b519d4f0151528c77696c.png]: /images/20220829/39380657638f4351875c71de49d0bad6.png
[2c07291ff3adc6b47a8d4142a3131c71.png]: /images/20220829/3ab5ff4ac9cb43ad81129052ffa4a667.png
[9c3eb8e9a929cafaefe1b00c54fe28b3.png]: /images/20220829/d7fe6630a4054e2d95b1dd2c114d0d36.png
[158452ab54abf66bf1d376cc81096bbc.png]: /images/20220829/f5594b178e764b63a6167ec87ffb70a6.png
[23d43fa65bea84d053b426d03e93a9f5.png]: /images/20220829/69341d18f1254e5c9c7a789aebb1a0e1.png
[e5bdf95f4cc4a6d2813640b8505d3477.png]: /images/20220829/e62671f25c5644e58b3c714f33902219.png
[8f25548c1262df8e07b59389bf000d26.png]: /images/20220829/01b9cdcb57e841ae848bba11ebeb72b1.png
[d853711bd74ca43d9ca7bea9b66d9b9d.png]: /images/20220829/3266b23fd2bc48cc851b677a0c029302.png
[abd5b0bac0481cb2b19a01a3638fbfb0.png]: /images/20220829/44e90352285c4966a491f6f100a02a6a.png
[c8c13015334c4c5d0de47622d42e919d.png]: /images/20220829/6b44df6f47fa44c18297da1fc3632c6b.png
[432988fd83a7e0af82c808a260fdf8e2.png]: /images/20220829/1fbcdf6c0d5e40f2ab9283571195bca8.png
[213db5640641ac6746feea9d16511658.png]: /images/20220829/c8a0e0bc6cbc492483e3443345d60da0.png
[c9f32f23045bb8c1471ecfdcb73add65.png]: /images/20220829/a5fc894a7c77464fa69203eeb5e1a41b.png
[7ad54523113a9ba212a0b9438e30138d.png]: /images/20220829/8266a5a4047e473fab3eab266b58c4d5.png
[333826848ddfa509ab90ec88fc2763b2.png]: /images/20220829/5c3f0906c01444fe9acd9942fa3d21a5.png
[baa4eef1a6223d3d9b1edd19ff99ef60.png]: /images/20220829/09ea1372c2684176828e0c9c48741ea4.png
[245f55b738e85c24343e1d9a8f9d4b00.png]: /images/20220829/9a40c8ad9638413f930fb980f91ad1a7.png
[365db64b44b6a8888cc981cb4f5c0a28.png]: /images/20220829/72ccfb0bb100418b81e61143a99e62e9.png
[bc67aa92255c621238246f3139c33f5d.png]: /images/20220829/e6300074ad08444691fe2b77a801c2fd.png
[763886e2892082254b8dabdc29b2c58e.png]: /images/20220829/32fc473106bb4ba38a2cd47ea0d28ad3.png
[ae446de563147874e4b7e895ea8eae17.png]: /images/20220829/6c43e0572c4b46b88b5835920e5570c2.png
[9dfe6614e45b8a7852dc16ec6ca0c639.png]: /images/20220829/e469d7d779234386baf45057aef077e0.png
[b313e308a42fd36b70af61e1e7878171.png]: /images/20220829/9c2a387cea6041e78ac8f587b0192de7.png
[f6ccd0027d136dcf86657bd57ad086f0.png]: /images/20220829/28678e8e2f3e49198e24d3118fd48f70.png
[b791d73eafd9ac443986918dbae5373e.png]: /images/20220829/29ff8f0076604f26ad673cd1b2a08f35.png