如何设计一个分布式链路跟踪系统

分享内容

1. 监控行业发展现状
2. TracelD 单次请求标识
3. RPCID 与 SpanlD 链路标识
4. 日志类型定义
5. 日志格式样例
6. 侵入式埋点 SDK 与 AOP 方式埋点
7. 总结

​

分布式链路跟踪服务属于写多读少的服务，是我们线上排查问题的重要支撑。我经历过的一个系统，同时支持着多条业务线，实际用上的服务器有两百台左右，这种量级的系统想排查故障，难度可想而知。

因此，我结合 ELK 特性设计了一套十分简单的全量日志分布式链路跟踪，把日志串了起来，大大降低了系统排查难度。

目前市面上开源提供的分布式链路跟踪都很抽象，当业务复杂到一定程度的时候，为核心系统定制一个符合自己业务需要的链路跟踪，还是很有必要的。

事实上，实现一个分布式链路跟踪并不难，而是难在埋点、数据传输、存储、分析上，如果你的团队拥有这些能力，也可以很快制作出一个链路跟踪系统。所以下面我们一起看看，如何实现一个简单的定制化分布式链路跟踪。

监控行业发展现状

在学习如何制作一个简单的分布式链路跟踪之前，为了更好了解这个链路跟踪的设计特点，我们先简单了解一下监控行业的现状。

最近监控行业有一次大革新，现代的链路跟踪标准已经不拘泥于请求的链路跟踪，目前已经开始进行融合，新的标准和我们定制化的分布式链路跟踪的设计思路很相似，即 Trace、Metrics、日志合并成一套系统进行建设。

三种监控各有千秋

在此之前，常见监控系统主要有三种类型：Metrics、Tracing 和 Logging。

Granfana官网展示的 Metrics

常见的开源 Metrics 有 Zabbix、Nagios、Prometheus、InfluxDb、OpenFalcon，主要做各种量化指标汇总统计，比如监控系统的容量剩余、每秒请求量、平均响应速度、某个时段请求量多少。

常见的开源链路跟踪有 Jaeger、Zipkin、Pinpoint、Skywalking，主要是通过分析每次请求链路监控分析的系统，我们可以通过 TraceID 查找一次请求的依赖及调用链路，分析故障点和传导过程的耗时。

Skywalking官方trace界面

kibana（ELK）官网，日志查找

而常见的开源 Logging 有 ELK、Loki、Loggly，主要是对文本日志的收集归类整理，可以对错误日志进行汇总、警告，并分析系统错误异常等情况。

这三种监控系统可以说是大服务集群监控的主要支柱，它们各有优点，但一直是分别建设的。这让我们的系统监控存在一些割裂和功能重复，而且每一个标准都需要独立建设一个系统，然后在不同界面对同一个故障进行分析，排查问题时十分不便。

随着行业发展，三位一体的标准应运而生，这就是 OpenTelemetry 标准（集成了 OpenCensus、OpenTracing 标准）。这个标准将 Metrics+Tracing+Logging 集成一体，这样我们监控系统的时候就可以通过三个维度综合观测系统运转情况。

常见 OpenTelemetry 开源项目中的 Prometheus、Jaeger 正在遵循这个标准逐步改进实现 OpenTelemetry 实现的结构如下图所示：

OpenTelemetry标准架构

OpenTelemetry技术名词

OpenTelemetry API

• 含义：一组标准化的接口，用于生成和操作可观测性数据。
• 作用：为开发者提供工具来创建和管理追踪、指标和日志数据，确保跨语言和跨平台的一致性。

Semantic Conventions

• 含义：对追踪、指标和日志数据中使用的属性和标签的标准化命名约定。
• 作用：确保不同服务和工具之间的数据具有一致性和可理解性，便于分析和监控。

Tracer

• 含义：用于创建和管理追踪数据的对象。
• 作用：生成和记录追踪数据（traces），每个追踪由一个或多个跨度（spans）组成。

Span Processor

• 含义：处理和导出跨度数据的组件。
• 作用：在跨度数据生成后立即处理这些数据，如过滤、修改或将其传递给导出器（exporter）。

Tracer API

• 含义：用于创建和操作追踪和跨度的编程接口。
• 作用：提供开发者工具来生成和管理追踪数据。

Context API

• 含义：用于管理上下文信息的接口。
• 作用：在不同的代码段和服务之间传递追踪和其他关联信息，确保关联性和一致性。