基于Zabbix 的Veritas Cluster Server集群管理系統(tǒng)的監(jiān)控技術

貴州省氣象信息中心 金石聲 白鐵男 譚海波 唐維堯

本文基于開源架構的Zabbix 監(jiān)控系統(tǒng)，對省級氣象數(shù)據(jù)收發(fā)系統(tǒng)CTS（Collection and Transfer System）集群的管理軟件VCS（Veritas Cluster Server）所承載的各項業(yè)務進行精細化監(jiān)控。系統(tǒng)從資源組層面實現(xiàn)了對CTS 集群業(yè)務運行狀態(tài)的集約化監(jiān)控，并以拓撲圖的方式展示了各資源組的運行狀態(tài)，通過動態(tài)圖標之間的連線直觀地了解資源組之間的業(yè)務依賴關系，在實際工作中精準的定位故障，極大地提高了核心業(yè)務系統(tǒng)的運行維護效率，符合氣象信息化和現(xiàn)代化的基本要求。

省級氣象數(shù)據(jù)收發(fā)系統(tǒng)CTS（Collection and Transfer System）。作為氣象資料交互的核心業(yè)務系統(tǒng)，承擔著氣象資料的收集、處理、分發(fā)等業(yè)務。為了保證系統(tǒng)的高可用性，采用了VCS（Veritas Cluster Server）集群管理軟件對CTS 集群的應用進行管理[1]。VCS 集群管理軟件雖然提供了管理界面，但是界面過于簡單，只適用于對應用進行管理，不具有基本的告警展示、推送功能，無法滿足集約化監(jiān)控的要求[2]。為解決上述問題，基于開源架構的Zabbix 監(jiān)控平臺自由度高、拓展性強的優(yōu)勢，通過梳理VCS 集群管理軟件上的資源組情況，設計并開發(fā)了專門針對CTS 的監(jiān)控系統(tǒng)。

1 架構設計

如圖1 所示，CTS 系統(tǒng)集群由8 臺服務器組成，通過VCS 集群管理軟件對服務器和分布在服務器上的資源組進行管理，資源組即相同類型應用的集合。采用VCS提供的Hastatus 命令編寫Shell 腳本，定時對各資源組的運行狀態(tài)進行采集并寫入日志文件。Zabbix 通過SSH方式登錄指定服務器對運行日志進行采集和處理，再通過觸發(fā)器組件（Triger）和拓撲圖組件（Map）對日志內容進行告警和圖形化展示。各個業(yè)務運行狀態(tài)在CTS 系統(tǒng)生成，Zabbix 對業(yè)務運行狀態(tài)進行采集、過濾、展示。資源組分布情況及負載類型如表1 所示。

表1 CTS 資源組進程分布情況表（“parallel”代表并行，“failover”代表主備）Tab.1 Process distribution of the CTS resource group("parallel" represents parallel and "failover" represents active and standby)

圖1 系統(tǒng)架構設計圖Fig.1 System architecture design diagram

2 功能實現(xiàn)

為實現(xiàn)其主要功能，系統(tǒng)包括信息采集模塊、告警模塊和監(jiān)控展示模塊[3,4]三個功能模塊，數(shù)據(jù)庫依托Zabbix 監(jiān)控系統(tǒng)的MySQL 數(shù)據(jù)庫。

2.1 信息采集模塊

腳本部分基于Linux 環(huán)境下的Shell 語言編寫，主要功能是通過VCS 集群管理提供的狀態(tài)采集命令Hastatus，將CTS 集群的運行狀態(tài)打印并保存到指定的日志文件；監(jiān)控項部分基于Zabbix 系統(tǒng)采取SSH 遠程協(xié)議類型實現(xiàn)，主要功能是在服務器上獲取日志文件信息，采集腳本如下：

source /root/.bash_profile

file_dir="/root/hastatus/hastatus.log"

if [ -f "$file_dir" ]; then

rm $file_dir

fi

sleep 1

hastatus -sum >$file_dir

