Tracing in TiDB 浅谈全链路监控： 从应用到数据库到 Runtime

• 语言: 中文（简体）
• 格式: .pdf
• 来源: github.com/gopherchina

摘要

文档介绍了TiDB中从应用到数据库到Runtime的全链路监控实现方案。核心思想是将Tracer ID和Span Context传递到TiDB内核中。具体做法包括添加Session Variable（如SET @@tidb tracer id=xxxxxx），在应用中将Tracer信息序列化后传递给该变量，在TiDB体系内反序列化生成新Context。TiDB和TiKV之间通过gRPC通信，Jaeger对gRPC有良好支持。文档还通过一个真实故事说明了全链路监控的必要性，并介绍了go tool trace工具及其优缺点。性能测试显示，在sysbench oltp_point_select负载下，profile+labels方案对QPS的损耗约3.1%。

AI总结

该文档介绍了TiDB全链路监控的实现方案，核心是将应用层的分布式追踪信息（如Jaeger的Trace ID和Span Context）传递到数据库内核，以实现从应用到数据库再到Runtime的端到端监控。

**核心思想**：将Tracer ID和Span Context传递到TiDB内核中。

**具体做法**：
1. TiDB新增一个Session Variable（`SET @@tidb tracer id=xxxxxx`），用于接收追踪信息。
2. 在应用程序中，将Trace ID和Span Context序列化为字符串，并通过该Session Variable传递给TiDB。
3. TiDB内部将接收到的字符串反序列化，生成新的Context，从而将追踪信息融入数据库内部处理流程。
4. TiDB与TiKV之间通过gRPC通信，而Jaeger对gRPC有良好支持，便于追踪信息在组件间传递。

**关键工具**：Jaeger client提供了序列化和反序列化的实现方法（`String()`和`ContextFromString()`），简化了集成过程。

**背景与动机**：文档通过一个真实故事说明了全链路监控的必要性：当应用变慢时，前端、后端和DBA可能互相推诿，而缺乏贯穿全链路的追踪信息使得问题定位困难。

**其他监控手段**：
- 文档提到了`go tool trace`，该工具好用但性能损耗大，不适合长期开启。
- 介绍了基于性能分析（profile）和标签（labels）的优化方案，并通过sysbench测试（`oltp_point_select`和`oltp_read_write`）验证了其性能损耗极低（QPS损耗约0.4%-3.1%，延迟损耗约0.8%-3%）。