作者：李飞 云杉DeepFlow
摘要：分布式数据库市场发展迅速，TDSQL、GuassDB、OceanBase、GoldenDB、TiDB 等各类分布式数据库产品纷纷涌现，尤其在金融行业的落地越来越多。提高分布式数据库的可观测性，提升用户对产品稳定性、可靠性的信心，是金融核心业务云原生化的重要保障。DeepFlow 通过 eBPF 技术零侵扰实现的全景图、分布式追踪和持续剖析等能力为分布式数据库的可观测性建设提供了开创性的新思路。本篇文章以某国有银行分布式核心交易系统为例，介绍 DeepFlow 如何实现 TDSQL 的全链路可观测性，分享如何在客户实践中通过应用、网络、数据库的全栈、全链路统一观测，真实做到 2 至 3 步操作、5 分钟以内的业务异常定界定位。

01

可观测性对分布式数据库的重要性

随着分布式数据库技术的快速发展，TDSQL、GuassDB、OceanBase、GoldenDB、TiDB 等各类分布式数据库产品纷纷涌现，但客户对分布式数据库产品的稳定性、可靠性的怀疑和猜测是产品落地的最大挑战。我们在一些分布式数据库的用户处发现，由于可观测性技术手段的缺乏，常见业务异常的定界定位经常需要 1 天以上的周期，而且整个过程需要消耗大量中高级运维人力，因此较大比例的轻微业务异常难以确定边界，长期悬而未决，最终不了了之，既无法确定、也无法排除是分布式数据库的责任与否，从而导致许多用户对分布式数据库的稳定性、可靠性产生怀疑甚至是质疑。

如何让用户对分布式数据库产品买的放心、用的放心，关键就在于是否具备这样的能力 —— 对每一次业务异常均能以最低的运维人力消耗、最快的速度厘清问题边界，确定或排除分布式数据库的责任。如果运维人员能够将故障定界速度提升到 5 分钟以内，故障定界比例提升到 99% 以上，通过客观数据将分布式数据库的责任比例降低到 1% 以下，用户对分布式数据库的怀疑将不复存在，分布式数据库的商业落地也将变得一帆风顺。

提升分布式数据库的可观测性，构建面向业务服务的观测能力，打通应用运维、数据库运维的技术鸿沟，并将应用调用链追踪能力对数据库无缝覆盖，从而具备对数据库每一次对外服务质量的观测洞察能力，具备对每一次应用请求从前端，到后台，再到数据库的完整应用调用链追踪能力，将很容易实现 5 分钟以内、99% 以上这 2 个指标。

02

DeepFlow 零侵扰实现 TDSQL 的全链路可观测性

在过去，数据库运维主要依赖数据库自身提供的日志、指标等数据的输出能力，缺乏面向业务服务的追踪手段，而传统 APM 手段通过插桩或 Java Agent 字节码注入等技术实现的调用链追踪，在实际落地时对数据库等位置的追踪基本无能为力，因此分布式数据库的运维数据与应用运维数据难以打通关联关系，产生了数据鸿沟，从而带来了应用运维与数据库运维的技术鸿沟，影响了业务问题的定界效率和数据库相关问题的定位效率。

下图中的六个问题经常会困扰分布式数据库运维人员：

1. 哪个「业务」对数据库的请求最高？分布式数据库上线后，业务逐步迁移上来，数据库自有的实例粒度的性能指标无法区分不同的客户端业务，运维人员面对数据库高负载时难以定位具体的业务和服务。
2. 哪条「SQL 语句」要优化？业务开发的 SQL 语句可能存在 Select 所有列、缺少 Limit、Join 不合理等千奇百怪的缺陷，很可能单条语句时延不大但高频执行资源消耗巨大，依靠慢日志无法发现此类问题。
3. 一笔交易慢了，慢在哪个「进程」？金融行业的分布式核心交易系统涉及到众多微服务、中间件，当一笔交易时延过高时，快速定界性能瓶颈在应用、网络、分布式数据库，是所有 DBA 面临的经典难题。
4. 一个事务慢了，慢在哪条「语句」？一笔交易过程可能涉及到复杂的 SQL 调用，如何发现单条语句执行速度快、但整个事务执行时间长的问题。
5. 一条语句慢了，慢在哪种「资源」？数据库运维人员一般具备表索引分析技能，通过实例粒度的性能指标也能快速分析 CPU 等资源的瓶颈，但如何关联分析一条 SQL 语句与偶发性磁盘读写慢的关系通常是一个难题。
6. 应用程序慢了，慢在哪个「函数」？应用程序中使用的数据库 SDK、ORM 框架繁多，对于没有插桩的进程，是否有方法能快速定位应用内部函数的性能瓶颈。

