随着OCEANBASE在金融、证券、运营商、能源等行业的应用越来越广泛，针对OCEANBASE的运维支撑工具的需求也被越来越多的用户提出来了。去年我们开始适配OB的动力来自于与一个金融行业用户的交流，他们对我们的D-SMART支持Oracle的功能表示满意，不过他们目前面临了一些新的问题。那就是目前部分业务系统已经从Oracle迁移到了Oceanbase，但是对于OB的运维，他们感到有些头痛。系统不出问题的时候，或者不出大问题的时候，也不太需要运维人员介入，大部分故障场景会在短时间内自愈。而系统出现一些较为严重的性能问题的时候，运维人员往往是束手无策的，甚至不知道故障可能会持续多长时间。
D-SMART支持OCEANBASE的适配工作已经经历了一年多了，当时适配的版本是3.X，不过到了Oceanbase 4.2.1 GA的23年10月份，这个工作还没有彻底完成。通过一个运维平台，不断的积累运维经验，构建大量的自动化预警模型和分析工具，可以有效的增强对OB数据库的运维支撑能力，整个智能化运维的框架是十分成熟的，研发团队对Oceanbase的研究何跟踪也有一两年时间了。因此我们在去年年初开始立项针对OB进行适配的时候，原本以为这项工作会在3-4个月内初步完成，然后去某个用户处磨合。没想到适配OCEANBASE远比我们预料的复杂。分布式数据库与集中式数据库在很多地方都与集中式数据库不同，从而导致运维管理方面的差异是十分巨大的。
首先是指标体系的不同，分布式数据库的部署环境是一组服务器，数据库实例也是由一组OBSERVER组成的多个分布式的服务组成。因此指标体系完全不同。对于集中式数据库来说，我们可以关注某个指标，比如每秒CLOG数量。不过对于OB来说，这里就复杂了，因为每个OBSERVER都会有相关的指标。
在集中式数据库中的一个指标，在分布式数据库中可能会有很多值，分布式数据库集群的节点数量越多，这个指标的值就越多。不仅如此，Oceanbase还支持多租户，每个租户都有独立的指标，因此在一个Oceanbase数据库中，某一个指标的值可能有几十个甚至几百上千个。我们不能仅仅从总值或者平均值去看问题，还要考虑值的均衡性问题和变化趋势。因此运维监控工具需要具备对一组值的处理能力。这涉及到了对D-SMART底层指标处理体系的改造与优化。
前端界面上显示的值也是要斟酌的，到底把哪个值放上去呢？最大值，平均值？如果放最大值有可能同一行上面的数据来自于多个不同的OBSERVER，数据时不一致的。
因为D-SMART最早设计指标体系的时候就学习了互联网企业的经验，支持列表、表格等模式，因此只要在前端显示与后端处理的时候适配一下就可以了，更大的问题还在后面。
第二个需要考虑的问题是多租户的问题，Oceanbase是一个从底层到上层都支持多租户的数据库系统。不同的租户之间有着较强的隔离。因此从运维的角度，我们如何来看待集群和租户呢？对于一个数据库来说，从集群下钻到租户，再到某个OBSERVER，可能是我们从集中式数据库沿用下来的思考方式。但是这种模式似乎会让运维工具变得太复杂，让运维人员很难掌握。通过思考，我们决定把集群和租户都看成是一个独立的运维对象。在现实的生产环境中，有些用户对于Oceanbase的运维也是这样的，集群有专门的人员维护，而不同的租户交给不同的使用单位自己来运维。
因此我们为OceanBase设计了三种数据库子类型：Oceanbase集群子类、Oceanbase MySQL租户子类和Oceanbase Oracle租户子类。如果仅仅以租户的角度来看待Oceanbase这样的多租户数据库系统还是比较简单的，这个框架完全可以参考Oracle的PDB，事实上root租户我们可以把它看成是Oracle的CDB，我们把root租户看成是Oceanbase的集群，对于集群而言，我们更关注的是节点、资源（总体与可分配资源）、容量、网络、高可用、故障等问题。而不需要去关注负载、并发等方面的问题。
Oceanbase数据库的负载、并发、性能等方面的问题可以在租户层面去关注。不过Oceanbase拥有MySQL和Oracle两种兼容性租户，这两种兼容性租户的核心代码是有较大差异的，因此这两种租户在指标方面都不是拉齐的。比如等待事件只有Oracle租户才有，某些MySQL租户的指标在Oracle租户中不见得有，因此我们无法对这两种租户采用相同的指标和健康模型。
第三个问题是Oceanbase自身的问题引发的，那就是Oceanbase不同大版本的兼容性问题。这是一个十分值得吐槽的问题，每次Oceanbase大版本升级，其系统视图，指标体系，等待事件都会有较大的变化，运维工具必须做较大的调整。
第三个问题叠加第二个问题，让Oceanbase的智能模型构建也变得复杂了，考虑到目前Oceanbase的大多数用户还是在使用3.x版本，因此我们必须对3.x版本进行支持。2.x版本的支持可能要往后放一放了，因为2.x和3.x版本的差异依然巨大。在这种情况下，健康模型要根据三种子类分别根据4.X/3.X版本进行个性化定制，目前通过7个模型来覆盖这些版本。
3.x和4.x版本之间的差异远远比增加一倍的健康模型要复杂的多，指标体系中也存在了大量的不兼容的指标，甚至描述同一个问题的指标会出现2个，一个代表4.X版本，一个代表3.x版本，而二者无法完全兼容，因为含义并不一定完全一致，如果用同一个指标来表示，很容易产生误解。
第四个问题是集群与服务器节点之间的拓扑关系问题。一套大型的Oceanbase数据库可能由数十个甚至上百个节点组成，并且上面跑了数十个租户，这种拓扑关系十分复杂。虽然租户之间但是他们依然存在关联关系，因为他们共享集群中的所有服务器。服务器出现故障或者性能问题，可能会导致集群和租户出现出现问题。因此我们在运维Oceanbase的时候依然必须关注服务器的健康。但是把服务器如何被纳入监管呢？
最终我们的方案选择了服务器在运维管理台上隐身，通过集群拓扑入口来统一监控集群所依赖的服务器的方案。服务器出现异常时，健康模型与故障模型会发现其问题并主动报警，但是服务器并不出现在数据实例的监控清单里。不过在集群和租户的集群拓扑里我们可以看到所有服务器的健康状态，如果需要，可以进行下钻。采用这种方式后，当服务器没有故障或者隐患时，我们可以不去关注服务器，只要关注租户的健康，而当服务器存在隐患时，我们可以获得告警，并且有入口可以去做诊断分析。
经过这一年多与Oceanbase的深度接触，我们找到了一种对复杂的多租户分布式数据库的运维监控与故障定位的方法，Oceanbase专版的发布后，我们会邀请客户一起来进行测试，并通过对用户现场数据的分析，丰富故障模型，完善智能基线，并积累更多的运维知识工具。通过数年的积累，我想Oceanbase的运维知识积累会一步步的丰富起来。
