关于后端:牛逼哄哄的全链路监控系统搭建起来也没有想象中的那么难啊

问题背景

随着微服务架构的风行，服务依照不同的维度进行拆分，一次申请往往须要波及到多个服务。互联网利用构建在不同的软件模块集上，这些软件模块，有可能是由不同的团队开发、可能应用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心。因而，就须要一些能够帮忙了解零碎行为、用于剖析性能问题的工具，以便产生故障的时候，可能疾速定位和解决问题。

全链路监控组件就在这样的问题背景下产生了。最闻名的是谷歌公开的论文提到的 Google Dapper。想要在这个上下文中了解分布式系统的行为，就须要监控那些横跨了不同的利用、不同的服务器之间的关联动作。

所以，在简单的微服务架构零碎中，简直每一个前端申请都会造成一个简单的分布式服务调用链路。一个申请残缺调用链可能如下图所示：

一个申请残缺调用链

那么在业务规模一直增大、服务一直增多以及频繁变更的状况下，面对简单的调用链路就带来一系列问题：

• 如何疾速发现问题？
• 如何判断故障影响范畴？
• 如何梳理服务依赖以及依赖的合理性？
• 如何剖析链路性能问题以及实时容量布局？

同时咱们会关注在申请解决期间各个调用的各项性能指标，比方：吞吐量（TPS）、响应工夫及谬误记录等。

• 吞吐量，依据拓扑可计算相应组件、平台、物理设施的实时吞吐量。
• 响应工夫，包含整体调用的响应工夫和各个服务的响应工夫等。
• 谬误记录，依据服务返回统计单位工夫异样次数。

全链路性能监控 从整体维度到部分维度展现各项指标，将跨利用的所有调用链性能信息集中展示，可不便度量整体和部分性能，并且不便找到故障产生的源头，生产上可极大缩短故障排除工夫。

有了全链路监控工具，咱们可能达到：

• 申请链路追踪，故障疾速定位：能够通过调用链联合业务日志疾速定位错误信息。
• 可视化：各个阶段耗时，进行性能剖析。
• 依赖优化：各个调用环节的可用性、梳理服务依赖关系以及优化。
• 数据分析，优化链路：能够失去用户的行为门路，汇总剖析利用在很多业务场景。

指标要求

如上所述，那么咱们抉择全链路监控组件有哪些指标要求呢？Google Dapper 中也提到了，总结如下：

探针的性能耗费

APM 组件服务的影响应该做到足够小。服务调用埋点自身会带来性能损耗，这就须要调用跟踪的低损耗，理论中还会通过配置采样率的形式，抉择一部分申请去剖析申请门路。在一些高度优化过的服务，即便一点点损耗也会很容易察觉到，而且有可能迫使在线服务的部署团队不得不将跟踪零碎关停。

代码的侵入性

即也作为业务组件，该当尽可能少入侵或者无入侵其余业务零碎，对于应用方通明，缩小开发人员的累赘。

对于利用的程序员来说，是不须要晓得有跟踪零碎这回事的。如果一个跟踪零碎想失效，就必须须要依赖利用的开发者被动配合，那么这个跟踪零碎也太软弱了，往往因为跟踪零碎在利用中植入代码的 bug 或忽略导致利用出问题，这样才是无奈满足对跟踪零碎“无所不在的部署”这个需要。

可扩展性

一个优良的调用跟踪零碎必须反对分布式部署，具备良好的可扩展性。可能反对的组件越多当然越好。或者提供便捷的插件开发 API，对于一些没有监控到的组件，利用开发者也能够自行扩大。

数据的剖析

数据的剖析要快，剖析的维度尽可能多。跟踪零碎能提供足够快的信息反馈，就能够对生产环境下的异样情况做出快速反应。剖析的全面，可能防止二次开发。

功能模块

个别的全链路监控零碎，大抵可分为四大功能模块：

埋点与生成日志

埋点即零碎在以后节点的上下文信息，能够分为 客户端埋点、服务端埋点，以及客户端和服务端双向型埋点。埋点日志通常要蕴含以下内容 traceId、spanId、调用的开始工夫，协定类型、调用方 ip 和端口，申请的服务名、调用耗时，调用后果，异样信息等，同时预留可扩大字段，为下一步扩大做筹备；

• 不能造成性能累赘：一个价值未被验证，却会影响性能的货色，是很难在公司推广的！
• 因为要写 log，业务 QPS 越高，性能影响越重。通过采样和异步 log 解决。

