故障症狀
有一個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進行升級，看問題是否還存在。
故障處理
大致分以下幾個步驟進行：
- 先對數據庫做完整備份，以備不時之需，步驟不再贅述。
- 用yum remove指令刪除數據庫。
- 用yum install MariaDB-server MariaDB-client指令重新安裝數據庫。由於刪除數據庫軟件並不會刪除數據庫文件，如果運氣好的話，直接就可以啓動數據庫，並用指令mysql_upgrade進行升級。升級完畢，登錄Mysql，查看庫或者表是否被識別。
- 執行指令 systemctl start cbd 啓動服務，查看進程是否運行。
驗證
登錄Centreon Web管理後臺，查看Poller運行狀態，圖標變成綠色，則表示運行正常，故障處理成功。
繼續觀察數日，看故障是否還會重現。通過10多天的觀察，再也沒發生同樣的故障，如果有其它監控，可以把這個Centreon也給監控上。