一文搞懂 OceanBase 4.x 全链路追踪

爱可生开源社区

发布于 2025-04-16 10:41:04

14800

代码可运行

文章被收录于专栏：爱可生开源社区爱可生开源社区

运行总次数：0

代码可运行

作者：李富强，爱可生 DBA 团队成员，OBCE；熟悉 MySQL，OceanBase 等数据库，擅长数据库架构设计，故障诊断，性能优化；技术让生活更美好，欢迎沟通交流，共同进步。

爱可生开源社区出品，原创内容未经授权不得随意使用，转载请联系小编并注明来源。

本文约 3600 字，预计阅读需要 15 分钟。

瓜分 10 万奖金！OceanBase 首届 AI 黑客松等你来战

📇 文章大纲

什么是全链路追踪？
全链路追踪的工作原理
全链路追踪信息如何展现？
常见相关问题解答

1. 什么是全链路追踪？

OceanBase 数据库是分布式数据库，因此调用链路较为复杂。

当出现超时问题时，往往无法快速定位是 OceanBase 内部组件的问题 还是 网络的问题。运维人员只能根据经验和 observer 日志进行分析。

为了提高诊断效率，OceanBase 4.x 版本新增了全链路追踪功能[1]。

全链路追踪

该功能可以追踪用户的 SQL 请求在数据库全链路过程中，在不同组件、不同阶段执行的相关信息，并以可视化方式展现给用户，从而帮助用户快速定位问题所在位置以及快速精准地发现组件内部问题。

2. 全链路追踪的工作原理

2.1 全链路日志

日志记录流程

OceanBase 基于各个链路的 trace log，一键生成 SQL 的全链路耗时信息，以便用户可以快速定位链路问题。

全链路追踪的日志（跟踪日志 trace logs），会根据数据访问路径来决定其记录细节。如果是通过 ODP 访问数据库，跟踪信息会同时记录在 OBProxy （obproxy_trace.log）和 OBServer 的日志文件（trace.log）中；若是直接访问 OBServer，则只在 OBServer 的日志文件中记录。

2.2 全链路追踪流程

在全链路中，不同的请求有对应的请求链路。一条完整的请求链路（Trace）则是若干个请求流程（Span）构成，在 OceanBase 数据库将内部处理的每一个流程定义为一个 Span。

请求链路可以理解为树状图，包含父节点 Span 以及相应的子节点 Span，此部分信息会被打印到跟踪日志（trace logs）中，并通过 parent_id 与 id 来关联父子节点。

同时，在 trace logs 中对于每个请求流程会包含实际执行 SQL 信息，这部分被命名为 Tag，以不同的 Tag 来记录当前操作的详细信息。Span 和 Tag 被记录在 trace logs 中，来帮助运维人员理解数据库内部的处理逻辑以及定位问题所在。

2.2.1 常见的 Span 解读

各类访问链路

与客户端相关的 Span

obclient：通过 OBClient 客户端进行访问
JDBC：通过 JDBC 驱动进行连接

与 OBProxy 相关的 Span

ob_proxy 为 OBProxy 对一条 SQL 处理的全部耗时，即 OceanBase 数据库除前端驱动层以外的从数据库请求开始到数据处理完成，结果反馈的整条链路耗时
ob_proxy_partition_location_lookup 为 OBProxy 在请求转发阶段，获取 partition location 准备进行路由的耗时。
ob_proxy_server_process_req 为 OBProxy 对一条 SQL 请求的处理耗时和访问来回的网络开销

与 OBServer 相关的 Span

OBServer 内部的处理机制是将分发过来的请求，根据请求类型分为文本 SQL、preprocess statement 和存储过程三类。

com_query_entry（同 com_query_process）：查询过程
mpquery_single_stmt：单个语句的访问路径
sql_compile：编译 SQL
pc_get_plan：获取执行计划
hard_parse：硬解析
parse：软解析
resolve：解析语法树的语义并生成语句
rewrite：重写 SQL
optimize：进行基于成本的优化并生成执行计划日志
code_generate：根据执行计划日志生成物理执行计划
pc_add_plan：将生成的执行计划加入 plan cache
sql_execute：执行物理执行计划
open：打开执行计划
response_result：执行计划过程和结果
px_schedule：按照 px 划分任务
px_task：执行 px 子任务
close：关闭执行计划

2.2.2 常见的 Tag 解读

com_query_entry

log_trace_id：当前请求在 log 中的 trace ID
err_code：当前请求的错误代码

sql_compile

sess_id：session ID
sql_text：SQL 文本
sql_id：SQL ID
hit_plan：执行计划命中执行计划缓存

px_schedule