DeepFlow 基于 eBPF 的零侵扰可观测性包括全景图、分布式追踪、持续剖析等功能，能够在不对应用、中间件、数据库做任何修改的情况下快速回答上述经典难题。特别是基于 eBPF 的分布式追踪技术，实现了包括各类基础服务在内零插桩、全覆盖的调用链追踪能力，其中也包括了分布式数据库进程间调用链的追踪能力（核心技术已发表在 ACM SIGCOOM 2023 ——《Network-Centric Distributed Tracing with DeepFlow: Troubleshooting Your Microservices in Zero Code》）。

DeepFlow 基于 eBPF 实现的零侵扰分布式追踪可以分解为微服务间追踪、微服务内追踪两部分：

1. 微服务间追踪，技术核心包括：
   • （1）eBPF 编程：通过 eBPF 编程对操作系统 Process 调用数据采集；
   • （2）零插桩追踪信息采集：通过算法计算客户端 Process、服务端 Process 位置的 TCP 流追踪信息；
   • （3）流量采集：采集解析应用调用在客户端网卡、服务端网卡位置的 TCP 流追踪信息；
   • （4）追踪关联：TCP 流追踪信息串联客户端 Process、客户端网卡、服务端网卡、服务端 Process 的追踪关系。
2. 微服务内追踪，技术核心包括：
   • （1）eBPF 编程：通过 eBPF 编程对操作系统对 Process 应用调用数据采集；
   • （2）零插桩追踪信息采集：eBPF 采集同一 Process 前端、后端 2 次应用调用的 Syscall，通过算法计算 2 次调用的关联关系，生成 Syscall Trace ID；
   • （3）追踪关联：利用 2 次调用的 Syscall Trace ID 串接同一 Process 前、后端应用调用的追踪关系。

03

某国有银行分布式核心交易系统

正是基于 eBPF 技术对进程的零侵扰特性，我们使用 DeepFlow 对某国有银行云原生环境中分布式核心交易系统的 Ingress ——> 应用实例 ——> F5 ——> TDSQL-Proxy ——> TDSQL 实例全链路进行了覆盖和观测：

04

全景图 - 定位客户端应用和 SQL 语句

通过 DeepFlow 的全景图能力，我们自动化（无需人工梳理）绘制出某银行分布式核心交易系统的端到端全景图，从而直接观测到微服务应用的上下游调用全貌：

基于 DeepFlow 全景图，困扰分布式数据库运维人员的前两个问题能快速回答：

1. 哪个「业务」对数据库的请求最高？应用实例、F5、TDSQL-Proxy 之间的连线上可展示吞吐量、时延、异常比例等性能指标，能用于快速定位高吞吐客户端、慢查询客户端。
2. 哪条「SQL 语句」要优化？点击应用实例、F5、TDSQL-Proxy 之间的连线，可查看具体的 SQL 调用日志，能够快速分析发现不合理的 SQL。

05

分布式追踪 - 定界单笔交易性能瓶颈

在微服务调用全景图的基础上，通过 DeepFlow 的调用链追踪能力，经过 2 至 3 步的查询操作，即可快速对微服务应用的慢响应进行全链路追踪：

从上面以火焰图形式呈现出来的调用链追踪中，我们可以非常直接的观测到：

• （1）该笔交易处理在 Ingress、应用实例、TDSQL-Proxy、TDSQL 实例之间的调用过程；
• （2）该笔交易过程的 Ingress 处理时延；
• （3）该笔交易过程的应用实例处理时延；
• （4）该笔交易过程的 TDSQL-Proxy、TDSQL 实例的处理时延；
• （5）该笔交易过程在网络传输上消耗的时延。

通过以上过程不难看出，DeepFlow 的零侵扰分布式追踪能力可以深入覆盖到分布式核心交易系统的各个角落，包括分布式数据库内部的 TDSQL-Proxy、TDSQL 实例，对任意一笔交易实现全链路的追踪。这种追踪能力将应用观测能力、数据库观测能力、网络观测能力无缝衔接起来，对业务服务异常真正做到 2 至 3 步操作、5 分钟内的诊断定界的处置效率。

基于 DeepFlow 分布式追踪，困扰分布式数据库运维人员的第 3 个问题也可快速回答：一笔交易慢了，慢在哪个「进程」？以上图为例，我们可以看到 TDSQL-Proxy 和 TDSQL 实例的执行速度均非常快，瓶颈发生在应用实例进程内部。而在其他环境中，通过 DeepFlow 也能快速发现应用进程收包慢、K8s 网络慢、KVM 网络慢等问题。

06

分布式追踪 - 分析 SQL 事务执行过程

在 DeepFlow 分布式追踪能力中，能够清晰的对 SQL 事务的执行过程进行分析，包括一个事务的开始、SQL 执行、提交全过程。

