基于Prometheus的openGauss监控系统的关键技术及验证

赵 伟， 王 蓓， 张士祁， 陈情晖， 周 兵

(1.郑州大学 网络空间安全学院 河南 郑州 450002； 2.郑州大学 计算机与 人工智能学院 河南 郑州 450001)

0 引言

在现代信息技术迅猛发展的同时，数据库系统作为计算机领域中的一项核心技术也得到了持续发展[1]。这期间不仅要求国内外数据库厂商研发出性能优异、功能强大、安全性高的产品，对监控数据库可用性的需求也日益增加[2]。早期的系统需要专门的技术人员通过登录数据库服务器定期检查各类性能指标，这种方法耗时耗力且不易及时发现错误[3]。因此，各种能同时监测维护数据中心设备的软件应运而生。大多数的国外商用数据库产品都提供了一些工具自动化监控过程，例如SQL Server的Performance Monitor、 Oracle的AWR、DB2的Performance Expert等。此外，企业还使用开源监测平台，例如国外的Zabbix[4]、 Nagios[5]和SolarWinds，国内的open-falcon、监控宝等。但是，上述这些监控软件只能针对特定的传统数据库。

为了处理大数据带来的4V特征[6]，研究者提出了分布式数据库、时空数据库等新型数据库。文献[7]针对分布式数据库HBase设计实现了性能监控系统；文献[8]提出一种可扩展的集群数据库监控机制云平台。近年来，人工智能和数据库技术的融合也促进了研究者采用机器学习的算法实现对数据库的监控。文献[9]通过预测DB系统临界状态概率来了解监控数据；文献[10]提出一种基于深度循环神经网络的数据库监控诊断框架AutoMonitor。但是这些工作都是以国外新型数据库作为研究对象，较少涉及对国产数据库尤其是openGauss的监控。

目前，openGauss有多种监控工具，例如WDR是一种性能收集和分析工具，openGauss提供的gs_checkos等工具可以完成系统状态检查。但是，这种传统的方式需要专业的管理员输入命令行来执行，效率低且性能差，而且没有统一的监控系统和管理页面，造成用户监控和维护数据库系统的不便。针对国产数据库中监控系统的不足以及现实的需求，本文设计并实现了一种新型的基于Prometheus的国产数据库openGauss监控系统，能够对数据库中的性能指标进行实时监测，并且提供统一的管理页面和监控指标可视化界面。

1 相关技术

1.1 Prometheus

Prometheus是一款由Google的Brogmon监控系统演变而来的开源型云原生监控系统，相对于传统的监控系统，其形成了基于中央化的规则计算、分析以及告警的新模型[11]，并受到云原生计算基金会(cloud native computing foundation，CNCF)的支持，经过几年的发展在社区十分受欢迎。

Prometheus自主研发了一套高性能的时序数据库TSDB，或者通过对接第三方时序数据库来扩展历史数据的存储。数据库中存储的所有数据都是时间序列，由Metric名称和labels键值对组成，且通过不同的labels表示不同的度量实例，可以进行多维度的数据监控[12]。同时，Prometheus定义了一套监控数据规范，并通过各种Exporter扩展系统采集能力。Prometheus监控原理如图1所示。

图1 Prometheus监控原理Figure 1 Prometheus monitoring principle

Prometheus由Server决定采集的目标，通过轮询的方式自动发现各个目标服务器，采用Pull模式采集时间序列数据。相对于Push的方法，这样不仅可以方便管理者在任意地点搭建监控平台，也可以避免有问题的服务器推送不准确的Metric。此外，可以提供查询语言PromQL，支持多种多样的图表和界面展示，比如Prometheus IU、Grafana等。

1.2 Grafana

Grafana是一个基于GO语言开发的数据可视化工具，它的库中具有丰富的图表、折线图、散点图、仪表盘等多种展示方式，使复杂的数据以一种直观的方式展现出来[13]。同时，它支持多种时间序列数据源，也可以在同一个图表中展示不同的数据源。Grafana还提供可视化构建器，用户可以绘制更多的Metric自定义监控界面。

