共计 6987 个字符，预计需要花费 18 分钟才能阅读完成。
对于作者
肖意
OceanBase 高级技术专家
曾多次加入蚂蚁双十一大促反对工作，是 TPC-C、TPC- H 性能攻坚项目组核心成员，次要负责 SQL 引擎相干研发，包含链路协定、执行打算治理、执行引擎等方向的设计与开发工作。
在上一篇 4.0 解读文章中，咱们回顾了单机到分布式逾越给数据库 DDL 带来的挑战，并介绍了 OceanBase 的应答策略及设计思路，以便为用户提供更高效、更通明的运维体验（* 戳链接浏览《OceanBase 4.0 解读：兼顾高效与通明，咱们对 DDL 的设计与思考》）。
本篇将持续数据库运维的话题，开展对故障追踪与定位能力的探讨。首先让咱们看下这样一个场景:
业务部门：数据库申请好慢，能够看看哪里出问题了吗？
DBA 查看数据库节点实时监控
DBA：我在数据库节点的实时监控并未发现很慢的 SQL。
业务部门：那是怎么回事？
DBA：可能是客户端到数据库节点这一链路有问题，我来看一下两头代理服务器的日志。
DBA 开始查问日志，1 hour later……
DBA：从代理服务器日志看耗时也是失常的。可能是客户端到代理服务器的网络问题？
……
上文形容的是分布式数据库下运维遇到慢 SQL 时的场景，如果运维无奈及时找出问题起因，就会十分影响应用体验，甚至导致业务服务不可用。因而，如何提供简略、高效的诊断能力，始终是咱们思考的问题。相比单机数据库，分布式数据库系统波及多个节点、多组件协同工作，集群规模可能达到几十、上百台服务器，用户申请链路会更加简单，要实现疾速高效地问题诊断与定位也会更有挑战。
OceanBase 4.0 在诊断能力方面有了显著晋升，其中包含首次实现对 SQL 申请的可视化全链路追踪，可能帮忙用户疾速追踪并定位具体问题产生在哪个执行阶段、哪台机器以及哪个模块，并提供具体的相干执行信息，为用户提供简略、高效的运维体验。本文将分享咱们对数据库高效诊断的思考，介绍 OceanBase 全链路追踪能力及设计思路：
全链路追踪要解决什么问题；
全链路追踪的要害能力有哪些；
咱们如何设计全链路追踪；
4.0 全链路追踪成果展现。
全链路追踪要解决什么问题？
在 OceanBase 中，当用户发动一个申请后，首先会被发送给 OBProxy（SQL 申请代理），由 OBProxy 路由转发到 OceanBase 集群，进入集群中的某一个 OBServer 节点，随后会通过 SQL 引擎、存储引擎、事务引擎等（不同的申请会波及不同引擎中的诸多解决模块），该申请也有可能通过 rpc 工作拜访多个 OBServer 节点的数据，最终将后果返回给客户端。
图 1 OceanBase SQL 申请执行过程示意图
当用户申请呈现报错或者执行慢的问题时, 可能是申请执行过程中的某个组件问题，也可能是不同组件节点间的网络等问题。在 4.0 之前的版本中，OceanBase 曾经为用户提供了较为欠缺的监控和诊断能力，包含 SysStat、Sql Audit、Trans Stat、Tenant Dump、Slow Trans、Slow Query 等，OceanBase 运维平台（OCP）根据上述监控输入的信息实现了白屏化监控和诊断，包含事务诊断、TopSQL 诊断、SlowSQL 诊断等。但这些诊断能力不足申请全链路视角的信息, 导致往往定位问题产生在哪个执行阶段、哪个机器以及哪个模块就破费了很多工夫；有时甚至须要各组件专家一起参加排查能力定位，影响运维人员对问题疾速诊断和复原的效率。
为进一步提高分布式场景下用户申请问题诊断效率, OceanBase 实现了全链路追踪机制, 可能追踪用户 SQL 申请在数据库全链路过程中，在不同阶段、不同组件执行的相干信息，并以可视化形式展示给用户，从而帮忙用户疾速定位问题所在位置。
全链路追踪的要害能力有哪些
▋ 事务 + SQL 维度的全链路追踪
OceanBase 提供了面向用户的事务 + SQL 维度的全链路追踪能力。对于业务部门而言，更关怀的往往是一笔业务服务总的耗时状况。例如在 OLTP 零碎中，一笔业务服务个别由一个或多个事务组成。因而，咱们把事务作为追踪单位会更贴合用户的理论业务，一个事务造成一个追踪的 Trace，并对事务中每条 SQL 申请记录 OBClient -> OBProxy -> OBServer 外部全链路过程中相干执行信息，用户能够通过一个 Trace 疾速找到该事务执行了哪些语句，以及这些语句从客户端视角看到的执行状况。
在理论业务中，一旦用户发现有慢的 SQL 申请，或者存在某个慢的事务，能够从慢 SQL 的整个执行链路中疾速定位是哪个执行阶段慢。又或者在某个事务中，如果发现一个 SQL 完结到另一个 SQL 再发动之间的工夫较长，则可请业务同学查看业务逻辑侧可能存在的问题。
图 2 事务中 SQL 调用过程图
▋ 反对分布式环境下的全链路追踪
OceanBase 反对分布式环境下的全链路追踪能力。首先，OceanBase 作为一个分布式系统，当 OBProxy 接管到一个客户端申请后，有可能会将其路由到 OBServer 集群中任意一台 OBbServer 上。同时，该申请波及到的数据可能散布在不同的 OBServer 中。具体到 SQL 执行阶段，执行引擎会向不同的 OBServer 发送执行子工作 task，当 OBServer 数量很多时，这些 SQL 申请和 Task 具体是在哪个 Server 上执行？Server 内具体各模块执行的耗时状况是怎么的？都会困扰运维人员。
全链路追踪机制实现了 SQL 申请在分布式场景下，波及多 Server 时残缺执行链路的追踪。用户可能直观地看到是哪个 OBServer 上接管申请，哪个 OBServer 上执行近程 task，每个 task 的调度状况，以及执行耗时等信息。
图 3 分布式申请执行过程图
▋ 提供便捷的业务零碎关联能力
在理论业务中，不少用户都会建设本人的监控及诊断系统。当数据库产生申请调用慢或报错时，用户可能须要零碎疾速关联到数据库对应的某个 SQL 诊断，进一步缩短从发现问题到解决问题的耗时。全链路追踪机制能够为用户提供便捷的业务零碎关联能力，用户通过 JDBC 接口 /SQL 接口，可能在业务数据库连贯上设置调用申请对应的 app trace id, 该 app trace id 会记录到 OceanBase 全链路追踪对应的信息中。
当用户发现某个 app trace id 对应的申请或服务数据库调用有报错时, 能够应用该 app trace id 在全链路诊断系统中疾速搜寻到对应的 app trace id 关联的数据库 Trace，而后间接查看该申请在数据库链路中各阶段耗时状况及报错点，疾速确定触发问题的组件。
▋ 多种全链路信息展现形式
用户通过 OceanBase 运维平台（OCP），能够通过不同维度疾速检索到有问题的申请，比方按耗时检索, 按指定 Trace id 或者 SQL ID 检索等，并且直观地看到申请从客户端到数据库外部全链路各组件的执行信息, 不便疾速定位出问题的阶段。
图 4 OCP 平台展现效果图
此外，用户能够在 OceanBase 新版本的交互场景应用全链路诊断能力。用户在命令行中手动执行某一个语句后，如果想剖析该语句的执行调用链路状况，以及链路中各阶段耗时状况，以便进行性能剖析或调优，能够应用 show Trace 性能便捷地找到性能瓶颈点。如下所示，咱们能够看到两个分布式并行执行工作 (px_task) 的执行状况，如果想看更多明细，也能够通过 show Trace 其余不同命令展示进去。
OceanBase(admin@test)>select/*+parallel(2)*/ count(*) from t1;
+----------+
| count(*) |
+----------+
| 5 |
+----------+
1 row in set (0.005 sec)
OceanBase(admin@test)>show trace;
+-------------------------------------------+----------------------------+------------+
| Operation | StartTime | ElapseTime |
+-------------------------------------------+----------------------------+------------+
| obclient | 2023-03-01 17:51:30.143537 | 4.667 ms |
| └─ ob_proxy | 2023-03-01 17:51:30.143716 | 4.301 ms |
| └─ com_query_process | 2023-03-01 17:51:30.145119 | 2.527 ms |
| └─ mpquery_single_stmt | 2023-03-01 17:51:30.145123 | 2.513 ms |
| ├─ sql_compile | 2023-03-01 17:51:30.145133 | 0.107 ms |
| │ └─ pc_get_plan | 2023-03-01 17:51:30.145135 | 0.061 ms |
| └─ sql_execute | 2023-03-01 17:51:30.145252 | 2.350 ms |
| ├─ open | 2023-03-01 17:51:30.145252 | 0.073 ms |
| ├─ response_result | 2023-03-01 17:51:30.145339 | 2.186 ms |
| │ ├─ px_schedule | 2023-03-01 17:51:30.145342 | 1.245 ms |
| │ │ ├─ px_task | 2023-03-01 17:51:30.146391 | 1.113 ms |
| │ │ │ ├─ get_das_id | 2023-03-01 17:51:30.146979 | 0.001 ms |
| │ │ │ ├─ do_local_das_task | 2023-03-01 17:51:30.147012 | 0.050 ms |
| │ │ │ └─ close_das_task | 2023-03-01 17:51:30.147237 | 0.014 ms |
| │ │ └─ px_task | 2023-03-01 17:51:30.146399 | 0.868 ms |
| │ │ ├─ get_das_id | 2023-03-01 17:51:30.147002 | 0.001 ms |
| │ │ ├─ do_local_das_task | 2023-03-01 17:51:30.147036 | 0.041 ms |
| │ │ └─ close_das_task | 2023-03-01 17:51:30.147183 | 0.011 ms |
| │ └─ px_schedule | 2023-03-01 17:51:30.147437 | 0.001 ms |
| └─ close | 2023-03-01 17:51:30.147536 | 0.049 ms |
| └─ end_transaction | 2023-03-01 17:51:30.147571 | 0.002 ms |
+-------------------------------------------+----------------------------+------------+全链路诊断交互式成果
▋ 建设从定位到诊断的一站式体验
咱们曾经晓得，用户能够借助全链路追踪能力疾速定位出故障产生的组件或模块。如果具体探讨某个比拟小的模块呢？此时用户就能够关联各模块对应的其余诊断机制进行问题定位。
举例来说，咱们通过全链路追踪定位到是 SQL 执行引擎慢，则能够通过 SQL 申请的 sql_trace_id 关联，主动跳转到 SQL Plan Monitor 诊断机制，查看执行打算各线程各算子执行状况。如图 5 所示，能够看到每个算子执行 CPU 工夫（DBTime 绿色）、等待时间（DBTime 红色）、算子返回行数等信息。
图 5 SQL Plan Monitor 展现执行信息图
咱们如何设计全链路追踪
如下图所示，能够看到 OceanBase 全链路追踪能力实现波及的次要板块。咱们记录 Trace 信息应用的数据模型是 OpenTracing 的模型，具体到实现则次要分 2 个局部：Trace 数据生成以及 OCP 剖析展现集成，下文将开展具体介绍。
图 6 OceanBase 全链路追踪实现示意图
▋ 数据模型
OceanBase 全链路追踪记录数据应用 OpenTracing 模型，该数据模型在分布式追踪零碎中被大量应用，下图中右边是 OpenTracing 数据模型，右图是对应 OceanBase 全链路追踪的记录模型，一个 Trace 对应于一个数据库的事务，每个 Trace 会对应多个 Span，比方一个 SQL 申请是一个 Span，Span 中会记录某个过程执行相干信息，每个 Span 会记录一条日志长久化到 Trace 文件中。
图 7 全链路追踪数据模型
▋ Trace 数据生成
生成残缺无效的 Trace 数据，是全链路追踪能力的要害。申请全链路波及的各个组件，哪些阶段须要独自记录 Span，以及记录哪些要害有用信息，咱们都会认真斟酌，确保全链路信息精确有用，另一方面，生成 Trace 数据的性能损耗，咱们也须要重点思考，这块开销次要分两局部，一部分是 Trace 数据记录到内存开销，另一部分是将 Trace 数据写入到 Trace 文件的开销，为了尽量不影响性能，同时为用户提供更多有用的全链路诊断信息, 咱们提供了多种控制策略，为不同用户链接能够设置不同 Trace 级采样频率，记录残缺 Trace 信息，同时也会将用户更关注的慢 SQL 及报错的 SQL 对应的 Trace 信息 100% 打印到 Trace 日志中。
图 8 各组件 trace 日志生成示意图
Trace 文件会独立记录到 OBProxy 和 OBServer 不同过程所在机器，思考到数据库客户端应用是在业务服务端，OceanBase 数据库 OBClient 端的全链路 Trace 信息并没有记录到业务服务器上，而是传输到 OBProxy 记录。
▋ OCP 平台剖析与展现集成
OCP 平台中，实现了链路 Trace 信息的页面搜寻及展现能力，它能够依据用户设定的条件，搜寻某个申请波及的 Trace 信息，让用户直观地查看整个链路的详细信息。而这些数据的起源, 次要来自 OBProxy 和 OBServer 不同服务器上的 Trace 日志, OCP 后盾会有专门的采集工具, 对这些 Trace 日志进行采集, 并解析，最初存储到 ES 中。但这些采集数据是原始的 Span 数据，同一个 Trace 的数据可能扩散在不同机器的不同 Span 中，要实现按一个 Trace 中不同的 Span 上的 Tag 作为条件来搜寻会较艰难。因而，OCP Server 会定时把 Trace 的要害 Span 数据（如不同阶段的耗时、重要 Tag）合在一条数据中，结构每条 Trace 的概要。从而实现让用户按不同的条件组合高效地查问 Trace 信息，用于页面展现。
4.0 全链路追踪成果展现
回到文章结尾的慢 SQL 问题，在 4.0 提供了全链路追踪能力后，运维人员的操作会有什么变动呢？
当初，用户如果发现业务申请变慢，能够在 OCP 的全链路搜寻页面中根据耗时对 SQL 进行排序，找到某个时间段内耗时高的申请，查看是否有执行工夫不合乎预期的 SQL。如果通过 TopSQL 诊断曾经确定是某个 SQL 耗时高，或者获取到有关联用户的 app trace id，也能够作为查找过滤条件，进一步缩小查找范畴。
图 9 OCP 全链路追踪搜寻
当确定耗时高的申请后，接下来咱们须要诊断具体是哪里出了问题。此时，用户能够在 OCP 中间接点击有问题的 Trace id，开展申请的 Trace 信息（如图 10 所示）。能够看到，从客户端视角看，该申请总共耗时是 4.47ms，OBProxy 视角总耗时 4.366ms，OBServer 中耗时是 3.246ms，次要耗时在 OBServer 端，进一步看，能够看到次要耗时在 SQL compile 阶段, 也就是 SQL 生成执行打算阶段。此时，咱们便能够得出初步论断：这条 SQL 执行慢耗时高，是它没有命中执行打算导致的。
图 10 OCP 全链路信息展现
在 OCP 的全链路详情中，能够看到相应 SQL 申请调用个模块的门路，并能够具体看到各阶段的耗时。举例来说，当用户要理解客户端发动申请到 OBProxy 接管申请这个阶段的具体耗时，从时间轴上看到 OBClient 和 OBProxy 间的网络耗时并不是次要耗时。如果用户想进一步理解该阶段耗时具体信息，能够别离点击对应 OBClient 发送申请的 Span 和 OBProxy 接管申请的 Span，如图 11 所示，能够疾速看到两者开始时间差为 187 us，也就是这个从客户端发送申请到 OBProxy 接管申请的耗时，这样能够帮忙咱们更加细化地剖析问题。
图 11 全链路追踪阶段信息展现
写在最初
OceanBase 4.0 的全链路追踪能力实现了对每个事务、每条 SQL 申请的可观测性，提供了高效的问题诊断和定位能力。咱们置信这一新能力将帮忙用户更加疾速地定位问题并解决问题, 从而带来更简略、更高效地数据库运维体验。作为改善 OceanBase 易用性的重要一环，咱们也将在将来的 4.x 中着力晋升运维体验，新增包含 ASH（Active Session History）、Realtime SQL Plan Monitor、Logical Plan Manager 等在内的更多功能。最初，欢送大家在评论区留言，一起探讨对数据库问题诊断的认识。
你可拜访 OceanBase 官网获取更多信息：https://www.oceanbase.com/