dfo_id：数据流操作 ID
used_worker_cnt：正在使用的 px 工作线程的个数
qc_id：查询协调器 ID

px_task

task_id：并行任务的逻辑 ID
dfo_id：数据流操作 ID
sqc_id：子查询协调器 ID
qc_id：查询协调器 ID
group_id：资源组 ID

3. 全链路追踪信息如何展现？

主要有两种方法，分别是通过 show trace[2] 命令行查看追踪信息和通过 OceanBase 运维平台（OCP）查看追踪信息，下面将进行分别介绍，使用全链路追踪前，对 OceanBase 及相关生态工具版本有一定要求。

✔️ 版本要求

OceanBase：V4.2.0 及以上版本
ODP：V4.2.0 及以上版本
JDBC：V2.4.3 及以上版本
OBClient：V2.2.3 及以上版本
OCP：V4.0.3 及以上版本

3.1 通过命令行查看追踪信息

⚠️ 注意事项

MySQL 原生驱动不支持 show trace 功能，建议使用 OBClient 和 OceanBase JDBC 驱动。
在线收集的全链路信息（show trace 命令行方式）存放在内存中，不会写入日志文件。

3.1.1 配置组件

使用 show trace 时，需使用上述正确版本并开启 OceanBase 2.0 协议，开启全链路诊断。

ODP 配置

# 使用 root@sys 用户通过 ODP 代理登录 OceanBase 数据库或使用 root 用户登录数据库的 proxysys 租户后，通过执行 SQL 语句配置。
obclient> alter proxyconfig set enable_ob_protocol_v2_with_client=true;
obclient> alter proxyconfig set enable_ob_protocol_v2=true;

OBClient 配置（这块实测，实际不配置也是生效的）。

# 执行如下命令开启 OceanBase 2.0 协议，取值为 0 表示关闭，取值为 1 表示开启
export ENABLE_PROTOCOL_OB20=1;
# 执行如下命令开启全链路诊断，取值为 0 表示关闭，取值为 1 表示开启。
export ENABLE_TRACE=1;

3.JDBC 配置

JDBC 可通过 URL 控制开启，在 JDBC URL 中添加 enableFullLinkTrace=true 或者 useOceanBaseProtocolV20=true&enableFullLinkTrace=true，均可开启全链路诊断功能。

3.1.2 开启 SHOW TRACE 功能

通过客户端连接 OceanBase 数据库后执行如下命令开启 session 级别 show trace。

obclient> set ob_enable_show_trace='on';

执行目标 SQL，此处以执行 select sleep(3); 命令为例。

obclient> select sleep(3);

3.1.3 展示全链路追踪信息

通过 show trace 返回的结果，根据 ElapseTime 字段，可以看到整个链路哪些 Span 节点耗时高，然后再根据 Span 代表的具体含义，进行问题分析。

本示例中，耗时主要在 sql_execute 的子 Span response_result，代表了 SQL 执行物理执行计划阶段耗时高。

obclient> show trace;
+--------------------------------------------------+----------------------------+-------------+
| Operation                                        | StartTime                  | ElapseTime  |
+--------------------------------------------------+----------------------------+-------------+
| obclient                                         | 2025-03-27 16:04:13.909281 | 3006.488 ms |
| └── ob_proxy                                     | 2025-03-27 16:04:13.910036 | 3004.656 ms |
|     ├── ob_proxy_partition_location_lookup       | 2025-03-27 16:04:13.910053 | 0.001 ms    |
|     ├── ob_proxy_server_process_req              | 2025-03-27 16:04:13.910235 | 3003.663 ms |
|     └── com_query_process                        | 2025-03-27 16:04:13.910577 | 3001.832 ms |
|         └── mpquery_single_stmt                  | 2025-03-27 16:04:13.910582 | 3001.813 ms |
|             ├── sql_compile                      | 2025-03-27 16:04:13.910598 | 1.365 ms    |
|             │   ├── pc_get_plan                  | 2025-03-27 16:04:13.910601 | 0.032 ms    |
|             │   └── hard_parse                   | 2025-03-27 16:04:13.910706 | 1.245 ms    |
|             │       ├── parse                    | 2025-03-27 16:04:13.910706 | 0.085 ms    |
|             │       ├── resolve                  | 2025-03-27 16:04:13.910813 | 0.189 ms    |
|             │       ├── rewrite                  | 2025-03-27 16:04:13.911049 | 0.286 ms    |
|             │       ├── optimize                 | 2025-03-2716:04:13.911345 | 0.151 ms    |
|             │       ├── code_generate            | 2025-03-2716:04:13.911502 | 0.194 ms    |
|             │       └── pc_add_plan              | 2025-03-2716:04:13.911868 | 0.061 ms    |
|             └── sql_execute                      | 2025-03-2716:04:13.911981 | 3000.324 ms |
|                 ├── open                         | 2025-03-2716:04:13.911982 | 0.007 ms    |
|                 ├── response_result              | 2025-03-2716:04:13.912012 | 3000.111 ms |
|                 └── close                        | 2025-03-2716:04:16.912160 | 0.044 ms    |
|                     └── end_transaction          | 2025-03-2716:04:16.912185 | 0.002 ms    |
+--------------------------------------------------+----------------------------+-------------+
20rowsinset (0.017 sec)