通过对本文中提到的开源监控工具的特性进行分析，发现Prometheus + Grafana模式更适合于对openGauss数据库性能指标的监测。因此，在监控系统中引入了时序数据库Prometheus和可视化工具Grafana，以增强数据计算能力和显示能力[14]。

2 系统设计

2.1 系统流程

为了解决国产数据库缺乏统一的图形化监控界面的问题，本文设计研发了基于Prometheus的openGauss监控系统，并且提供统一的管理页面和监控指标可视化界面，方便用户监控和管理。openGauss监控系统流程如图2所示。

图2 监控系统流程Figure 2 Monitoring system flow

2.2 系统框架

数据库监控指标能够反映出数据库系统的健康状况。通过对数据库进行监控，分析指标数据特征或者变化趋势等信息，可以及时发现数据库的异常状况。本系统实现了openGauss数据库相关性能指标的采集、存储和监控，其框架如图3所示。

图3 监控系统框架Figure 3 Monitoring system frame

系统框架包括四个部分。其中，Host为openGauss数据库所在的服务器；Agent(openGauss-Exporter采集器)为数据库代理模块，负责收集数据库性能指标，并将数据提供给Prometheus Server；Prometheus Server是数据库异常检测和分析模块；可视化模块加载数据源，对数据库指标进行展示。下面介绍系统中的三个重要模块。

(一) Agent模块 该模块由IOC容器、Channel和Http Sink三个子模块组成，负责从数据库中采集并发送指标数据。

1) IOC容器采用MVC模式，通过Model层与数据库进行交互，Servlet层实现业务逻辑，Exporter在IOC容器中通过自定义Collector方法可以直接访问业务代码，定期收集数据库指标数据，并将数据发送到数据通道Channel中。

2) Channel是内存数据通道，本质上是一个数据结构类型，用于缓存查询到的性能数据，利用Http Sink组件访问Channel中的数据。

3) Http Sink是数据汇聚点，该模块实现Http的请求，周期性地向该服务器发送获取样本的请求，从Channel中获取数据并转换为Prometheus Server要求输出的格式，以Http的方式将数据进行转发，数据读取之后从Channel中清除。

(二) Prometheus Server模块 该模块由Retrieval、Storage和Http Server三个子模块组成，负责接收数据进行处理、存储和查询。

1) Retrieval采用Pull的方式为Agent采集到的数据提供接收接口，同时对数据进行处理，根据配置的数据格式或者标签转换等操作，将数据存储到本地数据库内部。

2) Storage为存储模块提供了本地TSDB时序数据库的存储方法，在完成对性能数据的一些操作之后，Prometheus会根据配置时间周期性保存数据到本地，当需要存储海量数据时，支持将数据存储到其他远程服务器上，实现监控和数据库分离。

3) Http Server提供Http接口查询和面板，通过该接口使用Prometheus Server提供的PromQL语言对数据进行语法解析，调用Storage模块查询接口获取TSDB中的监控数据，返回给可视化工具Grafana。

(三) 可视化模块 该模块由Grafana工具实现，主要用于大规模指标数据的可视化展现。在Grafana中配置来自Prometheus Server的数据源后，通过提供的风格统一的管理页面和数据可视化界面，实现对openGauss数据库中包括CPU占用率、数据库大小、缓存命中率、SQL连接数等性能指标的监控，根据各自的特点使用不同的展示方式，方便用户监控和维护openGauss，提升用户管理和维护openGauss的效率。

3 系统实现

3.1 Agent模块

3.1.1数据采集 根据对监控系统框架图的分析，发现Agent模块(openGauss-Exporter)是整个监控架构的桥梁，也是系统的核心部件。在Agent模块中定义了两种方法对数据库进行性能指标的采集。方法1是针对openGauss数据库提供的gs_checkos和gs_checkperf等工具需要Shell命令执行的特性，设计了一种直接调用并执行目标服务器Shell命令的方法；方法2是对openGauss数据库文件进行配置，然后通过用户账号直连数据库，使用SQL语句的方式采集性能的基本信息。两种方法的具体步骤如下。

