GaussDB(DWS)数据库智能监控运维服务体系分析与设计概要-一一网

【摘要】早期，数据库仅仅提供SQL命令来查询其内部的运行状态，导致数据库运维操作门槛高，易用性差，DBA一度成为高度专业化的关键岗位，享受高薪和大家羡慕的目光的同时，也为企业的数据安全带来了不确定性风险。并且，命令行运维不直观，严重依赖运维人员经验，不能做到快速的发现、定位、解决问题，导致数据库运维问题，发现难，定位难，解决难。为了应对这种情况，数据库运行数据的可视化…

早期，数据库仅仅提供SQL命令来查询其内部的运行状态，导致数据库运维操作门槛高，易用性差，DBA一度成为高度专业化的关键岗位，享受高薪和大家羡慕的目光的同时，也为企业的数据安全带来了不确定性风险。并且，命令行运维不直观，严重依赖运维人员经验，不能做到快速的发现、定位、解决问题，导致数据库运维问题，发现难，定位难，解决难。

为了应对这种情况，数据库运行数据的可视化（数据库监控系统）应运而生，通过可视化的手段以人类便于理解的图表形式，将重点数据以图形化的手段展示给运维人员，从而显著的降低了数据库运维的门槛，提高了数据库运维的效率。随着云时代的到来，云数据库托管了客户的数据存储服务，云化将一切繁重的IT运维工作都集中在云后台管理了起来，从而把客户从专业，复杂，繁重的数据中心运维活动中解放了出来，使客户能够更加专注于其核心业务。另一方面，云服务提供商作为数据存储服务的提供者，则需要在IT运维与数据库运维上深耕细作，发挥其团队稳定，专业化程度高，掌握海量数据库运行数据的优势，充分利用目前机器学习、人工智能领域的科研成果，使用技术手段逐步提高每名运维人员所能管理的数据库数量，优化云端运维体验，从而实现“减员增效”。

数据库智能监控运维体系规划

数据库智能监控运维体系

传统意义上的数据库监控服务仅仅是指（1）采集数据库运行状态；（2）上报/存储数据库运行数据；（3）图形化展示数据库运行状态数据。但是，这仅仅是数据库智能监控运维体系的一部分。

如果把整个数据库智能监控运维体系比作一个人的话，传统意义上的数据库监控服务仅仅代表了，眼睛的角色。该服务只能做到发现问题，识别定位问题和解决问题都需要DBA的介入。因此DBA才是传统数据库监控运维体系中的核心要素，这也是DBA人才为何如此关键的原因之一。

而云时代的到来和大数据分析、人工智能等技术的成熟，给了数据库监控运维更多的想象空间。我可以在传统数据库监控（眼睛）的基础上，增加预测分析和根因判断模块，建立现象-根因-解决方案的映射关系（大脑），最后通过数据库管理模块执行解决方案（双手），从而实现从发现问题，定位问题，到解决问题的运维闭环。

并且机器不同于人类，只要算力允许，它可以做到眼观六路，耳听八方，不知疲倦，也不会觉得无聊，7×24的盯着成百上千数据库系统的各种运行数据，不会放过任何一个微小的潜在问题。

友商的数据库智能监控体系

综合来看目前亚马逊在云数据库的智能监控体系上切入的比较早，也发展了很多成果。相对而言，其他传统厂商在数据的智能监控体系上虽然各有所长，但是并没有像亚马逊一样能够形成运维闭环。

更多的友商智能运维产品分析和对比相关内容，我们就不在这里赘述了，后续我们会专门有相关专题展开讨论。

基于DMS的数据库智能监控体系设计

参考友商数据库监控运维体系的建设经验，结合GaussBD(DWS)数仓的自身特点，我们准备从眼，脑，手三个方面发力建立闭环的数据库智能监控运维体系。

DMS定义了监控，分析，处理三个部分，分别对应上文提到的数据库智能运维体系中的眼，脑，手三部分，从概念设计上形成运维体系的闭环。

监控部分：主要负责数据库运行状态数据的采集、存储和可视化展示，这一部分基本等同于传统的数据库的监控业务。这一部分功能和指标的选取，我们参考了友商以及运维团队的建议，将监控指标分为底层IT系统运维指标和数据库系统运维指标两类，正在分别逐步补齐和完善中。监控模块是DMS数据库运智能监控运维体系首先发力，并要在短时间内形成竞争力的模块。

