昨天聊了些数据库可观测性能力与数字化运维的问题。我们希望利用对数据库的数字化建模实现高质量的远程服务。以往给用户提供服务的时候，专家需要到用户现场去采集数据，分析数据，这种模式工作效率太低了。而Oracle可以通过TFA采集相关的数据，让用户上传到MOS上，通过与用户的多次交互实现十分高效的远程支持。
图片
让专家不动er而让数据动起来肯定是效率最高的服务模式，而为了实现类似Oracle Support Service的远程服务，必须将各种能够反映出数据库健康状态的数据都采集起来，在Oracle数据库中这些数据采集是通过TFA/AWR/OSW三个工具组合采集的，Oracle通过TFA的统一接口来打包。在国产数据库中，我们必须把数据库能够提供的可观测性能力充分的利用起来，将这些数据完整的采集起来，使之可以在线/离线使用，为线上数据库服务提供支撑。
我们该如何利用数据库的可观测性能力来向远程支持服务提供充足的数据呢？最近我们正好在做神通OSCAR的运维知识图谱，通过这个案例我来分享一下具体实现的过程。
OSCAR虽然是基于PG早期版本魔改的（参考我前些天发的文章），不过其可观测性能力与PG已经完全不相干了，不过OSCAR在极力模仿Oracle，因此利用我们建设Oracle运维知识图谱的经验，还是可以简化这个过程的。
图片
首先要完成对运维对象的梳理，将其管理类、配置类、技术类的相关数据都能够被采集回来。OSCAR的主要指标都几种在v$sysstat等几张系统视图中，利用早期针对Oracle 9i的代码很快就可以完成这些采集工作。
图片
参考上图，我们针对OSCAR采集到了600多个指标。可能有朋友已经发现了，OSCAR的指标数据并没有那么多，而且我们的指标里有很多大家不太认识的指标。
图片
这是因为简单的指标是不足以进行自动化分析的，需要对指标进行相关加工。通过加工会生成一系列新的指标，我们把这个过程称为过程指标化。因为运维自动化系统对于指标的处理是十分丰富的，因此我们在整个过程中需要把大量的分析中间过程和中间结果都指标化。
能指标化的东西尽可能指标化，甚至包括日志和SQL。OSCAR只提供慢SQL，不能提供Top SQL，不过我们依然需要对SQL进行指标化处理。
图片
传统的数据库监控系统构建完指标体系后就基本上大功告成了，只需要构建一些基线模板，再加一些辅助工具，就可以用于监控了。不过基线模板仅仅能够提供简单的筛选功能，把存在问题的指标筛选出来显示在看板上供专家去参考。而数字化运维的核心是自动化分析与预警，因此大量的数据并不是给人看的，而是需要自动化处理的。当不需要运维人员干预的时候，智能化运维系统是在默默地工作的。
图片
如上图，虽然系统中出现了数万次基线告警（基于智能基线，不是简单的阈值），但是我们从系统汇总信息中没有看到需要人去干预的告警（上上图的左侧中间）。此时数据库系统虽然负载很高，性能也较差，但是系统判断目前还没有出现必须由运维人员手工处置的告警。
图片
我们不需要过多地关注指标基线的异常，而更多的需要关注关键指标的波动异常。一般来说，波动异常意味着数据库中存在某些指标的异常波动。我们需要将这些异常也都指标化了。指标化是简化自动化分析的关键。
图片
一旦将异常指标化后，我们就可以通过传统的正则表达式来做简单的预警了。比如活跃会话数超过某个阈值可能系统会存在风险，而更大的风险来自于活跃会话数的异常波动。利用这种异常波动来预警，将会有更好的效果。不断地丰富上面的故障模型是系统上线后需要持续不断去做的事情。
智能化运维系统需要在用户现场不断的积累新的运维知识，通过新的案例泛化后构建新的故障模型，通过故障模型的不断积累来不断提升系统的能力。D-SMART系统出厂交付给客户只是一个起点而不是产品的终点。产品在用户的环境中不断发现系统没有正常预警的案例，然后通过专家介入后对案例进行分析和泛化，构建出新的故障模型，这是D-SMART最初设计的模式。不过从目前的实践来看，客户方面缺乏数据库专家，因此在客户侧的个性化积累效果不佳。因此目前主要还是依靠我们团队帮助客户来积累知识。
图片
当远程的用户系统出现问题的时候，可以将监控数据打包发送给二线三线的专家。利用离线数据，远程专家可以协助分析故障。我们的工程师可以通过对数据的分析和故障现象的描述抽象出新的故障模型。
图片
构建完健康模型、故障模型后，接下来可以构建日检、巡检、周报、容量审计、SQL审计、对象审计等方面的巡检工具。也可以构建监控看板、关键Sql跟踪等方面的应用工具，以支撑关键业务的高质量运行需求。
图片
工具是面向场景的，我们通过运维工作的特点将所有工具的功能划分为监控中心、日检中心、告警中心、性能优化中心、报告中心、容量管理中心、安全中心、工程中心这几个中心。具体要做某些事情的时候，去这些中心里找自己所需的工具就可以了。
通过近一个月的适配，目前我们针对OSCAR数据库的功能已经适配完成，下一步就需要在我们的 第一个客户那里去运行一段时间，丰富一下故障模型，并进一步优化健康模型了。想要让D-SMART在OSCAR上具有与在Oracle上一样的能力，还需要数年时间的磨合。Oracle 数据库的智能化运维在D-SMART上已经经过了5年的打磨了，运维经验是专家30年的积累，而这一切在OSCAR上刚刚起步。如果某位同学正在使用OSCAR，有兴趣参与我们的运维知识梳理，那么可以和我们联系，我们可以提供一年免费试用。
下面我们来看看，完成OSCAR的数字化建模后，我们能够获得什么样的运维能力。
实例状态（健康、关键指标、容量、告警）
配置信息（基本配置、参数、表空间、组件、拓扑关系）