3.1.4 关闭功能

分析结束后，执行如下命令关闭 session 级别 show trace，避免性能影响。

set ob_enable_show_trace='off';

3.2 通过 OCP 查看链路信息

OCP 支持多种检索维度，如耗时检索、Trace ID 或 SQL ID 检索等，帮助用户快速定位问题所在。此外，OCP 还提供了一种直观的全链路追踪信息展示[3]方式，允许用户查看请求在客户端到数据库内部各环节的执行详情。

3.2.1 部署 OpenSearch 集群和相关配置

第一次使用 OCP 展现全链路追踪，需要部署 OpenSearch 集群以及配置好链路查询相关参数。

部署 OpenSearch 集群（全链路追踪和日志检索等功能，依赖 OpenSearch 集群来进行存储和查询数据）。

1.首先要在 OCP 宿主机上获得 OpenSearch 的 Docker 镜像
docker pull oceanbase/opensearch:3.3.2

2.通过 Docker 部署 OpenSearch
2.1.生成根证书
cd /opt/key/
openssl genrsa -out ./root-ca-key.pem 2048
openssl req -new -x509 -sha256 -key ./root-ca-key.pem -subj "/C=CA/ST=ONTARIO/L=TORONTO/O=ORG/OU=UNIT/CN=ROOT" -out ./root-ca.pem

2.2.启动容器
# OpenSearch 的 Docker 镜像必须以 host 网络模式启动
# 多节点部署需要将根证书拷贝到各节点上，再进行启动操作
# 本示例用于功能演示，采用单节点，实际OpenSearch集群容量按照具体的业务需求评估
docker run -d --net host -v /opt/key/root-ca-key.pem:/opt/opensearch/config/root-ca-key.pem -v /opt/key/root-ca.pem:/opt/opensearch/config/root-ca.pem --env  OPENSEARCH_USERNAME=opensearch --env OPENSEARCH_PASSWORD=opensearch --env OPENSEARCH_NODE_URLS=xxx --env HOST_IP=xxx --env OPENSEARCH_JVM_HEAP=2g --name ocp-opensearch oceanbase/opensearch:3.3.2

3.2.2 配置链路查询相关参数，重启 OCP 容器

修改系统参数

设置好链路查询相关参数后，重启 OCP 容器后生效。

参数列表

3.2.3 开启租户级别全链路追踪

以 MySQL 模式租户举例。

OceanBase 默认开启租户的全链路 Trace 功能，用户可以使用 DBMS_MONITOR 系统包来配置租户的全链路收集策略。

1. 查询全链路 Trace 的收集策略（使用 root 用户，登录到业务租户进行查询；也可以登录到业务集群 sys 租户，这样查询的是所有租户的全链路 Trace 收集策略）。
# RECORD_POLICY字段表示trace信息输出到日志文件中策略, 支持以下 3 种策略
# ALL，所有 span 和 tag 信息均打印到日志文件中, 并且是在每个 span 结束时, 就打印到日志文件中。
# ONLY_SLOW_QUERY，当前请求为 slow query ，则该部分信息的span 和 tag 会打印到日志文件中。
# SAMPLE_AND_SLOW_QUERY，当前请求为 slow query 则该部分信息的span 和 tag 会打印到日志文件中；其他请求信息的 span 和 tag 有一定的概率会打印到日志文件中
# SAMPLE_PERCENTAGE字段表示采样的频率，下面收集策略查询SAMPLE_PERCENTAGE输出为10，代表采样频率为10%。
# LEVEL字段代表打印日志的粒度。目前支持三个粒度等级，其中 Level1 为模块级别的粗粒度，Level3 的粒度最精细

obclient [(none)]> SELECT * FROM oceanbase.GV$OB_FLT_TRACE_CONFIG;
+-----------+--------+-------------+-------------+-------------+-------------------+-------+-------------------+-----------------------+
| TENANT_ID | TYPE   | TENANT_NAME | MODULE_NAME | ACTION_NAME | CLIENT_IDENTIFIER | LEVEL | SAMPLE_PERCENTAGE | RECORD_POLICY         |
+-----------+--------+-------------+-------------+-------------+-------------------+-------+-------------------+-----------------------+
|      1002 | TENANT | obmysql     |             |             |                   |     1 |                10 | SAMPLE_AND_SLOW_QUERY |
+-----------+--------+-------------+-------------+-------------+-------------------+-------+-------------------+-----------------------+
1 row in set (0.021 sec)