方法1：通过建立与远程服务器控制台的连接，使用openGauss提供的gs_checkperf等命令。该方法的优点是可以对数据库级别、节点级别、会话/进程级别、SSD性能以及数据库负载情况等进行读取，然后通过算法1对得到的数据进行解析。

算法1处理Shell命令得到的数据

输入： Shell命令查询的结果cmdResult。

输出： InforMap。

1. 初始化得到的数据cmdResult

2. for each cmdResult do

3. Sring[] ← cmdResult.split("s+")

4. ∥对得到数据进行拆分并添加到数组中

5. end for

6. for i=1：String do

7. 通过正则表达式进行预编译

8. if String[i]匹配给定的正则表达式 then

9. numberList[i]←String[i]

10. end if

11. end for

12. for i=1：InforMap do

13. 为key[i]添加指标名称

14. for j=1：numberList[j] do

15. value[i] ← numberList[j]

16. ∥为InforMap添加指标数据值

17. end for

18. end for

方法2：通过与openGauss数据库直连的方式，对openGauss-Exporter进行授权，修改配置文件。通过配置文件中的账户信息连接数据库，执行相关的SQL命令，查询数据库性能等基本信息。该方法的优点是可以使用功能强大的SQL语句，对数据查询所用时间、某条SQL操作所用资源进行细致的监管，使获得的性能数据更加精细化，使用算法2对查询到的数据进行解析。

算法2处理SQL语句得到的数据

输入： 要查询的SQL语句。

输出： number。

1. set 要查询的SQL语句，并进行预编译

2. 得到SQL查询结果ResultSet

3. for each ResultSet do

4. ∥提取ResultSet中的查询结果

5. while ResultSet.next() do

6. ∥根据要查询的性能指标设置相应的数据类型

7. number ← ResultSet

8. end while

9. end for

3.1.2数据格式转换 通过3.1.1中的两种方法采集到的指标类型繁多，且需要使用不同的方式进行展示。针对数据库中的数据指标进行分析，先通过算法3指定显示的Metric类型，之后添加数据标注，转换数据类型，按照Prometheus的规范返回监控数据。

算法3数据格式转换

输入： 从算法1和2得到的Data。

输出： Samples。

1. 初始化从算法1和2得到的Data

2. set metricName∥定义一个数据类型

3. for each Data do

4. if Data使用 metricName类型表示 then

5. Sample ← Data∥数据类型转换为Sample实例

6. 同时添加metricName、labelNameArray、labelValueArray、Data到实例中

7. end if

8. end for

9. 添加所有Samples到MetricFamilySamples中

10. 指定当前监控指标的名称、类型、注释信息等

数据格式转换由 Metric 名称和一系列键值对作为唯一标识标签，不同的标签代表不同的时间序列。例如，Metric的名称Database_performance_indicators，标签为type= “Active_SQL_count”，表示为Database_performance_indicators{type=“Active_SQL_count”}4.0。

3.1.3封装样本数据 对经过格式转换过的数据进行收集，一种方法是使用拦截器，但这种方法用于统计所有应用请求的情况且存在一定的缺陷，会发生数据有异常而管理者不能及时发现的状况[15]。故采用另一种自定义Collector的方法实现对监控样本的收集，Client Collector只会在每次响应Prometheus Server请求时才会收集数据，并且显式传递变量的值。Collector是一个接口，所有收集Metric数据的对象都需要实现这个接口，接口包含两个无状态的函数方法Describe和Collect。其中，Describe暴露出完整的指标描述符列表到Channel，用以监测Metric定义的冲突；而通过 Collect 可以获取最新的数据，然后传递给Channel存储。

根据3.1.1中的收集方式自定义两个Collector类：CommandCollector和GaussSQLCollector。所有自定义指标收集类都要调用register()方法，将该实例保存到CollectorRegistry中，它负责维护当前系统中所有的Collector实例。当其中的Http Sink接口接收到请求后，会从CollectorRegistry中拿到全部的Collector实例，并调用collect()方法获取所有样本，最后进行封装为Prometheus格式的标准输出。Agent模块处理流程如4所示。