收集和存储日志

次要反对分布式日志采集的计划，同时减少 MQ 作为缓冲；

• 每个机器上有一个 deamon 做日志收集，业务过程把本人的 Trace 发到 daemon，daemon 把收集 Trace 往上一级发送；
• 多级的 collector，相似 pub/sub 架构，能够负载平衡；
• 对聚合的数据进行 实时剖析和离线存储；
• 离线剖析 须要将同一条调用链的日志汇总在一起；

剖析和统计调用链路数据，以及时效性

调用链跟踪剖析：把同一 TraceID 的 Span 收集起来，按工夫排序就是 timeline。把 ParentID 串起来就是调用栈。

抛异样或者超时，在日志里打印 TraceID。利用 TraceID 查问调用链状况，定位问题。

依赖度量：

• 离线剖析：按 TraceID 汇总，通过 Span 的 ID 和 ParentID 还原调用关系，剖析链路状态。
• 实时剖析：对单条日志间接剖析，不做汇总，重组。失去以后 QPS，提早。
• 强依赖：调用失败会间接中断主流程
• 高度依赖：一次链路中调用某个依赖的几率高
• 频繁依赖：一次链路调用同一个依赖的次数多
• 展示以及决策反对

Google Dapper

Span

根本工作单元，一次链路调用（能够是 RPC，DB 等没有特定的限度）创立一个 span，通过一个 64 位 ID 标识它，uuid 较为不便，span 中还有其余的数据，例如形容信息，工夫戳，key-value 对的（Annotation）tag 信息，parent_id 等, 其中 parent-id 能够示意 span 调用链路起源。

上图阐明了 span 在一次大的跟踪过程中是什么样的。Dapper 记录了 span 名称，以及每个 span 的 ID 和父 ID，以重建在一次追踪过程中不同 span 之间的关系。如果一个 span 没有父 ID 被称为 root span。所有 span 都挂在一个特定的跟踪上，也共用一个跟踪 id。

Span 数据结构：

type Span struct {
    TraceID    int64 // 用于标示一次残缺的申请 id
    Name       string
    ID         int64 // 以后这次调用 span_id
    ParentID   int64 // 下层服务的调用 span_id  最上层服务 parent_id 为 null
    Annotation []Annotation // 用于标记的工夫戳
    Debug      bool
}

Trace

相似于 树结构的 Span 汇合，示意一次残缺的跟踪，从申请到服务器开始，服务器返回 response 完结，跟踪每次 rpc 调用的耗时，存在惟一标识 trace_id。比方：你运行的分布式大数据存储一次 Trace 就由你的一次申请组成。

每种色彩的 note 标注了一个 span，一条链路通过 TraceId 惟一标识，Span 标识发动的申请信息。树节点是整个架构的根本单元，而每一个节点又是对 span 的援用。节点之间的连线示意的 span 和它的父 span 间接的关系。尽管 span 在日志文件中只是简略的代表 span 的开始和完结工夫，他们在整个树形构造中却是绝对独立的。

Annotation

注解，用来记录申请特定事件相干信息（例如工夫），一个 span 中会有多个 annotation 注解形容。通常蕴含四个注解信息：

(1) cs：Client Start，示意客户端发动申请 (2) sr：Server Receive，示意服务端收到申请 (3) ss：Server Send，示意服务端实现解决，并将后果发送给客户端 (4) cr：Client Received，示意客户端获取到服务端返回信息

Annotation 数据结构：

type Annotation struct {
    Timestamp int64
    Value     string
    Host      Endpoint
    Duration  int32
}

调用示例

• 申请调用示例

当用户发动一个申请时，首先达到前端 A 服务，而后别离对 B 服务和 C 服务进行 RPC 调用；
B 服务解决完给 A 做出响应，然而 C 服务还须要和后端的 D 服务和 E 服务交互之后再返还给 A 服务，最初由 A 服务来响应用户的申请；

• 调用过程追踪

整个调用过程追踪

• 申请到来生成一个全局 TraceID，通过 TraceID 能够串联起整个调用链，一个 TraceID 代表一次申请。
• 除了 TraceID 外，还须要 SpanID 用于记录调用父子关系。每个服务会记录下 parent id 和 span id，通过他们能够组织一次残缺调用链的父子关系。
• 一个没有 parent id 的 span 成为 root span，能够看成调用链入口。
• 所有这些 ID 可用全局惟一的 64 位整数示意；
• 整个调用过程中每个申请都要透传 TraceID 和 SpanID。
• 每个服务将该次申请附带的 TraceID 和附带的 SpanID 作为 parent id 记录下，并且将本人生成的 SpanID 也记录下。
• 要查看某次残缺的调用则 只有依据 TraceID 查出所有调用记录，而后通过 parent id 和 span id 组织起整个调用父子关系。

