利用OSCAR的可观测性能力构建运维知识系统

编者荐语：

D-SMART社区版将会推出信创专版，神舟通用OSCAR数据库也是信创专版支持的运维对象之一。随后我们将会陆续发布一些和D-SMART信创专版相关的信息。

我们团队针对神舟通用OSCAR的运维知识自动化系统构建工作已经进行了半个月了，因为充分了解了OSCAR的产品渊源，外加OSCAR本身在可观测性接口方面做了很多与Oracle兼容的设计，因此虽然我们刚刚接触OSCAR，不过对OSCAR的指标理解以及知识体系构建来说，都比一个完全陌生的数据库要容易得多，做起来也快了不少。

         

OSCAR数据库提供的客观性接口比Oracle 要简单得多，通过v$sysstat、v$lock、v$session、V$SEGSTA_STATISTICS、V$SESSION_WAIT_HISTORY、V$TRANSACTION、V$WAIT_CHAINS等系统视图，我们很快就把OSCAR的指标体系构建起来了。

         

指标不仅仅是从这些视图采集原始值，而是需要经过二次加工，构建出多维度的指标。在我们这个实验环境中，我们从OSCAR 7.0中获得了600多个指标。利用这些指标，进一步做维度分析，构建出健康模型。

OSCAR的健康模型分为总体、操作系统、命中率、负载、并发五个维度。因为我们之前已经了解了OSCAR是基于PG早期版本开发的，因此OS维度占有的分值较高，而单进程多线程架构对于物理内存OOM十分忌讳，再加上很可能存在类似PG的DOUBLE BUFFER的影响因素，因此在OS中，内存安全性方面的比重也比较高，反而命中率维度中的DB CACHE命中率之类的指标的影响度没那么大。

         

OSCAR的SQL引擎与PG存在一定的亲缘关系，因此在负载维度上我们完全可以参考PG数据库的并发和负载维度模型。

         

基于上述考虑，我们利用一天多的时间就完成了一个初步的健康模型的构建。这个模型目前还没有经过实战演练，必须在实际生产环境中通过几十个甚至上百个系统锤炼一阵子，才能更加贴近OSCAR数据库的真实状态。运维知识自动化系统就是这样一点点的构建起来的。

         

指标的采集还是完成得比较顺利的，在TOP SQL采集上我们遇到了一些问题，OSCAR没有类似ORACLE 的V$SQL（OSCAR的V$SQLSTAT里并不包含内存中SQL的完整统计信息），也没有类似pg_stat_statement这样的插件，v$session中的SQL_ID也总是空的，因此我们无法完成TOP SQL的采集工作，只能通过慢SQL采集来获得一些SQL语句。只能针对慢SQL分析应用，也减弱了针对OSCAR数据库的性能优化能力与复杂问题的定位能力。希望神通在后续版本中能够进一步优化OSCAR这方面的可观测性能力。

在研发部门与神舟通用专家的紧密配合下，慢SQL被成功的采集回来了。后续我们将针对慢SQL开发SQL审计、优化等方面的工具。

         

针对OSCAR的适配工作目前刚刚走上正轨，我们也和神舟通用的技术团队实现了对接，后续的工作会陆续开展。包括数据库日检、巡检、问题诊断、等待链分析、运维知识图谱、容量审计、SQL审计、智能异常检测、故障模型告警等方面的工作也将陆续展开。大概一个月后，支持OSCAR的测试版本可以封板。封板并不是本期研发的终点，而仅仅是实验室构建的完成，最重要的一步是后续的实际生产环境验证与运维知识的实战化构建工作。这项工作需要有大量的生产环境参与才能做好，如果哪位朋友家里有OSCAR数据库，欢迎和我们联系。