系列目录

本文从 [场景/概念/定义]，演变的统一规范，再到滋生出的各类开源产品，产品的接入，应用案例等的阐述。

涉及到的组件及版本：.NET 6，OpenTelemetry v1.6，SkyWalking v8.9.1，Jaeger v1.51，Prometheus v2.48

一、概念及定义

1.1 面临的场景

现代互联网服务通常被开发成复杂的、大规模的分布式系统。在分布式系统中，一次外部请求往往需要内部多个模块，多个中间件，多台机器或第三方等相互调用才能完成。在这一完整的调用过程中，有串行执行的，也有并行执行的，有关业务走向的，有关处理能力的等等。

  随着微服务和云原生开发的兴起，越来越多应用基于分布式进行开发，但是大型应用拆分为微服务后，服务之间的依赖和调用变得越来越复杂，这些服务是由不同团队开发的软件模块集合构建的，可能使用不同的编程语言，并且可能跨越多个物理设施中的数千台机器，他们之间提供的接口可能不同(RPC/API等)。在这种情况下，我们如何才能快速的确定某次请求都调用了哪些应用？哪些模块？哪些节点？以及它们的先后顺序及各部分的性能如何呢？

1.2 Observability

Observability 可观测性是指如何通过检查系统的运行数据，来了解系统的内部状态。它从各种来源收集和分析数据，以针对环境中运行的应用程序的行为提供详细见解。它可以应用于任何您构建的并希望进行监测的系统。

  可观测性很重要的原因在于 [发现]，借助可观测性，可让软件工程师、IT、DevOps 和项目团队解读遥测数据。借助仪表板、服务依赖关系图和分布式跟踪等可视化功能，甚至 AI 和机器学习方法，轻松完成。有了合适的可观测性解决方案，就可以了解应用程序、服务和基础架构在跟踪和响应问题方面的表现。让团队评估、监测和改进分布式 IT 系统的性能。甚至可以主动诊断、分析问题，并追溯问题根源。 

1.3 应用程序性能监控

Application Performance Monitoring (APM)，观测的一种方式，可观测性的子集。APM 解决方案可收集和监测来自各种网站、软件应用程序和服务的遥测数据，并对数据进行分析。是组织快速识别和解决应用程序和代码中任何性能问题的过程。

  APM 会使用一套工具和方法来监测和管理软件应用程序的性能。APM 工具一般包括对关键指标的监测，以此来识别和诊断性能瓶颈和问题。一些关键的指标例举：请求率/错误率/响应时间/服务实例数/硬件利用率等。设定各指标的范围(如内存剩余低于20%时)，做出响应告警。
如下图监控指标示例：

  APM 还可以提供详细的分布式链路追踪和故障排查信息，也是解决以上面临的场景提出来的问题，将每次分布式请求过程中的每个环节的执行情况，按序/耗时/状态/并串型等，很直观的集中展示出来。协助开发人员了解和修复代码中的问题，快速排查及隐患及预估处理能力等。这通常包括告警和报告功能，以让相关方始终了解应用程序的性能。这种多个节点串联起来的请求过程称为 Tracing。
如下图所示的 Trace、Span、Time 关系图：

Tracing 链路追踪是一种用于分析和监视应用程序的方法，尤其是那些使用微服务体系结构构建的分布式的应用程序。一个完整请求链路的追踪(TraceID)用于查出本次请求调用的所有服务/接口/组件等，调用的每个服务/接口/组件等都被称为跨度(Span)，用来记录调用顺序，上游跨度(ParenetID)用来记录调用的层级关系。调用时间周期Timestamp，是把请求发出、接收、处理的时间都记录下来。跨度还可以记录一些其它属性信息，比如发起调用服务名称、被调服务名称、返回结果、IP、请求状态、日志、故障等。最后再把拥有相同(TraceID)的跨度(Span)合成一个更大范围的试图，就形成了一个完整的单次请求调用链。

通过以上提到的 [监控] [链路]，APM 能够对应用程序的执行情况提供连续不断的详细见解。团队可以利用这些见解，更加积极主动地解决问题，而不是等到客户投诉了才有所行动。APM 有多种用途。例如，团队可以针对用户体验过程中的性能下降设置告警，衡量最新版本的影响，并就哪些地方需要改进做出明智的决策。

总结起来，它可以使得我们发现很多不曾注意到的细节，发现隐蔽的循环依赖，及早的发现问题，定位问题，优化改进，也可以帮助新人理解业务等等。

作者：[Sol·wang] - 博客园，原文出处：https://www.cnblogs.com/Sol-wang/

二、发展及产品

2.1 最初概念

从最初 Google 公司在 Dapper 中提到的 trace、span、annotation 概念：

• Trace：一次完整的分布式调用跟踪链路；
• Span：跨服务的一次调用，多个Span组合成一次Trace记录；
• Annotation：用来记录请求特定事件的相关详细信息及补充；

但 Google-Dapper 并没有开源，它是 Google 内部长期经过打磨后形成的产品，于2010年公布，对外是一篇论文，讲述的是分布式链路追踪的理论和 Dapper 的设计思想。大致由 [植入应用、收集跟踪数据、图形化UI] 三部分组成。后续市场的发展，有很多链路追踪系统也是基于 Dapper 论文的思想和理论为基础的。个人觉得 Google-Dapper 实现了两大方面：监控(发现细微的变化)、跟踪(及时定位并处理)。

2.2 统一规范

于2016年开始的 OpenTracing 项目得到绝大多数相关团队的认可，为分布式追踪，提供统一的概念、规范和接口。它是一个轻量级的标准化层，并不是功能实现代码，它只是为跟踪数据，用代码定义了一套数据模型，和一套API，是供统一遵循的规范，用于在应用程序中创建和管理这些数据模型。现在大多数链路跟踪产品系统都在尽量兼容遵循 OpenTracing 设计原则。