实现一个全链路监控平台很难吗？Pinpoint、SkyWalking、Zipkin，哪个实现比较好？...

我是「猿码天地」，一个热爱技术、热爱编程的IT猿。技术是开源的，知识是共享的！

写作是对自己学习的总结和记录，如果您对 Java、分布式、微服务、中间件、Spring Boot、Spring Cloud等技术感兴趣，可以关注我的动态，我们一起学习，一起成长！

用知识改变命运，让家人过上更好的生活，互联网人一家亲！

微信搜索「猿码天地」，回复「电子书」白嫖1000本Java开发精华电子书，回复「BAT面试」获取最新国内一线大厂Java面试题！我的微信：zhangbowen125 有任何问题欢迎私聊咨询！

Java知识学堂：https://gitee.com/zhangbw666/it-knowledge

来源：jianshu.com/p/92a12de11f18

推荐文章：

• SpringBoot 集成 SkyWalking：https://www.iocoder.cn/Spring-Boot/SkyWalking/

• SpringCloud 集成 SkyWalking：https://www.iocoder.cn/Spring-Cloud/SkyWalking/

• SpringBoot 集成 Zipkin：https://www.iocoder.cn/Spring-Boot/Zipkin/

• SpringCloud 集成 Zipkin：https://www.iocoder.cn/Spring-Cloud/Spring-Cloud-Sleuth/

• SpringBoot 集成 CAT：https://www.iocoder.cn/Spring-Boot/CAT/

• 0 问题背景

• 1 目标要求

• 2 功能模块

• 3 Google Dapper

  • 3.1 Span

  • 3.2 Trace

  • 3.3 Annotation

  • 3.4 调用示例

• 4 方案比较

  • 4.1 探针的性能

  • 4.2 collector的可扩展性

  • 4.3 全面的调用链路数据分析

  • 4.4 对于开发透明，容易开关

  • 4.5 完整的调用链应用拓扑

  • 4.6 Pinpoint与Zipkin细化比较

• 5 Tracing和Monitor区别

---

0 问题背景

随着微服务架构的流行，服务按照不同的维度进行拆分 ，一次请求往往需要涉及到多个服务。互联网应用构建在不同的软件模块集上 ，这些软件模块，有可能是由不同的团队开发、可能使用不同的编程语言来实现、有可能布在了几千台服务器，横跨多个不同的数据中心 。因此，就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题。

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

所以，在复杂的微服务架构系统中，几乎每一个前端请求都会形成一个复杂的分布式服务调用链路 。一个请求完整调用链可能如下图所示：

一个请求完整调用链

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

1. 如何快速发现问题？

2. 如何判断故障影响范围？

3. 如何梳理服务依赖以及依赖的合理性？

4. 如何分析链路性能问题以及实时容量规划？

同时我们会关注在请求处理期间各个调用的各项性能指标 ，比如：吞吐量（TPS）、响应时间及错误记录等。

1. 吞吐量 ，根据拓扑可计算相应组件、平台、物理设备的实时吞吐量。

2. 响应时间 ，包括整体调用的响应时间和各个服务的响应时间等。

3. 错误记录 ，根据服务返回统计单位时间异常次数。

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

有了全链路监控工具，我们能够达到：

1. 请求链路追踪，故障快速定位 ：可以通过调用链结合业务日志快速定位错误信息。

2. 可视化 ：各个阶段耗时，进行性能分析。

3. 依赖优化 ：各个调用环节的可用性、梳理服务依赖关系以及优化。

4. 数据分析，优化链路 ：可以得到用户的行为路径，汇总分析应用在很多业务场景。

1 目标要求

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

1. 探针的性能消耗

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

2. 代码的侵入性

   即也作为业务组件，应当尽可能少入侵或者无入侵其他业务系统，对于使用方透明，减少开发人员的负担 。

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

3. 可扩展性

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

4. 数据的分析

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

2 功能模块

一般的全链路监控系统，大致可分为四大功能模块：

1. 埋点与生成日志

   埋点即系统在当前节点的上下文信息，可以分为 客户端埋点、服务端埋点，以及客户端和服务端双向型埋点 。埋点日志通常要包含以下内容traceId、spanId、调用的开始时间，协议类型、调用方ip和端口，请求的服务名、调用耗时，调用结果，异常信息等，同时预留可扩展字段，为下