图4 Agent模块处理流程Figure 4 Agent module processing flow

3.2 Prometheus Server 模块

openGauss-Exporter将监控到的性能数据通过Http服务的方式暴露给Prometheus Server，再将节点信息添加到配置文件中，并通过Web方式管理监控节点。同时，使用TSDB来存储监控数据。TSDB按照固定的时间间隔“垂直”地写入最近的所有时间序列数据，通过“横向”的方式面向一个或多个时间序列进行读取操作，由于存在一个缓冲时间才会把数据写入，故按2 h作为一个块进行存储，这样既可以节省本地存储的空间，又可以提高数据计算时间效率。

4 系统安全

4.1 关键信息设备的安全性分析

关键信息设备安全是监控系统都需要考虑到的问题[16]，涉及系统运行中所有关键设备的安全问题，包括CPU运行的情况，内存和磁盘等存储设备的保管，以及监控系统所运行的服务器周围的环境。管理员要保证合适的温度和湿度，防止电磁干扰，以免造成数据的损坏或丢失。本系统监控的数据库和openGauss-Exporter均运行在华为云服务器中，华为云已经通过了国际安全认证，在云服务保障中具有领先实力，可以保障软件运行的安全性。

4.2 数据指标传送的安全性分析

监控系统中需要传输大量的监控指标数据来显示目前的运行状态，然后提供给监控工作人员进行分析。在监控指标数据传输过程中会受到如窃听、数据篡改以及黑客恶意攻击等很多安全威胁，故应做好安全方面的措施。在本系统中使用Prometheus作为监控数据库的服务器，保证了监控过程的安全性。在Prometheus服务器的Http服务端点上，支持内置的TLS以及身份验证功能。TLS[17]是专门用于保护Web通信的，在通信过程中使用记录协议和握手协议来保证Prometheus服务器和openGauss-Exporter之间数据交换过程的安全性和完整性。同时，在Prometheus提供的时间序列数据库中添加日志，对监控操作进行记录。

4.3 监控数据可视化的安全性分析

Grafana使用身份验证的方式登录界面，进行远程监控数据库，这样可以保证只有指定身份的管理员才能登录查看数据库性能指标数据[18]。通过Grafana可以查看较长一段时间内的操作系统指标、数据库基本性能、读写数量、查询/事务统计等，对数据库中的资源进行合理的分配，识别可能会发生瓶颈的值以及在一定程度上帮助管理员对未来性能进行预测。

5 实验

5.1 实验环境

选择华为云作为测试实验的硬件支撑，包括CPU、内存、公网IP和云存储等。实验测试环境如下：监控节点使用VMware Workstation Pro 16，Centos 7.6，内存16 GB，硬盘20 GB，Firefox 浏览器68.5.0；被监控节点部署在华为云上，使用Centos 7.6，openGauss 2.0，鲲鹏计算2vCPUs，内存4 GB。

5.2 系统监控结果

针对openGauss数据库研发了一种新型的基于Prometheus的性能指标监控系统，目前已实现了对openGauss的44种性能指标进行监控和可视化工作。实验中，向数据库添加测试数据并对数据进行一些操作，修改数据库的配置信息，对得到的部分监控数据进行分析。

监控数据包括openGauss数据库的基本配置信息，如服务器当前时间、数据库运行时间，数据库端口号为26 000，工作内存为2 MB，数据库共享内存为128 MB，对数据库设置的最大用户连接数为5 000。会话临时缓冲区为1 MB，以防止不必要的数据块从磁盘中重读。选择合适大小的缓冲区来提高命中率，可以提高访问速度。服务器执行堆栈的最大安全深度默认为2 M，如果发现不能运行复杂的函数，则可以适当地提高此参数的值。