• 调用链外围工作

  • 调用链数据生成，对整个调用过程的所有利用进行埋点并输入日志。
  • 调用链数据采集，对各个利用中的日志数据进行采集。
  • 调用链数据存储及查问，对采集到的数据进行存储，因为日志数据量个别都很大，不仅要能对其存储，还须要能提供疾速查问。
  • 指标运算、存储及查问，对采集到的日志数据进行各种指标运算，将运算后果保存起来。
  • 告警性能，提供各种阀值正告性能。
• 整体部署架构

• 通过 AGENT 生成调用链日志。
• 通过 logstash 采集日志到 kafka。
• kafka 负责提供数据给上游生产。
• storm 计算汇聚指标后果并落到 es。
• storm 抽取 trace 数据并落到 es，这是为了提供比较复杂的查问。比方通过工夫维度查问调用链，能够很快查问出所有合乎的 traceID，依据这些 traceID 再去 Hbase 查数据就快了。
• logstash 将 kafka 原始数据拉取到 hbase 中。hbase 的 rowkey 为 traceID，依据 traceID 查问是很快的。
• AGENT 无侵入部署

通过 AGENT 代理无侵入式部署，将性能测量与业务逻辑齐全拆散，能够测量任意类的任意办法的执行工夫，这种形式大大提高了采集效率，并且缩小运维老本。依据服务跨度次要分为两大类 AGENT：

服务内 AGENT，这种形式是通过 Java 的 agent 机制，对服务外部的办法调用档次信息进行数据收集，如办法调用耗时、入参、出参等信息。

跨服务 AGENT，这种状况须要对支流 RPC 框架以插件模式提供无缝反对。并通过提供规范数据标准以适应自定义 RPC 框架：

• （1）Dubbo 反对；
• （2）Rest 反对；
• （3）自定义 RPC 反对；

调用链监控益处

• 精确把握生产一线利用部署状况；
• 从调用链全流程性能角度，辨认对要害调用链，并进行优化；
• 提供可追溯的性能数据，量化 IT 运维部门业务价值；
• 疾速定位代码性能问题，帮助开发人员持续性的优化代码；
• 帮助开发人员进行白盒测试，缩短零碎上线稳定期；

计划比拟

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

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

以上三种全链路监控计划须要比照的项提炼进去：

探针的性能

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

collector 的可扩展性

可能程度扩大以便反对大规模服务器集群。

全面的调用链路数据分析

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

对于开发通明，容易开关

增加新性能而无需批改代码，容易启用或者禁用。

残缺的调用链利用拓扑

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

探针的性能

比拟关注探针的性能，毕竟 APM 定位还是工具，如果启用了链路监控组建后，间接导致吞吐量升高过半，那也是不能承受的。对 skywalking、zipkin、pinpoint 进行了压测，并与基线（未应用探针）的状况进行了比照。

选用了一个常见的基于 Spring 的应用程序，他蕴含 Spring Boot, Spring MVC，redis 客户端，mysql。监控这个应用程序，每个 trace，探针会抓取 5 个 span(1 Tomcat, 1 SpringMVC, 2 Jedis, 1 Mysql)。这边根本和 skywalkingtest 的测试利用差不多。

模仿了三种并发用户：500，750，1000。应用 jmeter 测试，每个线程发送 30 个申请，设置思考工夫为 10ms。应用的采样率为 1，即 100%，这边与生产可能有差异。pinpoint 默认的采样率为 20，即 50%，通过设置 agent 的配置文件改为 100%。zipkin 默认也是 1。组合起来，一共有 12 种。上面看下汇总表：

探针性能比照

从上表能够看出，在三种链路监控组件中，skywalking 的探针对吞吐量的影响最小，zipkin 的吞吐量居中。pinpoint 的探针对吞吐量的影响较为显著，在 500 并发用户时，测试服务的吞吐量从 1385 升高到 774，影响很大。而后再看下 CPU 和 memory 的影响，在外部服务器进行的压测，对 CPU 和 memory 的影响都差不多在 10% 之内。