2. 关闭当前租户的 trace，可以执行如下命令。
obclient [(none)]> call dbms_monitor.ob_tenant_trace_disable();
Query OK, 0 rows affected (0.262 sec)

3. 记录当前租户中的耗时等信息，全部记录并全部打印（生产环境谨慎开启ALL收集策略，可能会导致 OpenSearch 占用存储空间过大。如果当前租户已经开启全链路收集策略，需要先关闭后，再设置新的收集策略）。
obclient [(none)]> call dbms_monitor.ob_tenant_trace_enable(1, 1, 'ALL');
Query OK, 0 rows affected (0.208 sec)

4.再次查询全链路 Trace 的收集策略（可以看到已生效）。
obclient [(none)]> SELECT * FROM oceanbase.GV$OB_FLT_TRACE_CONFIG;
+-----------+--------+-------------+-------------+-------------+-------------------+-------+-------------------+---------------+
| TENANT_ID | TYPE   | TENANT_NAME | MODULE_NAME | ACTION_NAME | CLIENT_IDENTIFIER | LEVEL | SAMPLE_PERCENTAGE | RECORD_POLICY |
+-----------+--------+-------------+-------------+-------------+-------------------+-------+-------------------+---------------+
|      1002 | TENANT | obmysql     |             |             |                   |     1 |               100 | ALL           |
+-----------+--------+-------------+-------------+-------------+-------------------+-------+-------------------+---------------+
1 row in set (0.023 sec)

# 除了支持开启租户级别的全链路追踪，还支持 session 级别，client_identifier 级别，module/action级别，这里不展开了，可以根据参考资料中的官方文档进行设置。

3.2.4 执行 SQL，查看链路查询

1. 通过客户端连接 OceanBase 数据库 obmysql 租户后执行 SQL。
obclient [(none)]> select sleep(3);
+----------+
| sleep(3) |
+----------+
|        0 |
+----------+
1 row in set (3.022 sec)

链路查询

然后点击 Trace ID（00063163-37d4-f603-0855-157d240f1083），就可以看到 SQL 的全链路耗时信息（本示例中，耗时主要在 sql_execute 的子 Span response_result，同上部分 show trace 命令看到的结果一致）。

查看耗时信息

鼠标移动到具体的 Span 上，可以看到具体的 Tag 信息（执行的 SQL 语句，是否命中执行计划等信息）。

查看具体信息

4. 常见相关问题解答

Q1：通过 obclient 连接数据库执行 show trace 命令时，为何结果未显示驱动 obclient 的耗时信息？

Q1 效果

解答：一般是 ODP 配置项 `enable_ob_protocol_v2_with_client` 未开启导致的，开启后结果显示正常。

正常显示

Q2:启动 OpenSearch Docker 服务报错，Can't open /opt/opensearch/config/root-ca.pem for reading, No such file or directory

报错演示

解答：部署 OpenSearch 服务时，如果参考的是旧版本的官方文档，生成根证书这一步是漏掉的，参考 OceanBase 4.3.5 的文档，生成根证书，并在启动 OpenSearch Docker 服务时，指定证书即可。

总结

本文主要介绍了全链路追踪是什么以及工作原理，同时介绍了如何开启全链路追踪和全链路追踪的展示方法。

当业务反馈应用访问 OceanBase 慢，这时我们可以借助 OceanBase 4.x 全链路追踪功能，来快速定位链路具体慢在哪，并可以给出链路在每个阶段的耗时信息。

借助全链路追踪功能，快速诊断链路慢在哪儿，大大提高 DBA 的工作效率。

参考资料

[1]

全链路追踪概述: https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002013145

[2]

Show Trace: https://www.oceanbase.com/docs/common-odp-doc-cn-1000000002024105

[3]

查询链路: https://www.oceanbase.com/docs/common-ocp-1000000002380837

本文关键字：#OceanBase# #全链路追踪# #OCP# #Show Trace#

本文参与腾讯云自媒体同步曝光计划，分享自微信公众号。

原始发表：2025-04-15，如有侵权请联系 cloudcommunity@tencent.com 删除

oceanbase

配置

日志

数据库

本文分享自爱可生开源社区微信公众号，前往查看

如有侵权，请联系 cloudcommunity@tencent.com 删除。

本文参与腾讯云自媒体同步曝光计划，欢迎热爱写作的你一起参与！

登录后参与评论

暂无评论