分析部分：作为整个DMS数据库智能运维体系的大脑，该部分是承担运维数据分析与决策的关键模块。该部分因为其复杂性，目前还处于设计构想阶段。初步规划有三个子模块，时间序列的趋势分析子模块，该模块主要用来做趋势预测分析，用来预判潜在的问题；逻辑推断子模块，用户分析问题现象与实际根因之间的关系，可以实现从问题现象到触发原因的推断，初步考虑使用搜索引擎技术实现；知识图谱子模块，主要用于现象、根因与解决方案之间的映射关系表示，方便从定位的根因中找到最合适的解决方案。

处理部分：主要由DWS提供的数据库管理功能承担，目前可以提供数据库参数配置（可配置参数少，需要进一步丰富），工作负载队列配置，集群安装/卸载，集群重启，集群扩容，集群数据重分布以及节点温备等运维能力。

数据库监控用户角色

通过分析数据库监控系统的各种使用场景，我们对数据库监控系统的用户做了用户角色画像，定义了数据库运维过程中的三种角色，并认为不同角色仅仅关注数据库运维的一个侧面。在实际的数据库运维场景中，可能同一个用户会身兼多种角色，但是这里我们为了方便分析仅仅从逻辑上定义这三种角色。

应用开发工程师：主要指客户侧的应用开发角色，他们负责设计具体的业务SQL。他们关心业务SQL执行的正确性和执行效率。应用开发工程师需要用到web SQL来调试其SQL语句的查询效率；需要用到查询监控页面来查看业务SQL在实际执行场景中的表现和资源消耗；需要用到工作负载队列监控来确认新开发的业务SQL是否在合适的工作负载队列中，所配置的熔断规则是否合理，等等。

SRE：指的是华为云侧的数据库运维角色，他们通常一个人需要负责几百个集群的稳定运行，他们需要能够迅速识别出集群运行状态的异常，集群资源瓶颈以及集群潜在的扩容需求，并且他们还需要积极响应客户的求助，帮助客户定位，确认和解决问题。SRE需要节点资源监控来识别集群中的资源倾斜；需要识别集群资源消耗基线变化趋势，从而识别到扩容需并提醒用户；需要关注存储变化以推算下一次常规保养的时间点并自动规划；同时还需要响应用户需求，使用DMS提供的问题定位工具，辅助用户定位现网问题。

DBA：指的是GaussDB(DWS)数据库集群专家，他们熟悉数据库设计方法论，数据库的调优，数据库问题定位。他们需要帮助用户从业务、数据库设计的角度去推荐数据的索引，分布列的配置，建议数据库的分库分表设计，根据用户业务推荐购买的集群规模等等；也需要分析优化数据库的运行性能，从资源和业务角度分析系统的稳定性和潜在的系统瓶颈；同时需要辅助应用开发工程师调优写的不好的SQL语句；或者辅助SRE定位复杂问题的根因。

在现网场景中，用户角色一般只有应用开发和SRE两种，现网场景中的SRE角色往往涵盖了DBA的角色。我们在这里将运维角色细分的目的，其实是要展示一个完整的运维场景沙盘，将客户的运维诉求分门别类的列出来，为后续进一步的指标设计和运维场景设计提供基础。

DMS数据库监控指标设计

数据库是一个软件服务，而它必须运行在一个宿主机和操作系统之上，因此监控指标大致可以分为两类：

系统资源类指标：这一类指标主要描述系统上的各种资源消耗
数据库相关指标：这一类指标主要描述数据性能相关的业务资源消耗

上图总结了DMS主要采集的数据库指标，该指标地图并不固定，依然在演进中。

因为MPP数据库的特殊构型，数据库实例是作为进程试运行在节点上的。因此，我们的指标设计其实本身会自带维度属性，比如磁盘使用率指标，最小的维度应该是某个DN实例，上一级是节点级，再上一级就是整个集群。为了描述这种情形，我们引入原子指标，派生指标和组合指标的概念。以上面的磁盘使用率为例，我们将DN实例的磁盘使用率作为原子指标，而其他维度的磁盘使用率作为派生指标。