監(jiān)控項部分分為父監(jiān)控項和子監(jiān)控項，為了減少對CTS 的訪問，采用父監(jiān)控項采集日志文件內的全部信息，采用子監(jiān)控項在父監(jiān)控項的基礎上通過正則表達式對信息進行過濾[5]，從而獲取具體每個資源組的運行狀態(tài)信息。例如，對于AWS-PQC-grp 這個應用的運行狀態(tài)采集結果如下：

B AWS-PQC-grp begy-cts01 Y N OFFLINE

B AWS-PQC-grp begy-cts02 Y N ONLINE

則對應的兩個子監(jiān)控項的正則表達式分別為：B.*(AWS-PQC-grp).*(begy-cts01).*([A-Z]+).*([A-Z]+).*([A-Z]+)和,B.*(AWS-PQCgrp).*(begy-cts02).*([A-Z]+).*([A-Z]+).*([A-Z]+)，然后分別取出第5 個字段即表示該應用在兩個節(jié)點上是否在線。

2.2 告警模塊

告警模塊的功能是通過Zabbix 系統(tǒng)觸發(fā)器組件實現(xiàn)。觸發(fā)器內嵌有很多函數(shù)，本系統(tǒng)使用str()函數(shù)來判斷監(jiān)控項采集的信息中是否包含有OFFLINE 的字符串[6]，1 表示信息中能找到，0 表示信息中心未找到。對于并行應用（parallel），每個應用的狀態(tài)均是ONLINE 狀態(tài)則表示資源組運行正常；對于主備應用（failover），一個應用ONLINE 狀態(tài)則表示對應的資源組運行正常。對于這兩種情況對應觸發(fā)器里可以包含多個條件，根據(jù)資源組在服務器之間的負載類型，觸發(fā)器的條件由and 或者or 連接，當負載類型是并行模式（parallel）時條件由and 連接；當負載類型是主備模式（failover）時條件由or 連接，觸發(fā)器樣例如下：

parrallel 類負載觸發(fā)器

{xxzx_yxjkk_CTS05:begy-cts01-Scheduler-grp.str(ONLINE)}=0 and {xxzx_yxjkk_CTS05:begycts02-Scheduler-grp.str(ONLINE)}=0

failover 類負載觸發(fā)器

{xxzx_yxjkk_CTS05:begy-cts07-bstd-grp.str(ONLINE)}=0 or {xxzx_yxjkk_CTS05:begy-cts08-bstd-grp.str(ONLINE)}=0

2.3 監(jiān)控展示模塊

監(jiān)控展示模塊功能通過Zabbix 系統(tǒng)拓撲圖組件實現(xiàn)，通過在拓撲圖畫布上添加“元素”，將CTS2 各資源組狀態(tài)以圖形的方式進行直觀的展示，在資源組狀態(tài)異常時，觸發(fā)器就會根據(jù)負載類型來判斷是否告警，“元素”圖標也會根據(jù)觸發(fā)器的狀態(tài)而發(fā)生變化[7]。通過“元素”之間添加連線可以清楚展示各資源組之間的依賴關系，在發(fā)生故障時根據(jù)發(fā)生異常的“元素”和“連線”可以快速、準確地定位故障發(fā)生的資源組及依賴的資源組，提升了運維效率，從而保障了數(shù)據(jù)服務能力[3]，資源組依賴情況如圖2 所示。

圖2 資源組依賴圖Fig.2 Resource group dependency diagram

3 結語

本文依托開源架構的監(jiān)控系統(tǒng)Zabbix[8]，針對集群的管理軟件VCS 不能提供告警的業(yè)務難點展開研究，通過梳理VCS 集群管理軟件上的資源組情況，將資源組之間的依賴關系以及資源組在服務器之間的負載類型考慮進來，實現(xiàn)了CTS 資源組狀態(tài)層面的集約化監(jiān)控，提升了監(jiān)控的精細性和準確性，提高了核心業(yè)務系統(tǒng)CTS 的運維能力，符合氣象信息化發(fā)展的需求。