前言

随着微服务的往多层分布式方向的发展，随着业务的增长，系统的膨胀和升级。问题排查，性能分析，架构优化越来越复杂。因此出现了APM（Application Performance Management）思想，全链路追踪管理。

发展

image.png

名称	出现时间	地址	备注
Dapper	Apr-10	https://bigbully.github.io/Dapper-translation/	谷歌公司发布的一篇论文，全链路追踪系统的思想源头
CAT	2011	https://github.com/dianping/cat	国内开源
Pinpoint	Jul-12	https://github.com/pinpoint-apm/pinpoint	比较比较完善也比较有名的APM系统，页面功能完善，对java友好，不过封装比较死，代码庞大，依赖hbase，迭代开发麻烦
Zipkin	2012	https://zipkin.io/pages/extensions_choices.html	轻量级APM平台
skywalking	2017	https://github.com/apache/skywalking	apache顶级项目，比较成熟，支持opentrace协议
jaeger	2017	https://github.com/jaegertracing/jaeger	CNCF毕业项目，云开发时代新宠，支持opentrace协议
Opentelemetry	2019	https://opentelemetry.io/docs/what-is-opentelemetry/	CNCF提出可观测统一trace，logs，metrics。Opentelemetry 统一OpentTraceing和OpenCensus，统一标准，统一client library（跨语言），collector（支持contrib）

思路

痛点

image.png

借Dapper文章图片可知，在分布式系统的调用中，一次请求会经过庞大系统中的某些服务，如果想观测这一次请求中产生的指标和日志，以及走过的路径，需要如何实现，在快捷快速接入的同时，不对整个分布式系统产生影响是很麻烦的。

数据结构

image.png

通过对一次请求调用的分析和抽象，可以定义这样的一个数据结构。基本上大部分APM系统都是按dapper的思路做的，因此在数据结构上都有相似性。

{
    "trace_id": "一次分布式调用的唯一ID",
    "span_id": "当前执行步骤的唯一ID",
    "span_parent_id": "上一次执行步骤的唯一ID",
    "span_name": "执行步骤名称",
    "start_time": "当前执行步骤的开始时间",
    "end_time": "当前执行步骤的结束时间",
    "tags": "当前执行步骤的一些标签,比如http.method,系统版本",
    "events": "当前执行步骤的一些事件"
}

一些APM系统的架构

Pinpoint

官网定义

image.png

抽象

image.png

数据流程

1，pinpoint采集器采集指标，主要支持java，php。java使用javaagent探针字节码注入的方式，且支持了非常多的中间件包括不仅仅有springboot，netty，kafka等，不过由于pinpoint的开发时间较早，无法支持opentraceing协议。
2，pinpoint agent采集数据后，发送到Pinpoint Collector中。
3，Pinpoint Collector将trace数据写入到hbase中。
4，Pinpoint web查询hbase数据，返回前端客户。

Jaeger

官方定义

image.png

抽象

image.png

数据流程

1，同理agent采集指标。支持opentracing协议。
2，Collector加工数据到存储中。主要存储为elasticsearch，主要存储索引为三个（jaeger-span，jaeger-dependances，jaeger-service）
3，spark，flink二次加工数据到存储中，主要是拓扑图数据。
4，JaegerUI查询存储中的数据返回。如果是要查看指标则使用SPM。需要单独接一个Metrics数据源。

Opentelemetry解决方案

除了pinpoint，jaeger业内还有很多优秀的APM系统，比如skywalking，zipkin等，因此客户在接入一个厂商后，后期的切换和支持非常麻烦。因此CNCF在2019年统一了OpentTraceing和OpenCensus。主要统一的方面有三个。
1，标准，或者说规则。
2，客户端（client library），不同厂商不同的客户端，客户接入一个后就不能接其他的。因此统一了采集器客户端并支持跨语言。
3，collector，通过分析和抽象大部分的APM的架构，基本上都存在一个数据加工的Collector，且都绑定了相应的存储系统。因此Opentelemetry统一了Collector，客户可以支持多种数据源的输入和输出。与存储解耦。

官方定义

image.png

主要有以下几个组件
1）Receivers：
负责接收不同格式的 telemetry data，对于 trace 来说就是 Zipkin、Jaeger、OpenCensus 以及其自研的 OTLP。除此之外，还可以支持从 Kafka 中接收以上格式的数据，可以定制开发。
2）Processors：
负责实施处理逻辑，如打包、过滤、修饰、采样等等，尾部采样逻辑就可以在这里实现。
3）Exporters：
负责将处理后的 telemetry data 按指定的格式重新输出到后端服务中，如 Zipkin、Jaeger、OpenCensus 的 backend，也可以输出到 Kafka 或另一组 collector 中，可以定制开发。
4）Extensions：
提供一些核心流程之外的插件，如分析性能问题的 pprof，健康监测的 health 等等。

使用

Collector模式（推荐）

image.png

部署模式优缺点
1，保证客户流量只需要对内，安全管理方便。
2，中心集群方便做尾采样。
3，权限管理方便。

网关模式

image.png

部署模式优缺点
1，简单方便。
2，客户安全权限控制麻烦。
3，客户端链接过多。网络延迟等。

OTEL业内思路

image.png

一些以OTEL思路开发的参考

1，得物（https://cloud.tencent.com/developer/article/2188712）
2，腾讯（https://cloud.tencent.com/developer/article/1975542?from=article.detail.2188712&areaSource=106000.8&traceId=RdXXf1V3PpCrKgdhSngsS）
3，阿里（https://mp.weixin.qq.com/s/rgms8ROe6o_2ijEZ2g4Xzg）