OceanBase 4.0 解读:全链路追踪要解决什么问题?从一条慢SQL说起

简介: 曾多次参加蚂蚁双十一大促支持工作,是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 节点的数据,最终将结果返回给客户端。
  • image.png当用户请求出现报错或者执行慢的问题时, 可能是请求执行过程中的某个组件问题,也可能是不同组件节点间的网络等问题。在 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 再发起之间的时间较长,则可请业务同学查看业务逻辑侧可能存在的问题。
  • image.png▋ 支持分布式环境下的全链路追踪
    OceanBase 支持分布式环境下的全链路追踪能力。首先,OceanBase 作为一个分布式系统,当 OBProxy 接收到一个客户端请求后,有可能会将其路由到 OBServer 集群中任意一台 OBServer 上。同时,该请求涉及到的数据可能分布在不同的 OBServer 中。具体到 SQL 执行阶段,执行引擎会向不同的 OBServer 发送执行子任务 task,当 OBServer 数量很多时,这些 SQL 请求和 Task 具体是在哪个 Server上执行?Server 内具体各模块执行的耗时情况是怎样的?都会困扰运维人员。
    全链路追踪机制实现了 SQL 请求在分布式场景下,涉及多 Server 时完整执行链路的追踪。用户能够直观地看到是哪个 OBServer 上接收请求,哪个 OBServer 上执行远程 task,每个 task 的调度情况,以及执行耗时等信息。
  • image.png
  • ▋ 提供便捷的业务系统关联能力
    在实际业务中,不少用户都会建立自己的监控及诊断系统。当数据库发生请求调用慢或报错时,用户可能需要系统快速关联到数据库对应的某个 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 检索等,并且直观地看到请求从客户端到数据库内部全链路各组件的执行信息, 方便快速定位出问题的阶段。
  • image.png
  • 此外,用户可以在 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 红色)、算子返回行数等信息。

image.png

▋ 数据模型
OceanBase 全链路追踪记录数据使用 OpenTracing 模型,该数据模型在分布式追踪系统中被大量使用,下图中左边是 OpenTracing 数据模型,右图是对应 OceanBase 全链路追踪的记录模型,一个 Trace 对应于一个数据库的事务,每个 Trace 会对应多个 Span,比如一个 SQL 请求是一个 Span,Span 中会记录某个过程执行相关信息,每个 Span 会记录一条日志持久化到 Trace 文件中。


相关实践学习
分布式链路追踪Skywalking
Skywalking是一个基于分布式跟踪的应用程序性能监控系统,用于从服务和云原生等基础设施中收集、分析、聚合以及可视化数据,提供了一种简便的方式来清晰地观测分布式系统,具有分布式追踪、性能指标分析、应用和服务依赖分析等功能。 分布式追踪系统发展很快,种类繁多,给我们带来很大的方便。但在数据采集过程中,有时需要侵入用户代码,并且不同系统的 API 并不兼容,这就导致了如果希望切换追踪系统,往往会带来较大改动。OpenTracing为了解决不同的分布式追踪系统 API 不兼容的问题,诞生了 OpenTracing 规范。OpenTracing 是一个轻量级的标准化层,它位于应用程序/类库和追踪或日志分析程序之间。Skywalking基于OpenTracing规范开发,具有性能好,支持多语言探针,无侵入性等优势,可以帮助我们准确快速的定位到线上故障和性能瓶颈。 在本套课程中,我们将全面的讲解Skywalking相关的知识。从APM系统、分布式调用链等基础概念的学习加深对Skywalking的理解,从0开始搭建一套完整的Skywalking环境,学会对各类应用进行监控,学习Skywalking常用插件。Skywalking原理章节中,将会对Skywalking使用的agent探针技术进行深度剖析,除此之外还会对OpenTracing规范作整体上的介绍。通过对本套课程的学习,不止能学会如何使用Skywalking,还将对其底层原理和分布式架构有更深的理解。本课程由黑马程序员提供。
相关文章
|
4月前
|
SQL 运维 关系型数据库
在OceanBase数据库中,你可以通过以下几个途径来查看慢SQL和等待事件
在OceanBase数据库中,你可以通过以下几个途径来查看慢SQL和等待事件
164 1
|
11月前
|
SQL BI
【SQL开发实战技巧】系列(十):从拆分字符串、替换字符串以及统计字符串出现次数说起
本篇文章讲解的主要内容是:***遍历拆分字符串为单个字符、字符串中包含引号如何转译(q-quote特性)、计算字符在字符串中出现的次数、使用translate从字符串中快速删除替换不需要字符的巧妙写法、使用正则表达式regexp_replace将字符和数字数据分离、使用正则表达式regexp_like查询只包含数字或字母型的数据***
【SQL开发实战技巧】系列(十):从拆分字符串、替换字符串以及统计字符串出现次数说起
|
SQL 缓存 多模数据库
OceanBase源码解读(二):SQL的一生
本文为 OceanBase 数据库源码解读系列文章的第二篇,将主要为大家介绍 OceanBase 数据库中一条 SQL 的执行流程主路径,包括接收、处理、返回结果给客户端的过程,与开发者们一起探讨OceanBase的SQL引擎模块。
OceanBase源码解读(二):SQL的一生
|
存储 数据库 SQL
蚂蚁金服OceanBase挑战TPCC | TPC-C基准测试之SQL优化
蚂蚁金服自研数据库 OceanBase 登顶 TPC-C 引起业内广泛关注,为了更清楚的展示其中的技术细节,我们特意邀请 OceanBase 核心研发人员对本次测试进行技术解读。
1557 0
蚂蚁金服OceanBase挑战TPCC | TPC-C基准测试之SQL优化
|
SQL 数据库 OceanBase
几个关于oceanbase因系统原因 sql执行失败的案例
最近总结了一下关于oceanbase因为系统原因导致sql失败的例子
3035 0
|
23天前
|
SQL 算法 数据库
【数据库SQL server】关系数据库标准语言SQL之数据查询
【数据库SQL server】关系数据库标准语言SQL之数据查询
44 0
|
23天前
|
SQL 算法 数据库
【数据库SQL server】关系数据库标准语言SQL之视图
【数据库SQL server】关系数据库标准语言SQL之视图
36 0
|
23天前
|
SQL 人工智能 算法
【数据库SQL server】传统运算符与专门运算符
【数据库SQL server】传统运算符与专门运算符
17 0

相关产品

  • 云数据库 OceanBase 版