collector 的可扩展性

collector 的可扩展性，使得可能程度扩大以便反对大规模服务器集群。

• zipkin

开发 zipkin-Server（其实就是提供的开箱即用包），zipkin-agent 与 zipkin-Server 通过 http 或者 mq 进行通信，http 通信会对失常的拜访造成影响，所以还是举荐基于 mq 异步形式通信，zipkin-Server 通过订阅具体的 topic 进行生产。这个当然是能够扩大的，多个 zipkin-Server 实例进行异步生产 mq 中的监控信息。

• skywalking

skywalking 的 collector 反对两种部署形式：单机和集群模式。collector 与 agent 之间的通信应用了 gRPC。

• pinpoint

同样，pinpoint 也是反对集群和单机部署的。pinpoint agent 通过 thrift 通信框架，发送链路信息到 collector。

全面的调用链路数据分析

全面的调用链路数据分析，提供代码级别的可见性以便轻松定位失败点和瓶颈。

• zipkin

zipkin 链路调用剖析

zipkin 的链路监控粒度绝对没有那么细，从上图能够看到调用链中具体到接口级别，再进一步的调用信息并未波及。

• skywalking

skywalking 链路调用剖析

skywalking 还反对 20+ 的中间件、框架、类库，比方：支流的 dubbo、Okhttp，还有 DB 和消息中间件。上图 skywalking 链路调用剖析截取的比较简单，网关调用 user 服务，因为反对泛滥的中间件，所以 skywalking 链路调用剖析比 zipkin 齐备些。

• pinpoint

pinpoint 链路调用剖析

pinpoint 应该是这三种 APM 组件中，数据分析最为齐备的组件。提供代码级别的可见性以便轻松定位失败点和瓶颈，上图能够看到对于执行的 sql 语句，都进行了记录。还能够配置报警规定等，设置每个利用对应的负责人，依据配置的规定报警，反对的中间件和框架也比拟齐备。

对于开发通明，容易开关

对于开发通明，容易开关，增加新性能而无需批改代码，容易启用或者禁用。咱们冀望性能能够不批改代码就工作并心愿失去代码级别的可见性。

对于这一点，Zipkin 应用批改过的类库和它本人的容器 (Finagle) 来提供分布式事务跟踪的性能。然而，它要求在须要时批改代码。skywalking 和 pinpoint 都是基于字节码加强的形式，开发人员不须要批改代码，并且能够收集到更多准确的数据因为有字节码中的更多信息。

残缺的调用链利用拓扑

自动检测利用拓扑，帮忙你搞清楚利用的架构。

pinpoint 链路拓扑

skywalking 链路拓扑

zipkin 链路拓扑

下面三幅图，别离展现了 APM 组件各自的调用拓扑，都能实现残缺的调用链利用拓扑。相对来说，pinpoint 界面显示的更加丰盛，具体到调用的 DB 名，zipkin 的拓扑局限于服务于服务之间。

Pinpoint 与 Zipkin 细化比拟

• Pinpoint 与 Zipkin 差异性

  • Pinpoint 是一个残缺的性能监控解决方案：有从探针、收集器、存储到 Web 界面等全套体系；而 Zipkin 只偏重收集器和存储服务，尽管也有用户界面，但其性能与 Pinpoint 不可同日而语。反而 Zipkin 提供有 Query 接口，更弱小的用户界面和系统集成能力，能够基于该接口二次开发实现。
  • Zipkin 官网提供有基于 Finagle 框架（Scala 语言）的接口，而其余框架的接口由社区奉献，目前能够反对 Java、Scala、Node、Go、Python、Ruby 和 C# 等支流开发语言和框架；然而 Pinpoint 目前只有官网提供的 Java Agent 探针，其余的都在申请社区声援中（请参见 #1759 和 #1760）。
  • Pinpoint 提供有 Java Agent 探针，通过字节码注入的形式实现调用拦挡和数据收集，能够做到真正的代码无侵入，只须要在启动服务器的时候增加一些参数，就能够实现探针的部署；而 Zipkin 的 Java 接口实现 Brave，只提供了根本的操作 API，如果须要与框架或者我的项目集成的话，就须要手动增加配置文件或减少代码。
  • Pinpoint 的后端存储基于 HBase，而 Zipkin 基于 Cassandra。