本文对用于存储的Wal日志缓冲区数目、Wal日志写入磁盘的周期、Wal延迟时间进行监控。Wal日志是数据库中非常重要的部分，当在数据库中更新数据时，Wal会把这些操作记录到日志中再写入磁盘，保证了数据的完整性，且在数据库发生故障时用来恢复数据库。本文对数据库端和客户端之间的Keepalives相关信息也进行监控，包括最大发送次数、发送间隔等，使管理员对数据库与客户端之间的数据传输过程进行优化，从而实现高可用。同时，对openGauss运行30 min的基本性能进行监控。监控结果显示，有7个客户端对数据库服务器进行访问；活跃SQL连接数表示正在执行的客户端线程总数，目前有4个线程可能在消耗CPU、IO或者等待锁释放；数据库CPU占有率在开始一次性批量插入数据时达到一个最高值(65%)，之后对数据库进行SQL操作，占有率便逐渐下降；数据库存储值也在添加数据后由41%提升到42%。同时，每15 s对数据库的物理读写进行一次统计，随着对数据库中数据访问次数的增加，缓存命中率也在逐渐升高，最高能达到99.8%。

对数据库中提交事务的操作进行监控，图5显示了事务增长率的变化情况。可以看出，事务增长率有较大的变化。开始时，由于频繁的添加操作导致事务增长率有明显的增加；之后便略有起伏，说明提交事务的操作在平稳进行；随着时间的增加，有多个操作访问数据库可能产生并发事务，会发生抢占CPU、被堵塞以及事务故障等状况，事务提交量骤降，这时需要管理员及时检查数据库是否进入了非健康的状态。

图5 事务增长率的变化Figure 5 Change in transaction growth rate

5.3 系统性能测试

数据库性能的监控需要保证数据采集过程的实时性和准确性，监控操作要求系统的响应时间尽可能短，本实验对openGauss-Exporter两种方法连接数据库时间、数据查询时间、Prometheus服务器的请求响应时间分别进行性能测试分析。

5种测试指标的响应时间结果如图6所示。图中数据均为一次采集过程测试10次的平均值。其中，性能指标1为MPPDB_CPU_time_in_busy_time，表示数据库CPU占用率；性能指标2为Shared_buffers，表示缓存的大小；性能指标3为Active_SQL_count，表示活跃SQL连接数；性能指标4为deadLock-Count，表示死锁数；性能指标5为All_Table_Recorder，表示每秒全表扫描记录数。性能指标1和3由Shell命令进行查询；而性能指标2、4和5由直连数据库执行SQL语句进行查询。

图6 5种测试指标的响应时间Figure 6 Response time of 5 kinds of test index

由图6可知，使用Shell命令采集数据比使用SQL语句采集数据的总体响应时间要长，最长响应时间比达到11倍。Shell命令的连接时间和数据查询时间均在750 ms以上，而数据查询时间要比连接时间略长；SQL查询的方法对性能指标4的连接时间稍长，其他的连接时间和查询时间均在250 ms以内。两种方法的总响应时间都在2 s内，一定程度上也保证了对openGauss数据库中性能指标数据进行实时监控的及时性和准确性。

对Prometheus服务器的请求响应时间进行分析，结果如图7所示。可以看出，70%的请求响应时间在40 ms以内，90%的请求响应时间在70 ms以内，说明Prometheus服务器的大部分请求响应是比较快的。另外，95%的请求响应时间在120 ms以内，还有5%的请求响应时间可能会大于120 ms。这是由于在对openGauss-Exporter请求监控数据时，会有较小一部分在网络、服务器性能等方面耗费了大量的时间。

图7 请求响应时间Figure 7 Request response time

6 结束语

本文提出一种新型的针对openGauss数据库的性能监控系统，设计了一个数据采集器openGauss-Exporter，从openGauss数据库中采集性能指标数据，并通过Prometheus和Grafana对收集到的指标数据进行可视化工作。对openGauss 2.0数据库进行实时监控实验，结果表明，所提出的监控系统能够接收到openGauss数据库的44种性能指标，并提供一个完整的界面方便用户管理，研发系统是安全可靠且性能高效的。未来的工作包括在此系统的基础上实现更多的数据库性能指标监控；添加告警预测模块，通过对一段时间的性能分析形成事前预警。同时，随着监控规模的增加，将对监控系统本身所带来的性能问题进行优化。