D-SMART 对接 OceanBase4 看 OB 的可观测性：值得夸赞的和要吐槽的都不少

以下文章来源于白鳝的洞穴 ，作者白鳝

今天开始出差，这篇文章是昨天下班前写的，只要不在办公室里，就很难静静的思考，也写不出有价值的东西，最近这段时间有好几个会，还要送娃去学校报到，家里还有些事情要处理，所以这段时间可能更新比较不规律，请大家原谅。

Oceanbase 3 的时候虽然和 D-SMART 做了对接，不过因为知识梳理不足，那玩意就是个样子货。前阵分析了 OCP 之后，我们坚定了要做 OB 版本的决心。OCP 虽然对日常运维 OB 十分有价值，不过 OCP 在指标质量、监控运维，巡检、故障诊断等方面的能力还是偏弱的。很多用户在使用 ob 的时候不仅需要 OCP，应该也需要 D-SMART。

D-SMART 的定位是运维知识自动化系统，要想让一个 Oceanbase 这样的分布式数据库接入 D-SMART，需要 Oceanbase 提供强大并且丰富的可观测性接口。在 OB 3.X 上我们曾经做过一些尝试，不过当时我们发现 OB 3.X 上的很多指标并不完善。更有趣的是，和 OB3 相比 OB4 几乎就是一个全新的产品，从架构、基础概念、数据字典视图等方面有了巨大的改变。我们以前对 OB 3 的知识只有基础概念还能大部分延续，其他东西都要从头开始。包括指标的采集方式以及等待事件的含义等，都完全不同了。经过近两个月的努力，我们初步完成了支持 OB3/4 的数据指标体系构建，并实现了采集。

截止到今天，我们已经能够看到 OB4/OB3 集群和租户的健康状态了。

在集群拓扑中我们也可以十分方便的看到整个 OB 集群的架构，以及每个 OBSERVER 及租户的情况。

目前我们针对 OB 集群、Oracle 租户、MySQL 租户分别构建了健康模型。因为这三种数据库对象的指标体系是略有不同的，健康关注点也不尽相同。

构建指标体系和健康模型是构建数据库的数字化模型的第一步，通过健康模型的构建我们将 OB 的集群健康度划分为总体、集群、操作系统、并发、负载、性能这几个维度。

对于 Ob 集群来说， 总体是整个集群的总体情况，包括资源分配情况、磁盘空间使用情况等，对于则更关注于租户自己的总体情况。

集群维度主要是和集群健康相关的，包括 RPC 通讯的健康度、集群网络状态、集群负载均衡性等因素。

操作系统主要是操作系统资源使用情况、OS 健康度等方面的情况。

并发是数据库访问的并发能力的健康度。负载则是数据库承受的应用负载情况。性能是指数据库响应、关键等待事件延时等方面的指标。

利用以前为 OB 3.X 编制的运维知识图谱，也可以对系统进行相关的诊断，好像分析的准确性还可以，大体的故障范围定义的还不错。知识图谱还在继续更新之中，我想随着我们和 OB 同学的共同梳理，新版本的知识图谱的效果应该会更好。

通过上述工作对 OB 的内部结构以及运作机理也有了更加深入的理解。OB3/4 指标体系更加完善，也为构建更加能够反映出数据库运行健康情况的各种模型提供了坚实的数据基础。

目前我们使用的是 OB 4.2BETA，并非 GA 版本，因此目前数据库中也还存在不少问题。因此夸完之后，下面就是吐槽部分了，希望 OB 的同学们能看完下面的内容。

首先是部分指标目前是没有数据的，可以看出这一页的指标里有不少是 0，不知道是我们目前的测试环境没有触发指标的变化还是目前这些指标并没有在数据库核心代码中埋点。OB 3 中的指标就存在这个问题，很多定义的计数器并没有被填充数据。

到了 OB 4，这个问题似乎仅仅有了些许改善，在我们目前收录的 400 多个指标中，只有不到 200 个指标是能够采集到数据的。

指标数据不完整的情况分为三种：一种是某些指标只在 ROOT 租户中有；第二种是某些指标只在某个类型的租户（Oracle 或者 MySQL）中有；第三种是在哪都采集不到值。对于第三种可能目前的版本中还没有提供数据，我们希望在 GA 的版本中能够看到。因为不少指标对于评估 OB 数据库的健康状态还是很关键的。其他两种情况其实是正常的，只是 OB 的文档里没有对此做准确的标注。

另外一个需要吐槽的是，针对 OB 这样复杂的数据库系统，在 OB 的文档中对指标的描述和定义是十分模糊的，估计 OB 内部的同学看了这些描述都会摸不着头脑，更不要说 OB 用户了。理解指标是运维数据库十分关键的一环，因此希望 OB 的同学们能够在文档中认真写一下这方面的内容。

对于有数据的指标，有些指标设计的也不是很合理，比如租户 CPU 使用率，经常会出现超过 100 的情况。后来通过和 OB 的同学沟通才了解到，OB 的这个指标是把租户所有的 CPU 线程的使用率加在一起的统计值，如果要获得某个 OBSERVER 上某个租户的 CPU 使用率，还要除以某个 OBSERVER 上租户 CPU 线程数才能得到正确的指标。这对于运维人员来说，又增加了看指标的复杂度。租户在某个 OBSERVER 上的线程数本身就是个配置信息，如果能够直接加工好那就方便多了。

另外在做数据采集的时候还遇到了一些 BUG，比如对于 gv$ob_locks 视图做 count(*)操作就会报错，select 某个字段也会报类似的错误，只有 select * 是可以正确执行的。这个视图实际上是数据库内存区域的镜像，估计 OB 的同学目前只实现了一个最简单的接口，把整行数据输出给用户，没有支持其他的 SQL 接口。

经过和 OB 技术团队的合作，我们初步完成了 OB 指标体系的梳理，虽然发现了一些小问题，不过瑕不掩瑜，OB 4.2 的可观测性能力总体上还是有很大的提升的。我们也有信心在 OB 4 上实现 D-SMART 在 ORACLE 上的大多数功能。今后我们也会和 OB 社区一起发布一个 D-SMART 社区版的 OB 专版，到时候我会提前在公众号告知的。