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专版，到时候我会提前在公众号告知的。