标签:后缀 应该 alt mysql连接 使用 broker 情况 cat 原来
故障症状有一个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进行升级,看问题是否还存在。
大致分以下几个步骤进行:
登录Centreon Web管理后台,查看Poller运行状态,图标变成绿色,则表示运行正常,故障处理成功。
继续观察数日,看故障是否还会重现。通过10多天的观察,再也没发生同样的故障,如果有其它监控,可以把这个Centreon也给监控上。
标签:后缀 应该 alt mysql连接 使用 broker 情况 cat 原来
原文地址:https://blog.51cto.com/sery/2559614