摘要：作为一款优秀的开源分布式数据库软件，TiDB 得到越来越多的用户关注和应用，但在运维保障过程中同样面临着运维孤岛、定界定位难、获取可观测性数据开销大等挑战，本文总结了 TiDB 用户如何基于 DeepFlow 构建全栈可观测性的最佳实践，包括如何用 DeepFlow 高性能、零侵扰的可观测技术消除全链路追踪在 TiDB 侧的盲区，如何在 DeepFlow 中统一观测业务全景、SQL 事务全过程、网络性能、系统资源性能、文件读写性能、应用函数性能，从而为 TiDB 及其上应用构建出统一、立体、全方位的可观测性能力。
01
分布式数据库的运维挑战
在日常运维中，分布式数据库的 DBA 通常面临着三个方面的挑战：
观测数据实时性：由于传统插桩方法会带来明显的性能损耗，DBA 仅在出现业务异常后才会启用 TiDB 内置的分布式追踪能力，故障处置时只能事后分析、反复复现、被动定位。 观测数据全面性：传统数据库运维主要依赖数据库自身数据，缺乏客户端应用、系统资源、数据库文件读写、服务器网络性能等维度的实时数据，周遭环境处于诊断盲区。 观测诊断连续性：传统监控工具相互之间数据割裂，故障诊断经常需要在不同运维团队之间流转，分析过程经常需要在多个监控工具之间切换，诊断连续性经常中断。
以上问题导致数据库运维与其他运维的脱节，形成运维孤岛，业务运行风险难发现、故障难定界、恢复周期长、沟通协作多、运维矛盾多。
DeepFlow 通过零侵扰、高性能的观测数据采集、开放的观测数据接入、统一的观测数据关联分析等多项核心能力，为 TiDB 提供了全栈、全链路、可生产落地的观测能力，帮助 DBA 构建全链路监控、故障快速定界、根因分析等能力，有效提升分布式数据库运维效率，解决上述运维痛点。
02
TiDB 可观测性部署方案
TiDB 可观测性实践方案中，我们在业务集群和 TiDB 分布式数据库集群的 Node 内自动化部署了 DeepFlow Agent，采集、收集多维度的观测数据；结构化之后的观测数据经过网络传输，通过统一处理（统一标记数据标签，统一关联数据，统一分析数据），集中存储于 DeepFlow Server 端；通过紧贴运维场景的功能设计，基于这些数据提供从宏观到微观、灵活、多维度的全栈观测分析能力。
DeepFlow Agent 采集、收集丰富的观测数据，具体包括：
eBPF 零侵扰数据：调用链追踪、SQL 性能指标、SQL 调用日志、网络性能指标、网络流日志、文件读写事件、CPU Perf 等观测数据 OpenTelemetry 插桩数据：TiDB 各组件内部的调用链追踪数据 Prometheus Exporter 数据：K8s 系统指标、TiDB 性能指标
03
调用链追踪
在 DeepFlow 对 TiDB 的全栈观测实践中，我们通过 eBPF 技术实现了包括前端应用、中间网络、TiDB-Proxy、TiDB 的全链路调用链追踪能力，与传统 APM 技术相比，DeepFlow 实现的调用链追踪具有如下优势特性：
无盲区：消除了 TiDB、网关中间件、中间网络的追踪盲区； 高性能：通过 eBPF 技术实现的高性能、零侵扰追踪，对 TiDB 构建生产可落地的无采样追踪观测能力； 热加载：通过 eBPF 技术的代码热插拔特性，在应用和 TiDB 集群中随时上线追踪能力，即使对微小的性能抖动也能持续进行细粒度观测，快速发现并消除系统隐患。 跨技术栈：通过全栈的追踪能力，实现 DBA、数据库开发、系统运维、应用运维等多个运维技术栈的统一追踪、统一协作，快速确定故障边界，提升技术协同效率。
1）无盲区的调用链追踪
我们可以通过一张简单的示意图来回答这样一个问题：为什么说与传统插桩方案相比，DeepFlow eBPF 零侵扰采集才真正实现了无盲区的调用链追踪？
应用插桩
传统 APM 技术通过应用代码插桩对应用调用链进行追踪，观测范围局限在可插桩的应用范围内，追踪能力在 TiDB 侧形成了观测盲区，当业务访问出现慢响应时，无法快速判断 TiDB 是否是问题的根源。
应用插桩 + TiDB 插桩
为了将应用调用链追踪能力延伸到 TiDB，我们在 TiDB 社区提交 PR[1] 进行代码修复，实现了在 TiDB 侧的追踪能力，但随之我们发现在 TiDB 中的插桩仍然存在三方面的问题：
TiDB 运行环境中的网络处于追踪盲区，无法诊断网络对 SQL 性能的影响； TiDB 前置的 TiDB-Proxy 处于追踪盲区，无法诊断 TiDB-Proxy 对 SQL 性能的影响； TiDB 插桩后的响应性能明显下降（具体数据见下文），无法在生产系统中持续使用。
DeepFlow eBPF 零侵扰采集
通过 DeepFlow 的 eBPF 技术构建的零侵扰调用链追踪能力，消除了 TiDB 的追踪盲区，具备了对任意一次应用调用过程如下位置的完整追踪能力：1）前端应用；2）TiDB-Proxy；3）TiDB；4）K8s 网络。
至此，我们便可以在 DeepFlow 调用链追踪火焰图中对某次慢响应进行追踪，直观观测各个位置对响应时延的贡献比例，从而快速确定某一次慢响应的根源位置：
以下图为例，我们可以在一张 DeepFlow 调用链追踪火焰图的局部清晰的确定某次业务过程中的 MySQL COM_QUERY COMMIT 调用在 tidb-proxy 进程内的处理引入了 480ms 时延：
2）高性能的调用链追踪
在实际生产系统中阻碍 TiDB 可观测性落地的最关键问题是观测数据采集的性能。
我们发现，应用内插桩、Java Agent 字节码增强等技术实现调用链采集时，可能会带来显著的、难以定界的额外资源消耗，并可能引入显著的业务性能损失，导致此类技术方案在高并发、高性能、高可靠要求的系统中均无法落地。很多企业仅能在测试系统或非重要的生产系统中开启此类追踪能力，而较为重要的生产系统只能采用高比例采样追踪来降低对业务的负面影响，特别是金融行业核心生产系统会完全放弃追踪能力以确保不影响业务性能，但这就导致了运行保障能力薄弱、运维风险失控。
而 DeepFlow 采用 eBPF 技术实现的零侵扰（Zero Code）可观测性很好的解决了这些问题，业务时延（Response Time）通常仅有亚毫秒级别的影响，且 Agent 的资源消耗可预期、可设限。得益于 Just-in-Time (JIT) 技术，DeepFlow Agent 的 eBPF 代码运行效率可以与内核原生代码的性能媲美，且在采集过程中不会影响应用程序的处理过程，做到对应用调用处理过程的零侵扰。
在 DeepFlow 对 TiDB 的全栈观测实践中，我们测试验证了 TiDB 集群在使用 Jaeger 插桩与使用 DeepFlow 的 eBPF 零侵扰技术进行可观测性实践时业务性能的不同表现。
Jaeger 插桩采集时，TiDB SQL 响应时延：我们开启 TiDB 的 OpenTracing[2] 功能，并观察应用实例位置（svc-order）访问 tiproxy 的响应性能，可以看到 SQL 响应的平均时延均值稳定在 300~400ms 之间，最大时延均值在部分情况下超过了 1.5s。
DeepFlow eBPF 采集时，TiDB SQL 响应时延：我们使用 DeepFlow Agent 对 TiDB 分布式集群进行无采样的观测数据采集，并观察应用实例位置（svc-order）访问 tiproxy 的响应性能，可以看到 SQL 响应的平均时延均值降低到 3~5ms，最大时延均值不超过 38ms。
从以上性能对比数据中我们发现，DeepFlow 通过 eBPF 技术实现的零侵扰可观测性解决了插桩方案带来的业务性能问题，从而能够面向核心 IT 生产系统的 TiDB 分布式数据库构建生产可落地的无采样追踪观测能力。
3）随时热加载的调用链追踪
由于应用内插桩、Java Agent 字节码增强等技术手段带来的业务性能损失，重要的核心生产系统在日常运行中基本会关闭追踪能力，但当遇到故障或异常需要进行细粒度追踪时，却发现插桩和 Java Agent 的启动过程需要对核心生产系统的应用实例和 TiDB 组件实例进行重启，这时候追踪功能要不要开启就成为一个艰难和痛苦的抉择，最终形成了这样的运维现状：
微小故障不了了之，系统带着隐患运行。 中级故障大量投入，测试环境反复测试，靠运气复现定位根因。 重大故障全力灭火，全团队 7x24 不计成本全力投入，直至业务恢复。
海恩法则告诉我们在任何一起严重事故背后，都有 29 起轻微事故和 300 起潜在的隐患，在 IT 系统的运维保障中存在同样的规律。正是由于插桩和 Java Agent 开启所需的重启动作，导致生产环境中大量的潜在隐患和微小故障难以诊断定位而不了了之，中级故障的复测定位消耗大量人力，而重大故障还是在不断出现。
DeepFlow 零侵扰可观测性完美的解决了这个难题。对应用系统或 TiDB 需要开启调用链追踪能力时，随时可一键部署 DeepFlow Agent 以启动追踪数据采集，Agent 部署时不需要侵入应用 POD 和 TiDB 组件 POD，也不需要重启应用程序、TiDB 或操作系统，Agent 仅通过 Linux 操作系统 eBPF 技术便可将追踪数据的采集代码瞬时热加载到操作系统的内核中并开启各个位置的追踪数据采集。而即便是对于负载非常高的业务系统，当希望卸载追踪能力时，也可在线关闭 Agent 的 eBPF 采集开关或卸载 Agent，追踪数据采集代码便可从操作系统内核中瞬时卸载。在这整个过程中，上层应用程序和 TiDB 组件程序无任何感知。
DeepFlow Agent 在操作系统内核中随时热加载的调用链追踪能力，使得我们可以在应用系统和 TiDB 集群中随时上、下线追踪观测能力，而无需担忧对应用的扰动，随时对微小故障和中级故障进行细粒度观测，快速发现并消除系统隐患，避免重大故障的发生。
4）跨技术栈统一协作的调用链追踪
传统插桩技术的 APM 追踪适用于应用开发人员和 TiDB 开发人员，调用链更多体现的是进程内部的函数调用关系，没有开发背景很难看懂，因此在故障定界过程中对 DBA 及其他运维角色的实际帮助不大。而 DeepFlow 可观测性平台则实现了任意一次应用调用从应用程序到操作系统、底层网络的全栈追踪能力，因而可以构建面向 TiDB 运维、TiDB 开发、应用开发、K8s 运维、中间件运维等各个技术栈的全栈运维协作能力，对任意一次应用调用全过程在各个处理环节的性能洞察清楚，快速确定故障边界。
以上图为例，在 DeepFlow 可观测平台中：
业务应用开发和运维：通过业务应用微服务的调用时延，快速诊断发现业务应用的隐患或故障； K8s 运维：通过各微服务实例之间网卡的调用时延；快速诊断发现 K8s 平台的隐患或故障； 中间件运维：通过 TiDB-Proxy 位置的调用时延，快速诊断发现中间件的隐患或故障； DBA：通过 eBPF 采集的 TiDB 调用时延，快速诊断 TiDB 一侧的隐患或故障； 数据库开发：在按需开启 TiDB 的 OpenTelemetry 插桩数据后，数据库开发人员可以快速诊断 TiDB 内部关键函数的隐患或故障。
04
全方位观测
除了调用链追踪之外，日常对 TiDB 运维保障时，业务全景、网络性能、系统资源性能、操作系统文件读写性能、应用程序函数性能均是需要全面观测分析的维度，以快速找到问题的根源，可观测性实践必须要打通多类观测数据的孤岛，建立观测数据之间的联系，设计流畅的观测操作流，使得全栈运维人员在观测运维过程中，能够高效、丝滑的观测全方位数据，更快更简单地在数据中找到结论。
在 TiDB 可观测性实践中，我们在 DeepFlow 平台中实现了多类数据的统一采集分析，并通过丝滑的操作流，得以高效地调阅各类数据，实现全方位的观测能力，具体包括：
业务全景观测 网络性能观测 SQL 语句回溯 系统资源性能观测 文件读写性能观测 函数性能观测（CPU 剖析）
1）业务全景观测
DeepFlow 通过与云原生 API 接口的实时对接，动态获取资源标签、业务标签，并对实时采集的应用调用数据标记标签，从而实现自动化、随业务动态更新的业务全景构建能力。
在基于 DeepFlow 的 TiDB 可观测性实践中，我们构建了从云原生应用集群到 TiDB 分布式数据库集群的端到端业务全景（如下图）：
通过构建云原生应用集群与 TiDB 数据库集群的业务全景拓扑，从宏观出发观测 IT 业务系统的全貌，当在业务全貌中发现局部业务性能异常时，即可向微观逐步探索，快速找到未知的未知。
2）网络性能观测
网络丢包、网络时延是 TiDB 数据库集群故障诊断过程中经常怀疑的问题方向，DeepFlow 通过网络性能观测可以快速确定某次分布式数据库业务故障是否根源自网络故障。
在网络性能观测中，我们可以通过如下 6 个指标观测外部访问 TiDB 集群、TiDB 集群内部组件互访的网络交互性能，诊断、确定不同类型的网络传输问题：
字节（吞吐率）——观测网络吞吐压力 TCP 重传比例——观测网络丢包情况 TCP 零窗比例——观测 TCP 拥塞情况 建连-失败比例——观测 TCP 建连异常情况 平均 TCP 建连时延——观测网络 RTT 平均 TCP/ICMP 系统时延——观测操作系统的响应速度
示例1：快速观测客户端访问 TiDB 入口的网络交互性能
示例2：快速观测 TiDB 内部组件之间的网络交互性能
3）SQL 语句回溯
不合理的 SQL 语句会占用大量的 CPU 和内存资源，导致 TiDB 响应延迟增加，同时降低 TiDB 的整体性能，因此快速回溯效率低下的 SQL 语句是数据库运维中的重要一环。未使用索引的查询、全表扫描、过度复杂的查询、使用不合适的函数或数据类型均是需要通过回溯 SQL 语句，并重点关注的「烂 SQL」类型。
在 TiDB 可观测性实践中，DeepFlow 通过零侵扰的旁路采集能力，完整记录了每一次 SQL 的详情信息，包括 SQL 语句、响应时延、发生时间、源端节点等，在调用日志检索中可实时检索、回溯烂 SQL 的出现频次，并确定 SQL 的源头。
4）系统资源性能观测
操作系统的 CPU、内存利用率过高，或同时段的网络接口吞吐拥塞均可能导致慢 SQL 的出现，因此为了更快更准确的找到慢 SQL 的问题根源，在故障诊断过程中快速分析 TiDB 组件实例的 CPU、内存、网络接口指标是提升分布式数据库观测能力、运维能力、排障效率的关键一环。
在 TiDB 可观测性实践中，我们通过 Grafana Agent 采集系统指标，并将数据统一汇入 DeepFlow 可观测平台，对数据统一打标、统一关联、统一呈现，实现了对 TiDB 组件 POD 指标数据的观测能力，在调用链追踪中发现慢 SQL 的根源 POD 后，便可一键调阅 POD 的 CPU 使用率变化曲线、内存使用率变化曲线、网络吞吐变化曲线，通过问题时段的指标值轻松确定慢 SQL 事件与系统 CPU、内存、网络接口资源性能的关联关系。
5）文件读写性能观测
文件读写的性能会对 TiDB 的 SQL 响应性能产生显著影响，虽然采用高性能存储资源可以尽可能的避免文件慢读写可能性，但在 TiDB 运维过程中仍需要频繁回答两个问题：
当偶发性的慢 SQL 出现后，如何确定偶发性的文件慢读写是问题的根源？ 当系统中出现一些未知的大文件读写或频繁文件读写，如何找出文件读写的源进程？
DeepFlow 通过 Linux 内核的 eBPF 能力实现了对操作系统文件读写事件的完整采集和观测，并且支持全采集、部分采集等多种采集模式。
当应用出现慢响应时，在 DeepFlow 中可以一键检索问题时间段客户端、服务端的全部文件读写事件，在列表中快速锁定文件操作事件和源进程。当慢 SQL 响应出现时，DBA 可以在数秒内确定是否有伴生的慢 IO 事件；当有未知文件读写行为时，系统运维可以在数秒内锁定文件 IO 源：
6）函数性能观测（CPU 剖析）
对慢 SQL 的故障诊断过程中，当发现 CPU 成为业务性能瓶颈点后，接下来要做的便是对 TiDB 组件 POD 的 CPU 调度情况进行剖析，找出 TiDB 组件程序中的热点函数，从而找到程序优化的切入点。DeepFlow 通过 Linux 内核的 eBPF 技术实现了应用进程的 CPU Perf 数据采集和观测能力，通过对 TiDB 组件应用进程的 CPU 性能剖析，开发人员可以轻松锁定 TiDB 各组件程序中内核函数、库函数、应用函数的 CPU 热点。
TiDB 可观测性实践中，我们通过 DeepFlow 对 TiDB、PD、TiKV 组件进行了 CPU 性能剖析。其中在下面的 TiDB 进程 CPU 性能剖析火焰图中我们可以清晰观测到 Jaeger 插桩为 TiDB 进程带来了显著的 CPU 资源开销：
05
价值总结
良好的运维保障能力是 TiDB 分布式数据库稳定运行的前提条件，在此次可观测性实践中，DeepFlow 通过领先的高性能 eBPF 零侵扰数据采集技术、零插桩的调用链追踪技术、多源数据的统一观测技术，构建了面向 TiDB 全栈、全链路、随时热加载、可生产落地的可观测性方案，显著提升 TiDB 的全方位运维能力，高效助力 TiDB 数据库稳定运行，帮助用户打造更加可靠、稳定的数据库服务。