Apache ShardingSphere-Proxy SQL 链路追踪

前言：Apache ShardingSphere 作为践行 Database Plus 理念的数据服务平台，其包含数据分片、读写分离、数据加密、影子库等多种数据管理功能。

当 Apache ShardingSphere 应用于实际生产中，用户往往需要对其 SQL 链路进行监控，特别是在数据分片场景中，出现慢查询或执行异常时更加需要对 SQL 进行链路追踪协助分析排查问题，此时清晰了解 SQL 改写情况、执行情况就显得至关重要。

ShardingSphere-Agent 提供了链路追踪功能，帮助用户在使用 ShardingSphere-JDBC 或 ShardingSphere-Proxy 时进行调用链路分析 。本篇以 ShardingSphere-Proxy 为例，为大家讲解如何使用 ShardingSphere-Agent 实现链路追踪。

实现原理

ShardingSphere-Agent 采用 Java Agent 技术实现，使用 Byte Buddy 修改目标字节码，织入数据采集逻辑。有兴趣的读者可以自行了解 Java Agent、Byte Buddy 相关技术。

基础概念

链路中有如下两个「重要概念」：

🌟 Span：基本工作单元，一次链路调用创建一个 span，使用唯一的 id 进行标识，span 中可以有其他的数据，比如描述信息，时间戳，key-value 对等自定义信息。

🌟 Trace：类似树结构的 span 集合，表示的是一条调用链路，存在唯一标识。在 ShardingSphere-Proxy 中对应一条逻辑 SQL 的完整执行链路。

Apache ShardingSphere-Proxy 中执行一条 SQL 会经过解析、路由、改写、执行、归并流程。目前实现了对解析、执行两处比较重要的操作进行了追踪，而其中执行阶段往往是最受关注的部分。执行阶段涉及到 Proxy 连接到物理库执行实际的 SQL，所以此阶段的信息对排查问题提供了重要依据，也完整体现了逻辑 SQL 和改写后实际 SQL 的对应关系。在 ShardingSphere-Proxy 中一条完整的链路会包含三种 span 类型。

Span	描述
/ShardingSphere/rootInvoke/	表示一条逻辑 SQL 执行的完整流程，并且可以查看执行逻辑 SQL 的耗时
/ShardingSphere/parseSQL/	解析阶段，可以查看 SQL 的解析耗时，和逻辑 SQL语句。(当使用 PreparedStatement 时无此 span )
/ShardingSphere/executeSQL/	执行阶段，此阶段会执行改写后的 SQL，可以查看执行耗时。(如果 SQL 无需在后端物理库执行，则无此 span)

实战指南

为了方便查看链路数据，一般会使用 Zipkin 或者 Jaeger 对链路数据进行收集和展示。目前 ShardingSphere-Agent 支持上报链路数据到这两种组件。接下来就以分片场景为例介绍怎样上报数据和怎样对 SQL 链路进行分析。

ShardingSphere-Proxy 准备

✅ 下载 Proxy,  下载地址查看官网 [1] 

✅ 在 MySQL 物理库下创建 demo_ds_0、demo_ds_1 作为后续使用的存储节点 ds_0、ds_1。

✅ 启动 Proxy，使用 MySQL 客户端工具连接到 Proxy，创建逻辑库 sharding_db，并使用 DistSQL 在该库下注册存储节点。(DistSQL（Distributed SQL）是 Apache ShardingSphere 特有的操作语言。它与标准 SQL 的使用方式完全一致，用于提供增量功能的 SQL 级别操作能力，详细使用可以参考 DistSQL 官网文档 [2])

使用 DistSQL 创建分片规则 t_order，设置 ds_0、ds_1 为存储节点，且分片数为 4

创建表 t_order

最终会在物理库 demo_ds_0 下创建表 t_order_0、t_order_2，在物理库 demo_ds_1 下创建表 t_order_1、t_order_3。

在准备好 ShardingSphere-Proxy 环境后，接下来就介绍怎么样通过 ShardingSphere-Agent 实现 SQL 链路数据上报到 Zipkin 和 Jaeger。

上报到 Zipkin

部署 Zipkin，参考官网 [3]

配置 agent.yaml 导出数据到 Zipkin

plugins:
  tracing:
    OpenTelemetry:
      props:
        otel.service.name: "shardingsphere" # 配置的 service name
        otel.traces.exporter: "zipkin" # 使用 zipkin exporter
        otel.exporter.zipkin.endpoint: "http://localhost:9411/api/v2/spans" # zipkin 接收数据地址
        otel-traces-sampler: "always_on" # 采样设置
        otel.metrics.exporter: "none" # 关闭 OpenTelemetry metric 采集

停止 Proxy 后重新启动 Proxy 和 Agent（--agent 表示开启 Agent）

./bin/stop.sh

./bin/start.sh --agent

使用 MySQL 客户端工具连接到 Proxy，并依次执行如下 insert、select、update、delete 语句。

访问 http://127.0.0.1:9411/zipkin/ (Zipkin UI 地址)，此时可以查看到有 4 条链路数据，和执行的 SQL 数量一致。

