国产化监控方案：金仓数据库 + Nagios 从零搭建指南，核心指标实时掌握

前言

在数据库运维工作中，实时掌握数据库状态、及时发现潜在问题是保障业务稳定运行的关键。Nagios作为开源监控领域的标杆工具，凭借其强大的实时监测能力，是当今运维团队的“得力助手”。而现在金仓数据库已实现与Nagios的完美适配，可以快速来搭建高可靠、易扩展数据库监控解决方案。下面我就来看看整个搭建过程吧！

一、环境准备：安装三大核心组件

Nagios监控体系主要由Nagios Core、Nagios Plugins和NRPE三大核心组件构成，这些组件需分别部署在监控服务器（监控端）和被监控数据库服务器（被监控端）。

1.1 安装Nagios Core（监控端）

Nagios Core是整个监控体系的主监控程序，安装过程需在监控端操作，且需要root权限：

1. 首先下载并解压Nagios Core安装包，执行以下命令：

wget https://github.com/NagiosEnterprises/nagioscore/archive/refs/tags/nagios-4.5.9.tar.gz
tar -zxf nagios-4.5.9.tar.gz && cd nagioscore-nagios-4.5.9

2. 接着进行编译安装，命令如下：

./configure && make all && make install

1.2 安装Nagios Plugins（监控端与被监控端均需安装）

Nagios 核心本身不具备 “主动采集数据” 的能力，所有对监控目标（服务器、网络设备、应用、数据库等）的状态检测，都必须通过调用对应的 Plugins 来完成，所以我们还要安装下面Nagios Plugins。

1. 下载并解压插件安装包：

wget https://github.com/nagios-plugins/nagios-plugins/archive/refs/tags/release-2.4.12.tar.gz
tar -zxf release-2.4.12.tar.gz && cd nagios-plugins-release-2.4.12

2. 执行编译安装命令：

./configure && make && make install

1.3 安装NRPE（监控端与被监控端安装内容不同）

NRPE是我们实现 “跨机器远程监控” 的核心组件。如果没安装NRPE，Nagios 只能监控 “自身所在的服务器”，无法实现企业级的分布式监控。所以我们也的得把NRPE给安装一下：

监控端：仅需安装check_nrpe插件用于通信，操作如下：

1. 下载并解压NRPE安装包：

wget https://github.com/NagiosEnterprises/nrpe/archive/refs/tags/nrpe-4.1.3.tar.gz
tar -zxf nrpe-4.1.3.tar.gz && cd nrpe-nrpe-4.1.3

2. 编译安装插件：

./configure && make all && make install-plugin

被监控端：需要完整安装，包括守护进程，步骤如下：

1. 同样先下载并解压NRPE安装包（命令同上）；
2. 执行完整的编译安装命令：

./configure && make all && make install-plugin && make install-daemon && make install-daemon-config

二、基础配置：构建监控体系框架

完成核心组件安装后，我们还需进行基础配置，包括创建专用用户、了解配置文件结构以及调整默认配置，来为我们后续监控金仓数据库做好准备。

2.1 创建用户、用户组与配置权限

为保障 Nagios 监控体系的安全性与运行独立性，需优先创建 Nagios 专用的用户及用户组，并为其配置符合监控需求的权限。

1. 创建专用用户和用户组：

useradd -m nagios
groupadd nagcmd

2. 将nagios用户和Web服务用户加入监控组（若通过Web访问Nagios）：

usermod -a -G nagcmd nagios
usermod -a -G nagcmd apache

2.2 熟悉核心配置文件结构

为便于后续精准调整监控规则，需先熟悉 Nagios 核心配置文件的结构，Nagios的配置文件集中在/usr/local/nagios/etc目录下，不同配置文件承担着不同的功能，下面是每个配置文件的简要功能描述：