在下面的案例中，某笔业务的 SQL 事务过程经过了「开启手动提交模式」、「多次 COM_QUERY」、「手动提交」的复杂交互过程，通过 DeepFlow 的观测能力，我们能够在调用链中清晰的洞察每次 SQL COM_QUERY 操作在客户端、网络、服务端的响应时延，以及执行结果，整个过程中的任何异常在 DeepFlow 的观测下一目了然：

基于 DeepFlow 分布式追踪，困扰分布式数据库运维人员的第 4 个问题也可快速回答：一个事务慢了，慢在哪条「语句」？以上图为例，我们可以清晰的看到 COMMIT 花费的时间最长，其次是第三条语句（INSERT）。

07

分布式追踪 - 观测慢查询磁盘 IO 速度

在许多情况下，数据库调用的慢响应是由所在节点的磁盘 IO 速度慢导致，特别是在使用云硬盘的场景下，磁盘作为一项共享资源其响应时延可能受到其他访问者的影响。因此磁盘 IO 的观测能力也是数据库运维非常重要的部分，也是传统操作系统运维和数据库运维的痛点。通过 DeepFlow 的零侵扰 eBPF 数据采集能力，我们实现了对磁盘 IO 事件的观测，以及对 MySQL 调用与磁盘 IO 事件之间的关联分析。

在下面的案例中，我们可以观测到某次 SQL 的 COM_QUERY 的调用、该次调用过程中的所有相关磁盘 IO 事件列表、每次 IO 事件的详细信息（进程 ID、线程 ID、文件名、读写类型、字节数、IO 消耗时长），当发生磁盘的慢 IO 事件导致数据库响应慢时，我们可以在 IO 列表中以秒级的速度快速洞察出来：

基于 DeepFlow 分布式追踪，困扰分布式数据库运维人员的第 5 个问题也可快速回答：一条语句慢了，慢在哪种「资源」？以上图为例，我们可以清晰的看到对 binlog 等文件的读写非常迅速。

08

持续剖析 - 定位 TDSQL 客户端瓶颈函数

在实际运维中，我们还发现很多数据库的业务异常与数据库的客户端进程有直接关系，通过对分布式数据库的观测并不能解决任何问题，而 DeepFlow 的零侵扰 eBPF 数据采集实现了对应用进程性能剖析数据的获取能力，完整覆盖应用进程的应用函数、库函数、内核函数的 On-CPU 调度，在 TDSQL 分布式数据库的运维场景中，我们可以通过该能力对访问数据库的客户端实现零侵扰的性能持续剖析。

在下面的案例中，我们对数据库客户端进程进行 5 分钟的 On-CPU 性能剖析，可清晰观测到数据库 update 的 CPU 耗时 10ms ，数据处理 CPU 耗时 2.5s，Java 内存分配 CPU 耗时 5.06s：

基于 DeepFlow 分布式追踪，困扰分布式数据库运维人员的第 6 个问题也可快速回答：应用程序慢了，慢在哪个「函数」？。

09

指标统一观测 - 传统指标无缝集成

除了通过 eBPF 技术以零侵扰方式获取的大量数据库观测数据之外，DeepFlow 还支持 Promethus RemoteWrite、PromQL 接口，传统由数据库自身暴露的性能指标可以汇入 DeepFlow Agent，并由 DeepFlow Server 统一关联、存储、分析、呈现，消除运维数据孤岛，减少诊断、监控在不同运维系统间的上下文切换，提升运维观测效率，实现多源数据的统一观测分析，提升数据库的可观测性。

10

总结

恐惧源于未知，信任始于洞察，从 DeepFlow 的大量实践中我们发现，当 IT 系统通过可观测性技术实际具备分钟级定界定位能力之后，就可以将过去困扰 IT 系统运维的大量悬而未解、不了了之的问题全部消灭，从而消除团队间的技术怀疑和协作壁垒，增强对包括分布式数据库在内的各类基础服务产品的使用信心。

而 eBPF 技术为 IT 系统的可观测性提供了丰富的想象力，DeepFlow 在 eBPF 方向的稳步技术积累正在将一个个想象逐步变为现实，通过此次 DeepFlow 的零侵扰调用链追踪技术对 TDSQL 分布式数据库环境的采集覆盖和调用链追踪实战，我们可以发现困扰传统 APM 技术已久的数据库等基础服务的追踪、观测已不在有任何技术难度和挑战。

11

什么是 DeepFlow

DeepFlow 是云杉网络开发的一款可观测性产品，旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰（Zero Code）采集，并结合智能标签（SmartEncoding）技术实现了所有观测信号的全栈（Full Stack）关联和高效存取。使用 DeepFlow，可以让云原生应用自动具有深度可观测性，从而消除开发者不断插桩的沉重负担，并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。

GitHub 地址：https://github.com/deepflowio/deepflow

访问 DeepFlow Demo，体验零插桩、全覆盖、全关联的可观测性。