下面以 insert 语句的链路进行分析。找到 insert 语句的链路，可以看到具体的详情，通过 /shardingsphere/parsesql/ span 内的 tags 信息可以看到解析的 SQL 语句和在客户端执行的逻辑 SQL 一致。

有 4 条 /shardingsphere/executesql/ span 数据，依次查看详情后得出存储节点 ds_0 中执行了下面两条 SQL 语句。

insert into t_order_0 (order_id, user_id, address_id, status) VALUES (4, 4, 4, 'OK')
insert into t_order_2 (order_id, user_id, address_id, status) VALUES (2, 2, 2, 'OK')

存储节点 ds_1 中执行了下面两条 SQL 语句

insert into t_order_1 (order_id, user_id, address_id, status) VALUES (1, 1, 1, 'OK')
insert into t_order_3 (order_id, user_id, address_id, status) VALUES (3, 3, 3, 'OK')

登录到物理库查看对应的数据（在执行 insert 语句后查看）

由于 t_order 表分为了 4 片，并且插入了 order_id 为 1 到 4 的数据，所以最终会在表 t_order_0、t_order_1、t_order_2、t_order_3 中各插入一条数据，也就会有 4 条 /shardingsphere/executesql/ span。最终显示的 SQL 链路和实际执行的结果一致，可以通过 span 清晰了解每个步骤执行的耗时，也可以通过 /shardingsphere/executesql/ span 知道逻辑 SQL 的具体执行情况。

下面分别是 select、update、delete 语句的链路详情，也都和实际情况一致。

上报到 Jaeger

部署 Jaeger，参考官网 [4]

部署 Proxy

agent.yaml 配置

plugins:
  tracing:
    OpenTelemetry:
      props:
        otel.service.name: "shardingsphere" # 配置的 service name
        otel.traces.exporter: "jaeger" # 使用 jaeger exporter
        otel.exporter.otlp.traces.endpoint: "http://localhost:14250" # jaeger 接收数据地址
        otel.traces.sampler: "always_on" # 采样设置
        otel.metrics.exporter: "none" # 关闭 OpenTelemetry metric 采集

停止 Proxy 后重新启动 Proxy 和 Agent（--agent 表示开启 Agent）

./bin/stop.sh

./bin/start.sh --agent

登录 Proxy 在 sharding_db 库下执行 SQL 语句(和上报到 Zipkin 示例中执行的语句一致)

访问 http://127.0.0.1:16686/ （Jaeger UI 地址）可以看到 4 条 trace 数据, 与执行的 SQL 数量一致

由于执行的 SQL 语句和上报到 Zipkin 示例中相同，所以链路数据也应是一致的，下面以 insert 语句的链路为例进行说明。

同样显示了一条解析 span， 4 条执行 span

存储节点 ds_0 执行了下面两条 SQL 语句。

insert into t_order_0 (order_id, user_id, address_id, status) VALUES (4, 4, 4, 'OK')
insert into t_order_2 (order_id, user_id, address_id, status) VALUES (2, 2, 2, 'OK')

存储节点 ds_1 执行了下面两条 SQL 语句。

insert into t_order_1 (order_id, user_id, address_id, status) VALUES (1, 1, 1, 'OK')
insert into t_order_3 (order_id, user_id, address_id, status) VALUES (3, 3, 3, 'OK')

通过 span 条数、解析的 SQL 语句、执行的 SQL 语句分析得出整个 SQL 链路是符合预期的。

采样率

若生产环境中的链路数据量非常大，用户可以选择进行采样收集。如下，设置采样率为 0.01（表示采样率为 1%）。由于使用的是 OpenTelemetry Exporters 进行数据导出，其他详细参数可以参考 OpenTelemetry Exporters文档 [5]

plugins:
  tracing:
    OpenTelemetry:
      props:
        otel.service.name: "shardingsphere"
        otel.metrics.exporter: "none"
        otel.traces.exporter: "zipkin"
        otel.exporter.zipkin.endpoint: "http://localhost:9411/api/v2/spans"
        otel-traces-sampler: "traceidratio"
        otel.traces.sampler.arg: "0.01"

结语

以上就是本次分享的全部内容，如果读者对 Apache ShardingSphere 有任何疑问或建议，欢迎在 GitHub issue 列表 [6] 提出，或可前往中文社区 [7] 交流讨论。

🔗 参考

[1] ShardingSphere-Proxy 下载地址：https://shardingsphere.apache.org/document/current/cn/downloads/
[2] DistSQL 文档：https://shardingsphere.apache.org/document/current/cn/user-manual/shardingsphere-proxy/distsql/
[3] Zipkin 官网：https://zipkin.io/pages/quickstart.html
[4] Jaeger 官网：https://www.jaegertracing.io
[5] OpenTelemetry Exporters文档：https://github.com/open-telemetry/opentelemetry-java/tree/main/sdk-extensions/autoconfigure
[6] GitHub issue 列表：https://github.com/apache/shardingsphere/issues
[7] 中文社区：https://community.sphere-ex.com/