配置文件/目录	功能描述
nagios.cfg	主配置文件，控制Nagios的全局设置
nrpe.cfg	被监控端配置文件，定义可执行的监控命令（部署于被监控服务器）
objects/	存放主机、服务、命令等配置文件的目录
commands.cfg	监控命令定义文件
localhost.cfg	存放本地主机的服务以及主机相关配置
services.cfg	定义需要监控的具体服务（如金仓数据库用户数监控），需用户创建并赋权
hosts.cfg	记录被监控主机的IP、别名等信息，需用户创建并赋权
templates.cfg	内置通用模板（如generic-service），简化配置

2.3 禁用默认配置并创建自定义文件

在远程监控金仓数据库的场景中，Nagios 默认配置（如本地主机监控配置）无法满足跨机器监控需求，因此我们需先禁用默认配置，再来创建适配远程监控逻辑的自定义配置文件。

1. 编辑nagios.cfg文件，注释掉默认的localhost.cfg配置：

# cfg_file=/usr/local/nagios/etc/objects/localhost.cfg

2. 进入/usr/local/nagios/etc/objects目录，创建自定义的hosts.cfg和services.cfg文件：
   • 创建hosts.cfg配置文件并赋权：

   cd /usr/local/nagios/etc/objects
   head -51 localhost.cfg > hosts.cfg
   chown -R nagios.nagios hosts.cfg
   

   • 创建services.cfg配置文件并赋权：

   touch services.cfg
   chown -R nagios.nagios services.cfg
   

三、金仓数据库专属监控脚本配置

为了实现对金仓数据库的精准监控，所以需要我们配置专属的监控脚本，包括自定义监控指标脚本、部署脚本并配置权限，以及在NRPE中注册脚本命令。

3.1 自定义数据库监控指标脚本

以查询数据库用户数为例，我们可以通过Shell脚本调用金仓数据库命令，将结果输出为Nagios可读格式，以下是一个示例：

#!/bin/bash
host="192.168.55.33"  # 数据库服务器IP
port="54327"  # 数据库端口
user="system"  # 数据库用户名
passwd="system"  # 数据库密码
database="test"  # 数据库名称
sql="select count(1) as user_num from sys_catalog.sys_user"  # 查询用户数的SQL语句# 执行SQL查询并获取结果
result=$(/home/KESV9/Kingbase/Server/bin/ksql -h ${host} -p ${port} -U ${user} -d ${database} -c "${sql}" 2>&1)# 判断查询是否成功
if [ $? -ne 0 ];thenecho "connect failed,because:$result"exit 1
fiecho "$result"

3.2 脚本部署与权限配置

1. 将编写好的check_kes.sh脚本上传到被监控端的/usr/local/nagios/libexec/目录；
2. 为脚本赋予执行权限，命令如下：

chmod +x /usr/local/nagios/libexec/check_kes.sh

3.3 配置NRPE允许执行脚本

为了让 Nagios 监控端能远程调用被监控端的金仓数据库监控脚本，我们需要在被监控端的nrpe.cfg文件中注册脚本命令，来建立 NRPE 与脚本的关联，从而确保脚本可被正常触发。

1. 编辑nrpe.cfg文件，添加以下内容：

command[check_kes]=/usr/local/nagios/libexec/check_kes.sh

2. 重启NRPE服务，使配置生效（具体重启命令根据操作系统而定，如systemctl restart nrpe）。

3.4 金仓数据库可监控指标清单

目前，金仓数据库提供50+相关数据库监控指标脚本，覆盖数据库监控全场景，部分关键脚本如下：

• license相关：license_validdays.sh
• 性能相关：qps.sh、tps.sh
• 系统表相关：sys_class.sh、sys_class_age.sh
• 数据库状态相关：sys_database_age.sh、sys_database_size.sh、sys_is_in_recovery.sh
• 锁相关：sys_lock.sh
• 复制相关：sys_replication_slots.sh、sys_stat_replication.sh、sys_stat_wal_receiver.sh
• 统计信息相关：sys_stat_activity.sh、sys_stat_archiver.sh、sys_stat_bgwriter.sh、sys_stat_database.sh