• Pinpoint 与 Zipkin 相似性

  • Pinpoint 与 Zipkin 都是基于 Google Dapper 的那篇论文，因而实践根底大致相同。两者都是将服务调用拆分成若干有级联关系的 Span，通过 SpanId 和 ParentSpanId 来进行调用关系的级联；最初再将整个调用链流经的所有的 Span 汇聚成一个 Trace，报告给服务端的 collector 进行收集和存储。
  • 即使在这一点上，Pinpoint 所采纳的概念也不齐全与那篇论文统一。比方他采纳 TransactionId 来取代 TraceId，而真正的 TraceId 是一个构造，外面蕴含了 TransactionId, SpanId 和 ParentSpanId。而且 Pinpoint 在 Span 上面又减少了一个 SpanEvent 构造，用来记录一个 Span 外部的调用细节（比方具体的办法调用等等），因而 Pinpoint 默认会比 Zipkin 记录更多的跟踪数据。然而实践上并没有限定 Span 的粒度大小，所以一个服务调用能够是一个 Span，那么每个服务中的办法调用也能够是个 Span，这样的话，其实 Brave 也能够跟踪到办法调用级别，只是具体实现并没有这样做而已。

• 字节码注入 vs API 调用

  • Pinpoint 实现了基于字节码注入的 Java Agent 探针，而 Zipkin 的 Brave 框架仅仅提供了利用层面的 API，然而细想问题远不那么简略。字节码注入是一种简略粗犷的解决方案，实践上来说无论任何办法调用，都能够通过注入代码的形式实现拦挡，也就是说没有实现不了的，只有不会实现的。但 Brave 则不同，其提供的利用层面的 API 还须要框架底层驱动的反对，能力实现拦挡。比方，MySQL 的 JDBC 驱动，就提供有注入 interceptor 的办法，因而只须要实现 StatementInterceptor 接口，并在 Connection String 中进行配置，就能够很简略的实现相干拦挡；而与此绝对的，低版本的 MongoDB 的驱动或者是 Spring Data MongoDB 的实现就没有如此接口，想要实现拦挡查问语句的性能，就比拟艰难。
  • 因而在这一点上，Brave 是硬伤，无论应用字节码注入如许艰难，但至多也是能够实现的，然而 Brave 却有无从下手的可能，而且是否能够注入，可能多大程度上注入，更多的取决于框架的 API 而不是本身的能力。

• 难度及老本

  • 通过简略浏览 Pinpoint 和 Brave 插件的代码，能够发现两者的实现难度有天壤之别。在都没有任何开发文档撑持的前提下，Brave 比 Pinpoint 更容易上手。Brave 的代码量很少，外围性能都集中在 brave-core 这个模块下，一个中等水平的开发人员，能够在一天之内读懂其内容，并且能对 API 的构造有十分清晰的意识。
  • Pinpoint 的代码封装也是十分好的，尤其是针对字节码注入的下层 API 的封装十分杰出，然而这仍然要求浏览人员对字节码注入多少有一些理解，尽管其用于注入代码的外围 API 并不多，但要想理解透彻，恐怕还得深刻 Agent 的相干代码，比方很难高深莫测的了解 addInterceptor 和 addScopedInterceptor 的区别，而这两个办法就是位于 Agent 的无关类型中。
  • 因为 Brave 的注入须要依赖底层框架提供相干接口，因而并不需要对框架有一个全面的理解，只须要晓得能在什么中央注入，可能在注入的时候获得什么数据就能够了。就像下面的例子，咱们基本不须要晓得 MySQL 的 JDBC Driver 是如何实现的也能够做到拦挡 SQL 的能力。然而 Pinpoint 就不然，因为 Pinpoint 简直能够在任何中央注入任何代码，这须要开发人员对所需注入的库的代码实现有十分深刻的理解，通过查看其 MySQL 和 Http Client 插件的实现就能够洞察这一点，当然这也从另外一个层面阐明 Pinpoint 的能力的确能够十分弱小，而且其默认实现的很多插件曾经做到了十分细粒度的拦挡。
  • 针对底层框架没有公开 API 的时候，其实 Brave 也并不齐全机关用尽，咱们能够采取 AOP 的形式，一样可能将相干拦挡注入到指定的代码中，而且显然 AOP 的利用要比字节码注入简略很多。
  • 以上这些间接关系到实现一个监控的老本，在 Pinpoint 的官网技术文档中，给出了一个参考数据。如果对一个系统集成的话，那么用于开发 Pinpoint 插件的老本是 100，将此插件集成入零碎的老本是 0；但对于 Brave，插件开发的老本只有 20，而集成老本是 10。从这一点上能够看出官网给出的老本参考数据是 5:1。然而官网又强调了，如果有 10 个零碎须要集成的话，那么总成本就是 10 * 10 + 20 = 120，就超出了 Pinpoint 的开发成本 100，而且须要集成的服务越多，这个差距就越大。

