照片来源于 包图网
大家为 Dog 整体规划的总体目标是连接企业的绝大多数运用，预估每秒钟解决 500MB-1000MB 的数据信息，单机版每秒钟 100MB 上下，应用几台一般的 AWS EC2。
由于文中的许多阅读者任职的企业不一定有较为全方位的 APM 系统，所以我尽可能照料大量阅读者的阅读感受，会在有一些內容上唠叨一些，期待我们可以了解。
我能在原文中提及 Prometheus、Grafana、Cat、Pinpoint、Skywalking、Zipkin 等一系列专用工具，假如你沒有使用过也没事儿，我能考虑到到这一点。
文中预置的一些环境：Java 语言表达、Web 服务项目、每一个运用有好几个案例、以微服务架构方法布署。
此外，从内容的可浏览性上考虑到，我假定每一个运用的不一样案例遍布在不一样的 IP 上，很有可能你的应用领域不一定是如此的。
APM 介绍
APM 通常以为是 Application Performance Management 的缩写，它具体有三个领域的內容，分别是 Logs(日志)、Traces(链路追踪)和 Metrics(报表统计)。
之后大伙儿触碰一切一个 APM 系统的情况下，都能够从这三个层面去剖析它到底是什么样子的一个系统。
有一些情景中，APM 专指上边三个中的 Metrics，大家在这里没去探讨这一定义。
这节大家先对这 3 个领域开展详细介绍，与此同时介绍一下这 3 个行业里边一些较常用的专用工具。
①最先 Logs 最好是了解，便是对各种运用中复印的 log 开展整理和给予查看工作能力。
Logs 系统的重要程度显而易见，通常我们在清查特殊的请求的情况下，是十分取决于前后文的日志的。
之前我们是根据 terminal 登陆到设备里边去查 log(我很多年是那样回来的)，可是因为群集化和微服务创新的缘故，再次应用这些方法工作效能会非常低。
因为你很有可能必须登陆很多台设备检索日志才可以寻找必须的信息，因此必须有一个地方去中心化储存日志，而且给予日志查看。
Logs 的典型性完成是 ELK(ElasticSearch、Logstash、Kibana)，三个新项目全是由 Elastic 开源系统，在其中最主要的便是 ES 的存放和查找的功能获得了各位的认同，承受了十分多企业的业务流程磨练。
Logstash 承担搜集日志，随后分析并储存到 ES。通常有二种较为核心的日志收集方法：
- 一种是根据一个客户端程序 FileBeat，搜集每一个运用打印出到系统盘的日志，发给 Logstash。
- 另一种则是每一个运用不用将日志储存到硬盘，反而是立即发送至 Kafka 群集中，由 Logstash 来交易。
Kibana 是一个十分实用的专用工具，用以对 ES 的信息开展数据可视化，简易而言，它便是 ES 的手机客户端。
kibana-discover
大家转过头来剖析 Logs 系统，Logs 系统的数据信息来自于运用中复印的日志，它的特性是信息量很有可能非常大，在于运用开发人员如何打日志，Logs 系统必须储存全量数据信息，通常都需要适用最少 1 周的存储。
每条日志包括 ip、thread、class、timestamp、traceId、message 等信息，它涉及的技术性点很容易了解，便是日志的存放和查看。
应用也比较简单，清查问题时，通常先根据关键词搜到一条日志，随后根据它的 traceId 来检索全部链接的日志。
题外话，Elastic 实际上除开 Logs 之外，也保证了 Metrics 和 Traces 的解决方法，但是现阶段中国客户主要是运用它的 Logs 作用。
②让我们再一起来看看 Traces 系统，它用以纪录全部启用链接。
前边讲解的 Logs 系统应用的是开发人员打印出的日志，因此它是最接近工作的。
而 Traces 系统就离业务流程更远一些了，它关心的是一个请求进去之后，通过了什么运用、什么方式，各自在每个节点消耗了是多少時间，在哪个地方抛出去的不正常等，用于迅速精准定位。
通过十几年的发展趋势，Traces 系统尽管在服务器端的设计很多种多样，可是手机客户端的设计方案渐渐地趋向统一，因此拥有 OpenTracing 新项目，我们可以简易了解为它是一个标准，它界定了一套 API，把手机客户端的实体模型干固出来。
现阶段较为核心的 Traces 系统中，Jaeger、SkyWalking 是应用这一标准的，而 Zipkin、Pinpoint 沒有采用该标准。仅限于篇数，文中不对 OpenTracing 进行详细介绍。
下边这幅图就是我画的一个请求的状态图：
trace
从上边这一图上，可以十分便捷地看得出，这一请求通过了 3 个运用，根据线的长度可以很容易看得出每个节点的用时状况。
通常点一下某一节点，我们可以有越多的信息展现，例如点一下 HttpClient 节点大家很有可能有 request 和 response 的数据信息。
下边这幅图是 Skywalking 的图，它的 UI 也是蛮好的：
skywalking-trace
SkyWalking 在中国应当比较多企业应用，是一个非常出色的由中国人进行的开源软件，已进到 Apache 慈善基金会。
另一个比较好的开源系统 Traces 系统是由日本人开源系统的 Pinpoint，它的打理数据信息比较丰富，这里有官方网给予的 Live Demo，大伙儿可以去玩一玩。
pinpoint
近期较为火的是由 CNCF(Cloud Native Computing Foundation)慈善基金会管理方法的 Jeager：
jaeger
自然也是有很多人应用的是 Zipkin，算得上 Traces 系统中开源软件的老一辈了：
zipkin
上边详细介绍的是现阶段较为核心的 Traces 系统，在清查实际问题的情况下他们十分有效，根据链接剖析，非常容易可以看出去这一请求通过了什么节点、在每一个节点的用时、是不是在某一节点实行出现异常等。
尽管这儿详细介绍的好多个 Traces 系统的 UI 不一样，大伙儿很有可能有一定的喜好，可是实际说起来，表述的全是一个物品，那便是一颗启用树，因此我们要而言说每一个新项目除开 UI 之外不一样的地方。
最先肯定是数据信息的丰富度，你往上提看 Pinpoint 的树，你就会发现它的前后端分离比较丰富，确实完成了一个请求通过什么方式一目了然。
可是这真的是一个好事儿吗?非常值得大伙儿去思索一下。2个层面，一个是对服务端的特性危害，另一个是服务器端的工作压力。
次之，Traces 系统由于有系统间启用的数据信息，因此许多 Traces 系统会应用这一数据信息做系统间的启用统计分析，例如下边这一图实际上也蛮有效的：
trace-statistics
此外，前边说的是某一请求的详细链接剖析，那麼就引出另一个问题，大家怎么获取这一“某一请求”，这也是每一个 Traces 系统的不同点。
例如图中，它是 Pinpoint 的图，大家见到前边2个节点的圆形是有缺憾的，点一下前边这一圆形，就能够看出去缘故了：
pinpoint-dashboard
图上右侧的2个小圆圈就是我加的。我们可以见到在 Shopping-api 启用 Shopping-order 的请求中，有 1 个错误的请求。
大家用电脑鼠标在散点图中把这个小红点框出来，就可以加入到 trace 主视图，查询详细的启用链接了。仅限于篇数，我这里就没去演试别的 Traces 系统的通道了。
或是看上边这一图，大家看右下方的2个统计图表，大家能看出去在近期 5 分鐘内 Shopping-api 启用 Shopping-order 的全部请求的用时状况，及其時间遍布。在产生异常情况的状况，例如总流量突发性，这种图的功效就出来。
针对 Traces 系统而言，最有效的便是这种物品了，自然我们在应用全过程中，很有可能也看到了 Traces 系统有很多的统计分析作用或是设备健康情况的监管，这种是每一个 Traces 系统的多元化作用，大家就没去深入分析了。
③最终，大家接着探讨 Metrics，它偏重于各种各样表格数据的搜集和展现。
在 Metrics 层面做得比较好的开源系统系统，是大众点评网开源系统的 Cat，下边这一图是 Cat 中的 transaction 主视图，它展现了许多的大家常常必须关注的统计分析数据：
cat-transaction
下面的图是 Cat 的 problem 主视图，对大家开发人员而言就太有用了，运用开发人员的目的是让这一主视图中的数据越低就越好。
cat-problem
文中以后的具体内容关键全是紧紧围绕着 Metrics 进行的，因此在这里就不会再进行大量的信息了。
此外，说到 APM 或系统监管，就不能不提 Prometheus Grafana 这对组成，他们对设备健康情况、URL 网站统计、QPS、P90、P99 这些这种要求，适用得很好，他们用于做监控大屏是特别适宜的。
可是通常不能帮助我们清查问题，它见到的是系统工作压力高了、系统不行，但不可以一下子看出去为什么高了、为啥不行。
科谱：Prometheus 是一个应用运行内存开展储存和估算的服务项目，每一个设备/运用根据 Prometheus 的插口汇报数据，它的特性是快，可是设备服务器宕机或重新启动会遗失全部数据。
Grafana 是一个小玩意，它利用各种各样软件来数据可视化各种各样系统数据，例如查看 Prometheus、ElasticSearch、ClickHouse、MySQL 这些，它的特征便是炫酷，用于做监控大屏最好不过了。
Metrics 和 Traces
由于文中以后要介紹的大家开发设计的 Dog 系统从归类而言，偏重于 Metrics，与此同时大家也给予 tracing 作用，因此这儿独立写一小标题，剖析一下 Metrics 和 Traces 系统中间的沟通和区别。
应用上的区别非常好了解，Metrics 做的是数据统计分析，例如某一 URL 或 DB 浏览被要求几回，P90 多少钱ms，不正确数多少钱等这类问题。
而 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 系统而言薄弱了许多。
Dog 介绍
下边是 DOG 的架构图，手机客户端将信息递送给 Kafka，由 dog-server 来交易信息，储存使用了 Cassandra 和 ClickHouse，后边再详细介绍实际存什么数据。
architecture
也是有 APM 系统不是根据消息中间件的，例如 Cat 便是手机客户端根据 Netty 联接到服务器端来推送讯息的。
Server 端应用了 Lambda 架构设计，Dog UI 上查看的数据，由每一个 Dog-server 的运行内存数据和中下游存储的数据汇聚而成。
下边，大家简易讲解下 Dog UI 上一些较为主要的作用，大家以后再去剖析如何完成对应的作用。
留意：下边的图全是自己画的，并不是确实页面截图，标值上很有可能不太精确。
下面的图实例 transaction 表格：
transaction-type
点一下图中中 type 中的某一项，大家有这一 type 下边每一个 name 的表格。例如点一下 URL，我们可以获得每一个插口的数据统计分析：
transaction-name
自然，图中中点一下实际的 name，也有下一个等级 status 的统计分析数据，这儿就不会3d贴图了。Dog 一共设计方案了 type、name、status 三级特性。
上边2个图上的末尾一列是 sample，它可以引导到 sample 主视图：
sample
Sample 便是抽样的含意，在我们见到有一个插口失误率很高，或是 P90 很高的情况下，你了解出了问题，但因为它仅有统计分析数据，因此你永远不知道究竟哪儿出了问题，这个时候，就必须有一些样版数据了。
大家每分对 type、name、status 的不一样组成各自储存较多 5 个取得成功、5 个不成功、5 个慢解决的样版数据。
点一下里面的 sample 表格中的某一 T、F、L 实际上便会进到到咱们的 trace 主视图，展现出这一要求的全部链接：
trace
根据上边这一 trace 主视图，可以十分迅速地了解是哪个阶段出了问题。
自然，大家以前也说过，大家的 trace 取决于大家的前后端分离丰富度，可是 Dog 是一个 Metrics 为主导的系统，因此它的 Traces 工作能力是远远不够的，但是大多数情形下，针对清查问题应该是充足用的。
针对运用开发人员而言，下边这一 Problem 主视图应该是十分有用的：
problem
它展现了各种各样问题的数据统计分析，而且给予了 sample 让开发人员去清查问题。
最终，大家再简易讲解下 Heartbeat 主视图，它和前边的作用没有什么关联，便是很多的图，大家有 gc、heap、os、thread 等各种各样数据，使我们可以留意到系统的健康情况。
heartbeat-heap
这节关键讲解了一个 APM 系统通常包括什么作用，实际上也非常简单对不对，下面大家从开发商的视角，来聊一聊实际的完成关键点问题。
手机客户端数据实体模型
大伙儿全是开发人员，我便立即一些了，下面的图详细介绍了服务端的数据实体模型：
data-model
针对一条 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，大家稍候再详细介绍。
下边报表实例一下打理数据，那样较为形象化一些：
client
简易详细介绍几个方面內容：
①type 为 URL、SQL、Redis、FeignClient、HttpClient 等这种数据，归属于全自动埋点的范围。
通常做 APM 系统软件的，都需要进行一些全自动埋点的工作中，那样运用开发人员不用做所有的埋点工作中，就能见到许多有用的数据。像最终二行的 type=Order 归属于手动式埋点的数据。
②打理必须需注意 type、name、status 的层面“发生爆炸”，他们的组成过多会十分耗费資源，它有可能会立即压垮大家的 Dog 系统软件。
type 的层面很有可能不容易过多，可是大家也许必须留意开发人员很有可能会乱用 name 和 status，因此大家一定要做 normalize(如 url 可能是带动态性基本参数的，必须恢复出厂设置解决一下)。
③报表中的最终两根是开发人员手动式埋点的数据，通常用于统计特殊的情景，例如想要知道某一方式被启用的状况，启用频次、用时、是不是抛出现异常、入参、传参等。
由于全自动埋点是业务流程不愿关的，冰冷的数据，开发人员很有可能要想埋一些自已要想统计的数据。
④开发人员在手动式埋点的情况下，还能够汇报大量的业务流程有关的数据上去，参照报表最终一列，这种数据可以做项目剖析来用。
例如我是做支付平台的，通常一笔支付订单会涉及特别多的流程(海外的支出和大伙儿日常应用的手机微信、支付宝钱包略微有点儿不一样)，根据汇报每一个连接点的数据，最终我便可以在 Dog 上应用 bizId 来将全部链接串起來，在清查问题的过程中是十分有用的(我们在做付款服务的情况下，付款的通过率并没各位预料的那样高，许多连接点很有可能出问题)。
手机客户端设计方案
上一节大家讲解了一条 message 的数据，这节大家遮盖一下别的內容。
最先，大家详细介绍手机客户端的 API 应用：
上边的编码实例了怎样嵌入应用 Transaction 和 Event，当最表层的 Transaction 在 finally 代码块启用 finish() 的情况下，完成了一棵树的建立，开展信息递送。
大家往 Kafka 中递送的并非一个 Message 案例，由于一次要求会形成许多的 Message 案例，反而是应当机构成 一个 Tree 案例之后开展递送。
下面的图叙述 Tree 的每个属性：
tree
Tree 的属性非常好了解，它拥有 root transaction 的引入，用于解析xml整粒树。此外便是必须带上设备信息内容 messageEnv。
treeId 应当有一个优化算法能确保全局性唯一，简易讲解下 Dog 的完成：${appName}-${encode(ip)}-${现阶段分鐘}-${自增id}。
下边简易详细介绍好多个 tree id 有关的內容，假定一个要求从 A->B->C->D 通过 4 个运用。
A 是通道运用，那麼会出现：
- 一共会出现 4 个 Tree 目标案例从 4 个运用递送到 Kafka，跨运用启用的过程中必须传送 treeId, parentTreeId, rootTreeId 三个主要参数。
- A 运用的 treeId 是全部连接点的 rootTreeId。
- B 运用的 parentTreeId 是 A 的 treeId，同样 C 的 parentTreeId 是 B 运用的 treeId。
- 在跨应用启用的情况下，例如从 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 的內容，这一部分內容实际上非常简单，可是能作出许多五颜六色的数据图表出去，可以完成朝向老总程序编写。
heartbeat-sample
前边大家讲解了 Message 有两个派生类 Event 和 Transaction，这儿让我们再加一个派生类 Heartbeat，用于汇报心率数据。
大家关键整理了 thread、os、gc、heap、client 运作状况(造成多少个 tree，数据尺寸，推送不成功数)等，与此同时也保证了 api 让开发人员自定数据开展汇报。
Dog client 会打开一个后台管理线程，每分运作一次 Heartbeat 搜集程序流程，汇报数据。
再详细介绍细一些。关键构造是一个 Map
有关手机客户端，这儿就讲解这么多了，实际上具体编号流程中，也有一些关键点必须解决。
例如假如一棵树太大要怎么处理，例如沒有 rootTransaction 的状况怎么处理(开发人员只启用了 Dog.logEvent(...))，例如里层嵌入的 transaction 沒有启用 finish 怎么处理这些。
Dog server 设计方案
下面的图实例了 server 的总体设计方案，特别注意的是，大家这儿对线程的应用十分地抑制，图上仅有 3 个工作中线程。
server-design
最先是 Kafka Consumer 线程，它承担大批量消费信息，从 Kafka 群集中消费到的是一个个 Tree 的案例，下面考虑到怎么处理它。
在这儿，大家必须将树形结构构造的 message 平整，大家把这一步称为 deflate，而且做一些预备处理，产生下边的构造：
deflate
下面，大家就将 DeflateTree 各自递送到2个 Disruptor 案例中，大家把 Disruptor 设计方案签单线程生产制造和单线程消费，主要是特性上的考虑到。
消费线程依据 DeflateTree 的特性应用关联好的 Processor 开展解决，例如 DeflateTree 中 List problmes 不以空，与此同时自身关联了 ProblemProcessor，那麼就必须启用 ProblemProcessor 来解决。
科谱時间：Disruptor 是一个性能卓越的序列，性能提升 JDK 中的 BlockingQueue 好些。
这儿大家采用了 2 个 Disruptor 案例，自然还可以考虑到应用大量的案例，那样每一个消费线程关联的 processor 就越来越少。
大家这儿把 Processor 关联到了 Disruptor 案例上，实际上缘故也非常简单，为了更好地特性考虑到，大家想让每一个 processor 仅有单线程应用它。
单线程实际操作可以降低线程转换产生的花销，可以灵活运用到系统缓存，及其在设计方案 processor 的情况下，无需考虑到高并发读写能力的问题。
这儿要考虑到web服务的状况，有一些 processor 是较为消耗 CPU 和运行内存資源的，一定要有效分派，不可以把工作压力最高的好多个每日任务分到同一个线程中来到。
关键的解决逻辑性都是在每个 processor 中，他们承担数据测算。下面，我将每个 processor 必须做的具体内容介绍一下，终究能见到这儿的开发人员，应当真的是对 APM 的数据解决较为有兴趣的。
①Transaction processor
transaction processor 是系统软件工作压力最高的地区，它承担报表统计，尽管 Message 有 Transaction 和 Event 2个关键的派生类，可是在具体的一颗树中，绝大多数的连接点全是 transaction 种类的数据。
transaction-type
下面的图是 transaction processor 内部结构的一个具体的数据构造，最表层是一个時间，大家用分鐘時间来机构，大家最终在分布式锁的情况下，也是依照分鐘来存的。
第二层的 HostKey 意味着哪个运用及其哪个 ip 来的数据，第三层是 type、name、status 的组成。最里层的 Statistics 是人们的数据统计分析控制模块。
transaction-statistics
此外大家还可以见到，这一构造究竟会耗费是多少运行内存，实际上关键在于大家的 type、name、status 的组成也就是 ReportKey 是否会许多，也就是咱们前边在说手机客户端打理的情况下，要防止层面发生爆炸。
最表层构造意味着的是時间的分鐘表明，大家的财务报表是根据每分来开展统计分析的，以后分布式锁到 ClickHouse 中。
可是人们的使用人在看数据的情况下，并不是一分钟一分钟看的，因此必须做数据汇聚。
下边展现两根数据是怎样做汇聚的，在许多数据的情况下，全是依照相同的方式 开展合拼。
transaction-cal
你认真想一想便会发觉，前边好多个数据的测算都没问题，可是 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 的不一样组成，每分一条数据。
②Sample Processor
sample processor 消费 deflate tree 中的 List transactions 和 List<:Event> events 的数据。
大家也是依照分鐘来取样，最后每分，对每一个 type、name、status 的不一样组成，收集较多 5 个取得成功、5 个不成功、5 个慢解决。
相对而言，这一或是比较简单的，它的关键构造如下图：
sample-structure
融合 Sample 的作用看来很容易了解：
sample
③Problem Processor
在做 deflate 的情况下，全部 success=false 的 Message，都是会被放进 List problmes 中，用于做不正确统计分析。
Problem 内部结构的数据构造如下图：
problem-structure
各位看下这种图，实际上也就了解要干什么了，我不唠叨了。在其中 samples 大家每分储存 5 个 treeId。
顺带也再展示下 Problem 的主视图：
problem
有关持久化，我们都是存到了 ClickHouse 中，在其中 sample 用分号连接成一个字符串数组，problem_data 的列如下所示：
④Heartbeat Processor
Heartbeat 解决 List heartbeats 的数据信息，题外话，通常情况下，一颗树里边只有一个 Heartbeat 案例。
前边我就简易提及了一下，大家 Heartbeat 中用于展示数据图表的关键算法设计是一个 Map
搜集到的 key-value 数据信息如下所示所显示：
作为前缀是归类，后缀名是图的名字。手机客户端每分搜集一次数据信息开展汇报，随后就可以做许多的图了，例如下面的图展示了在 heap 归类下的各种各样图：
heartbeat-heap
Heartbeat processor 要做的事非常简单，便是数据储存，Dog UI 上的数据资料是立即从 ClickHouse 中读取数据的。
heartbeat_data 的列如下所示：
⑤MessageTree Processor
前边大家多次提及了 Sample 的作用，这种取样的信息协助大家修复当场，那样我们可以根据 trace 主视图来追踪启用链。
trace
要做上边的这一 trace 主视图，大家必须上中下游的任何的 tree 的数据信息，例如图中是 3 个 tree 案例的数据信息。
以前我们在手机客户端详细介绍的情况下说过，这好多个 tree 根据 parent treeId 和 root treeId 来机构。要做这一主视图，给大家明确提出的考验便是，大家必须储存全量的数据信息。
大伙儿可以想一想这个问题，为什么要储存全量数据信息，大家立即储存被 sample 到的数据信息不就好了没?
这儿大家使用了 Cassandra 的工作能力，Cassandra 在这类 kv 的情景中，有特别好的特性，并且它的维护成本费很低。
大家以 treeId 做为外键约束，此外再加 data 一个列就可以，它是全部 tree 的案例数据信息，基本数据类型是 blob，大家会先做一次 gzip 缩小，随后再丢给 Cassandra。
⑥Business Processor
我们在详细介绍手机客户端的情况下说过，每一个 Message 都能够带上 Business Data，但是仅有运用开发人员自身手动式前后端分离的过程中才会出现。
在我们看到有项目信息的情况下，大家会做另一个事儿，便是把这个数据储存到 ClickHouse 中，用于做项目剖析。
大家实际上不清楚运用开发人员究竟会把它用在什么情景中，由于每一个人承担的新项目都不一样，因此大家只有做一个通用性的数据库系统。
data-model
转过头来看这个图，BusinessData 中大家界定了较为常用的 userId 和 bizId，大家觉得他们可能是每一个业务场景会使用的物品。userId 就别说了，bizId 大伙儿可以用来纪录订单信息 id，付款单 id 等。
随后大家出示了 3 个 String 种类的列 ext1、ext2、ext3 和2个标值种类的列 extVal1 和 extVal2，他们可以用于表述你的业务流程有关的主要参数。
大家的解决自然也比较简单，将这种数据信息存到 ClickHouse 中就可以了，表格中关键有这种列：
这些数据信息对大家 Dog 系统软件而言毫无疑问不认识，由于大家也不知道你表述的是啥业务流程，type、name、status 是开发人员自身界定的，ext1，ext2，ext3 各自1什么意思，我们都不清楚，大家只承担储存和查看。
这种业务流程数据信息十分有效，根据那些数据信息，我们可以做许多的数据分析表出去。由于这篇文章是探讨 APM 的，因此该一部分內容就不会再赘述了。
别的
ClickHouse 必须大批量载入，要不然肯定是撑不下去的，一般一个 batch 最少 10000 行数据信息。
我们在 Kafka 这层操纵了，一个 app_name ip 的数据信息，只能被同一个 dog-server 交易，自然也不是说被好几个 dog-server 交易会有什么问题，可是那样载入 ClickHouse 的数据信息便会大量。
也有个重要的点，前边大家讲了每一个 processor 是由单核开展浏览的，可是有一个问题，那便是来源于 Dog UI 上的要求可该怎么办?
这儿我想了个方法，那便是将要求放进一个 Queue 中，由 Kafka Consumer 那一个进程来交易，它会将每日任务扔到2个 Disruptor 中。
例如这一要求是 transaction 表格要求，在其中一个 Disruptor 的顾客会发觉这个是自身要干的，便会去实行这一每日任务。
总结
假如你掌握 Cat 得话，能够看见 Dog 在许多地区和 Cat 有共同之处，或是直接说“抄”也行，以前大家也考量过立即应用 Cat 或是在 Cat 的根基上做二次开发。
可是我看了 Cat 的源代码后，就放弃了这一念头，细心想一想，仅仅参考 Cat 的数据库系统，随后我们自己写一套 APM 实际上并不是难以，因此拥有大家这一新项目。
写作必须，许多地区我还敷衍塞责，由于这不是哪些源代码剖析的文章内容，没必要随处谈关键点，主要是给阅读者一个全景图片，阅读者能根据我的叙述大概想起必须解决什么事儿，必须写什么编码，那么就在我描述清晰了。
热烈欢迎各位明确提出自个的疑惑或是念头，有不明白或是我有疏漏的地区，热烈欢迎纠正~
创作者：javadoop
编写：陶家龙
来源：www.javadoop.com/post/apm