我们可以通过金仓社区下载这些脚本，金仓技术团队也会定期迭代脚本，并且还能通过社区反馈定制监控需求。

四、配置监控规则：实现Nagios与NRPE联动

完成上述配置后，需要在Nagios中定义监控命令、配置被监控主机和具体的监控服务，实现Nagios与NRPE的联动。

4.1 定义监控命令（commands.cfg）

在监控端的commands.cfg文件中添加check_nrpe命令，就可以告诉 Nagios：如何调用check_nrpe工具，下面是用于调用被监控端的脚本：

define command{command_name check_nrpecommand_line $USER1$/check_nrpe -H $HOSTADDRESS$ -c $ARG1$# 说明：$USER1$ 指向Nagios插件目录（默认/usr/local/nagios/libexec/），$HOSTADDRESS$ 自动获取hosts.cfg中定义的主机IP
}

4.2 配置被监控主机（hosts.cfg）

在hosts.cfg文件中定义被监控的金仓数据库主机信息：

define host{use linux-server  # 使用Nagios内置Linux主机模板host_name kingbase-server  # 主机唯一标识（需与services.cfg一致）alias Kingbase Database  # 主机友好名称（显示在Web界面）address 192.168.55.33  # 数据库服务器实际IPmax_check_attempts 5  # 最大检测重试次数（默认5次）
}

4.3 定义监控服务（services.cfg）

在services.cfg文件中定义针对金仓数据库的具体监控服务，以监控数据库用户数为例：

define service{use generic-service  # 使用默认服务模板host_name kingbase-server  # 关联的被监控主机名称（与hosts.cfg中一致）service_description Kingbase User Count  # 服务名称（显示在Web界面）check_command check_nrpe!check_kes  # 调用监控命令（格式：check_nrpe!自定义指标名）check_interval 5  # 监控间隔（单位：分钟）retry_interval 1  # 重试间隔（单位：分钟）max_check_attempts 3  # 最大重试次数
}

五、验证与展示：查看实时监控数据

当所有配置（含监控命令定义、被监控主机与服务关联、NRPE 联动设置）完成后，我们就可以通过 Nagios Web 界面直观查看金仓数据库的实时监控状态，实时掌握数据库运行动态了。

5.1 测试配置有效性

首先在监控端执行以下命令，验证check_nrpe命令是否能成功调用被监控端的check_kes脚本：

check_nrpe -H 192.168.55.33 -c check_kes

如果能正常返回数据库用户数信息，则说明配置生效。

5.1 通过Web界面查看监控状态

1. 访问Nagios Web控制台：在浏览器中输入http://监控服务器IP/nagios（例如http://192.168.55.33/nagios）

3. 登录系统：使用默认账号nagiosadmin、密码nagiosadmin登录（首次登录建议修改密码，保障安全性）；

5. 查看监控详情：登录后，进入Services→Kingbase Database→Kingbase User Count，即可查看金仓数据库用户数的实时监控状态。

5.3 监控状态标识说明

下面我们就可以通过 Nagios Web 的界面，来观察金仓数据库的监控结果了。通过不同的状态标识他们分别对应明确的监控结果含义，能帮助运维人员快速判断数据库当前运行状况

• OK：指标正常（如用户数在阈值内），数据库运行状态良好；
• WARNING：指标接近阈值，需运维人员重点关注，预防问题扩大；
• CRITICAL：指标超限，系统会触发邮件/短信告警，运维人员需立即处理，避免影响业务。

总结

以上我们就实现了金仓数据库 + Nagios 从零搭建数据库的监控解决方案。是不是非常的方便通过 Nagios 我们可以实时掌握金仓数据库状态、及时发现潜在问题是保障业务稳定运行的关键。这些都得益于金仓数据库开放兼容的技术生态，在今后，金仓数据库将持续优化生态适配能力，提供更多开箱即用的监控解决方案，助力企业构建自主可控的数据库运维体系。