APM-Trace全链路追踪管理

APM-Trace全链路追踪管理是一种针对分布式系统，特别是微服务架构下的问题排查、性能分析和架构优化的解决方案。以下是对APM-Trace全链路追踪管理的详细介绍：

随着微服务向多层分布式方向发展，以及业务的增长和系统的膨胀升级，问题排查、性能分析和架构优化变得越来越复杂。为了应对这些挑战，APM（Application Performance Management）思想应运而生，并逐渐发展出全链路追踪管理的概念。

• Dapper：2010年4月，谷歌公司发布了一篇论文，提出了全链路追踪系统的思想源头，为后续的APM系统发展奠定了基础。
• CAT：2011年，国内开源了CAT系统，为APM领域的发展做出了贡献。
• Pinpoint：2012年7月，Pinpoint作为一个比较完善且有名的APM系统出现，对Java友好，但封装较死，代码庞大，依赖hbase，迭代开发麻烦。
• Zipkin：同样在2012年，Zipkin作为一个轻量级APM平台出现，为开发者提供了另一种选择。
• Skywalking：2017年，Skywalking成为apache顶级项目，比较成熟，且支持opentrace协议。
• Jaeger：也在2017年，Jaeger作为CNCF毕业项目，成为云开发时代的新宠，同样支持opentrace协议。
• Opentelemetry：2019年，CNCF提出了可观测统一trace、logs、metrics的Opentelemetry，统一了OpentTraceing和OpenCensus，为APM领域带来了新的标准和发展方向。

• 痛点：在分布式系统的调用中，一次请求会经过庞大系统中的某些服务。为了观测这次请求中产生的指标和日志，以及走过的路径，需要在快捷快速接入的同时，不对整个分布式系统产生影响，这是一个复杂的挑战。

• 数据结构：通过对一次请求调用的分析和抽象，可以定义一个数据结构来描述全链路追踪的信息。这个数据结构基本上遵循了Dapper的思路，并在大多数APM系统中都有相似性。以下是一个典型的数据结构示例：

• 官网定义：Pinpoint是一个针对大型分布式系统的APM工具，提供了对Java和PHP应用的深度追踪和性能分析。

• 数据流程：

  Pinpoint采集器采集指标，主要支持Java和PHP。Java使用javaagent探针字节码注入的方式，支持了非常多的中间件，包括Spring Boot、Netty、Kafka等。但由于开发时间较早，无法支持opentraceing协议。

  Pinpoint agent采集数据后，发送到Pinpoint Collector中。

  Pinpoint Collector将trace数据写入到hbase中。

  Pinpoint web查询hbase数据，返回前端客户。

• 官网定义：Jaeger是一个开源的端到端分布式追踪系统，用于监控和排查微服务架构中的性能问题。

• 数据流程：

  Agent采集指标，支持opentracing协议。

  Collector加工数据到存储中，主要存储为elasticsearch，主要存储索引为三个（jaeger-span、jaeger-dependances、jaeger-service）。

  Spark或Flink二次加工数据到存储中，主要是拓扑图数据。

  JaegerUI查询存储中的数据返回。如果要查看指标则使用SPM，需要单独接一个Metrics数据源。

Opentelemetry是CNCF在2019年统一了OpentTraceing和OpenCensus的产物，主要解决了客户在接入一个厂商后，后期切换和支持麻烦的问题。Opentelemetry的统一主要体现在三个方面：标准、客户端（client library）和collector。

• 标准：统一了规则，使得不同厂商的系统能够遵循相同的标准进行开发和集成。
• 客户端：统一了采集器客户端，并支持跨语言，使得客户能够更灵活地选择和使用不同的客户端。
• Collector：通过分析和抽象大部分的APM架构，统一了Collector，支持多种数据源的输入和输出，与存储解耦，使得客户能够更灵活地管理和使用数据。

• 官方定义：Opentelemetry是一个可观测性框架，用于生成、收集和处理telemetry data（包括trace、logs和metrics）。
• 主要组件：

  Receivers：负责接收不同格式的telemetry data，如Zipkin、Jaeger、OpenCensus以及其自研的OTLP等。还可以支持从Kafka中接收以上格式的数据，并可以定制开发。

  Processors：负责实施处理逻辑，如打包、过滤、修饰、采样等。尾部采样逻辑就可以在这里实现。

  Exporters：负责将处理后的telemetry data按指定的格式重新输出到后端服务中，如Zipkin、Jaeger、OpenCensus的backend，也可以输出到Kafka或另一组collector中，并可以定制开发。

  Extensions：提供一些核心流程之外的插件，如分析性能问题的pprof、健康监测的health等。

• Collector模式（推荐）：

  部署模式特点：

  保证客户流量只需要对内，安全管理方便。

  中心集群方便做尾采样。

  权限管理方便。

• 网关模式：

  部署模式特点：

  简单方便。

  客户安全权限控制麻烦。

  客户端链接过多，可能导致网络延迟等问题。