故障症状

有一个Centreon 单节点监控系统（不含分布式），隔三差五的挂掉，幸好我们安排人手，时不时访问web管理后台，才没出现大的纰漏。其主要症状是Poller失效，但系统其它进程比如Apache、PHP、Centreon-engine等运行正常。 在Centreon Web管理界面重载（reload）或者重启（restart）cbd服务，无效；登录系统，执行指令systemctl start cbd ,也无效，只能重启系统，才能正常。因为这个Centreon 是部署在PVE（Proxmox VE）平台，以虚拟机形式承载的，相关人员不胜其烦，认为是PVE的问题，打算将其备份，然后恢复到PVE的其它物理节点。我想了一下，PVE上那么多虚拟机，虽然是其它应用，但都没出现问题，而且出问题是Centreon的一个应用cbd而已，与虚拟机本身的关系不大，应该另有原因。

分析思路

既然其它服务正常，那么我们就从有故障的cbd服务入手。找到cbd日志所在的目录，其完整路径为/var/log/centreon-broker,查看其下的文件，其大致情况如下：

虽然日志文件很多，但能查到有用信息的文件是centreon-master.log这个，在个案里边，解决故障的日期是11月25日，因此我就查看文件central-broker-master.log-20201125，如果时间再久远一些，系统会自动把旧文件压缩打包，以.gz的形式结尾。Centreon 自带工具zcat，可以直接查看.gz结尾的文件。这里，我随机打开一个，看是否有收获。 果然有报错信息，原来是数据库连接不上。再查看一下11月25日那个日志文件，因为这个文件比其他文件都大，信息应该更详细。 根据报错信息，我的解读就是：Mysql连接不上，导致cbd服务不能正常运行。那么好办，mysql就在本机，顺藤摸瓜查看mysql是什么状况。

先看mysql进程是否运行，哦豁！没运行呢。前边只顾查看centreon开头的进程是否运行，给mysql忘记了。原来肯定是运行着的，不然监控一直就应该处于不正常状态。看了一眼系统日志及磁盘空间使用情况（怕磁盘塞满），未发现有用信息，那么剩下的地方就是Mysql错误日志可以作为选择目标，其所在路径为/var/lib/mysql，文件名以主机名加.err后缀结尾. 打开它，看看到底什么原因所致。 初步判断是字符集的问题。为什么会出现这个问题，可能的原因是我经常对系统执行yum update 升级系统，其它的软件包升级都正常，而Mariadb却没有一次升级成功的。于是就计划尝试对Mariadb进行升级，看问题是否还存在。

故障处理

大致分以下几个步骤进行：

1. 先对数据库做完整备份，以备不时之需，步骤不再赘述。
2. 用yum remove指令删除数据库。
3. 用yum install MariaDB-server MariaDB-client指令重新安装数据库。由于删除数据库软件并不会删除数据库文件，如果运气好的话，直接就可以启动数据库，并用指令mysql_upgrade进行升级。升级完毕，登录Mysql，查看库或者表是否被识别。
4. 执行指令 systemctl start cbd 启动服务，查看进程是否运行。

验证

登录Centreon Web管理后台，查看Poller运行状态，图标变成绿色，则表示运行正常，故障处理成功。 继续观察数日，看故障是否还会重现。通过10多天的观察，再也没发生同样的故障，如果有其它监控，可以把这个Centreon也给监控上。