• 通用性和扩展性

  • 很显然，这一点上 Pinpoint 齐全处于劣势，从社区所开发进去的集成接口就可见一斑。
  • Pinpoint 的数据接口不足文档，而且也不太规范（参考论坛探讨帖），须要浏览很多代码才可能实现一个本人的探针（比方 Node 的或者 PHP 的）。而且团队为了性能思考应用了 Thrift 作为数据传输协定规范，比起 HTTP 和 JSON 而言难度减少了不少。

• 社区反对

  • 这一点也不用多说，Zipkin 由 Twitter 开发，能够算得上是明星团队，而 Naver 的团队只是一个石破天惊的小团队（从 #1759 的探讨中能够看出）。尽管说这个我的项目在短期内不太可能隐没或进行更新，但毕竟不如前者用起来更加释怀。而且没有更多社区开发进去的插件，让 Pinpoint 只依附团队本身的力量实现诸多框架的集成实属艰难，而且他们目前的工作重点仍然是在晋升性能和稳定性上。

• 其余

  • Pinpoint 在实现之初就思考到了性能问题，www.naver.com 网站的后端某些服务每天要解决超过 200 亿次的申请，因而他们会抉择 Thrift 的二进制变长编码格局、而且应用 UDP 作为传输链路，同时在传递常量的时候也尽量应用数据参考字典，传递一个数字而不是间接传递字符串等等。这些优化也减少了零碎的复杂度：包含应用 Thrift 接口的难度、UDP 数据传输的问题、以及数据常量字典的注册问题等等。
  • 相比之下，Zipkin 应用相熟的 Restful 接口加 JSON，简直没有任何学习老本和集成难度，只有晓得数据传输构造，就能够轻易的为一个新的框架开发出相应的接口。
  • 另外 Pinpoint 不足针对申请的采样能力，显然在大流量的生产环境下，不太可能将所有的申请全副记录，这就要求对申请进行采样，以决定什么样的申请是我须要记录的。Pinpoint 和 Brave 都反对采样百分比，也就是百分之多少的申请会被记录下来。然而，除此之外 Brave 还提供了 Sampler 接口，能够自定义采样策略，尤其是当进行 A/B 测试的时候，这样的性能就十分有意义了。

• 总结

  • 从短期指标来看，Pinpoint 的确具备压倒性的劣势：无需对我的项目代码进行任何改变就能够部署探针、追踪数据细粒化到办法调用级别、功能强大的用户界面以及简直比拟全面的 Java 框架反对。然而久远来看，学习 Pinpoint 的开发接口，以及将来为不同的框架实现接口的老本都还是个未知数。相同，把握 Brave 就绝对容易，而且 Zipkin 的社区更加弱小，更有可能在将来开发出更多的接口。在最坏的状况下，咱们也能够本人通过 AOP 的形式增加适宜于咱们本人的监控代码，而并不需要引入太多的新技术和新概念。而且在将来业务发生变化的时候，Pinpoint 官网提供的报表是否能满足要求也不好说，减少新的报表也会带来不能够预测的工作难度和工作量。

Tracing 和 Monitor 区别

Monitor 可分为系统监控和利用监控。系统监控比方 CPU，内存，网络，磁盘等等整体的零碎负载的数据，细化可具体到各过程的相干数据。这一类信息是间接能够从零碎中失去的。利用监控须要利用提供反对，裸露了相应的数据。比方利用外部申请的 QPS，申请解决的延时，申请解决的 error 数，音讯队列的队列长度，解体状况，过程垃圾回收信息等等。Monitor 次要指标是发现异常，及时报警。

Tracing 的根底和外围都是调用链。相干的 metric 大多都是围绕调用链分析失去的。Tracing 次要指标是系统分析。提前找到问题比呈现问题后再去解决更好。

Tracing 和利用级的 Monitor 技术栈上有很多共同点。都有数据的采集，剖析，存储和展式。只是具体收集的数据维度不同，剖析过程不一样。

作者：七寸知架构
起源：https://www.jianshu.com/p/92a…