基于Zabbix的省級氣象云監控運維系統①

楊立苑,胡佳軍,鄧衛華,劉喆玥

(江西省氣象信息中心,南昌 330096)

運動隨著近幾年來云計算技術的飛速蓬勃發展,云計算技術已經發展成熟[1],云基礎設施也融入到各行各業當中,例如政府服務部門的政務云[2,3]、教育服務行業的教育云[4,5]、公共衛生事業的醫療云[6,7]等.為了實現氣象部門信息化、現代化的快速發展,集約化管理氣象信息基礎設施和業務應用,江西省氣象部門已經建設了省級氣象云平臺.但是因為氣象云的物理設備數量和業務應用數量的迅速增加,傳統的集群監視技術已經無法滿足當下氣象云監控運維的需要[8].傳統的集群監視技術只能對物理服務器的資源利用情況進行簡單的監視,一方面無法對氣象云的虛擬機實例和運行在氣象云上的云應用進行監視,另一方面無法對監視到的故障問題進行報警及自動應急處理.

江西省氣象云主要分為物理基礎設施層、虛擬化層、氣象應用層.物理基礎設施層主要包括物理服務器、路由器、交換機等等,其中物理服務器經常出現硬盤損壞、CPU 負載過高等問題.虛擬化層主要是基于KVM 虛擬化技術生成的虛擬機實例,虛擬機經常出現假死無響應、存儲空間不夠等問題.氣象云應用層主要運行的是氣象服務應用,例如氣象數據傳輸存儲類應用、氣象數據統計分析類應用、氣象公眾Web服務類應用,這些云應用經常會出現突然中斷退出、性能變低等問題.

為了建立面向氣象云的監控運維系統,實現對氣象云的三層監控,及時對發生的故障和問題進行通知和自動處理,減輕值班運維人員的日常維護負擔,本文基于Zabbix 開源系統設計了一種氣象云監控運維系統(Meteorological Cloud Monitoring and Maintenance System,MCMMS).

1 相關工作

Cacti是一種網絡流量監視圖形分析開源工具,它是基于PHP、MySQL、RRDTool 等開發的[9].它通過SNMP的snmpget 命令和snmpwalk 命令去遠程獲取網絡設備相關信息,然后基于RRDTool 工具繪制監視設備的性能狀態圖.Cacti 具備精準的流量監視能力,但不支持分布式集群監控,缺乏報警功能,不適應目前云環境下的監控需求.

Nagios是一種監視系統運行和網絡設備信息的開源監視系統[10,11].它能夠有效監視各類操作系統的狀態以及路由器、交換機等網絡設備的狀態.當監視對象出現異常時,它能夠以郵件和短信的方式發出警報.雖然它告警功能強大,但是它的數據收集機制不強,在當下云環境虛擬機眾多的情況下,添加配置監視對象也很繁瑣,不宜進行維護.

Ganglia是一種可擴展的分布式監控系統,它是主要為高性能計算集群設計的[12,13].它可以監視高性能計算集群各個節點的狀態信息,通過gmond 代理采集各項性能指標,通過gmetad 進程進行監視數據的匯總,最后通過PHP 展示機器的性能數據.但是這個系統對應用的監視比較薄弱.

Zabbix為分布式系統和網絡監視功能提供了一種基于Web 應用的企業級開源解決方案[14,15].Zabbix的監控方式如圖1所示,Zabbix 可以通過代理、JMX、SNMP 等多種方式對服務器和網絡進行監控數據收集,能夠支持包括Linux、Windows 在內的各種系統平臺.Zabbix 既解決了Cacti 沒有報警的不足,也解決了Nagios 配置繁瑣的問題.Zabbix 另外的一個優點在于能夠允許用戶對監視功能進行自定義擴展.

圖1 Zabbix的監控方式

2 系統的體系結構

江西省氣象云主要分為物理基礎設施層、虛擬化層、氣象應用層[16].物理基礎設施層主要包括物理服務器和網絡設備.虛擬化層主要包括運行在物理基礎設施層上的各類虛擬機.氣象云Hypervisor是運行在物理基礎設施層和虛擬化層之間的軟件,它可以對物理基礎設施進行硬件資源抽象,然后為虛擬化層供給共享的計算、存儲、網絡等資源.用戶可以通過Hypervisor對虛擬化層進行一定程度的性能監視以及對虛擬機進行生命周期管理.氣象應用運行在虛擬機的操作系統上,為用戶提供氣象信息技術服務.

基于Zabbix的氣象云監控運維系統體系結構如圖2所示,主要分為氣象云監控代理和氣象云監控運維Web 系統兩部分.

圖2 氣象云監控運維系統體系結構

氣象云監控運維系統需要在物理服務器和虛擬機中部署監控代理.部署在物理服務器中的監控代理主要是監視物理服務器以及運行在其上所有虛擬機的CPU資源、內存資源、網絡資源、硬盤資源的實時使用情況.部署在虛擬機中的監控代理主要監視運行在虛擬機上氣象應用的運行情況.這些部署在氣象云上的監控代理會將監視數據通過網絡發送給氣象云監控運維系統.另外,這些監控代理還會接收來自監控運維系統的操作指令,自動對氣象云進行應急運維操作.

氣象云監控運維Web 系統自下而上主要分為4 層,分別是業務數據庫層、數據訪問層、業務邏輯層、展示層.

業務邏輯層使用的是MySQL 數據庫,數據庫中存儲著各種資源歷史使用情況、設備實例的詳細信息、監視規則、觸發報警規則、報警事件等.

數據訪問層采用的是ORM 框架,它向上為業務邏輯層提供了數據庫的訪問接口,向下使用面向對象的形式對數據庫中的表進行了映射操作.

業務邏輯層是氣象云監控運維系統的核心部分,它分為兩大部分,一部分是繼承原有的Zabbix 監視業務邏輯,另一部分是在Zabbix 數據庫基礎上對Zabbix進行了可視化以及報警、應急操作的擴展.繼承原有的監視業務邏輯主要包括數據收集模塊、主動監視模塊、數據處理模塊,擴展的業務邏輯主要包括可視化模塊、報警模塊、應急操作模塊.數據收集模塊的作用是接收從氣象云監控代理發送過來的數據,主動監視模塊的作用是監控運維系統通過一些常用協議去主動監視Java 應用、網絡設備、硬件設備,數據處理模塊主要是對監視數據進行處理、讀取.報警模塊的作用是根據報警觸發規則為用戶推送告警信息,應急操作模塊的作用是對運維過程中出現的問題進行及時的簡單處理,可視化模塊是將監控的相關信息展示到前臺頁面.業務服務視圖負責對前臺的模型及頁面進行渲染.

展示層需要為PC Web 桌面和智能手機(iOS、Android)提供信息展示功能.值班人員的PC Web 桌面是基于HTML5 開發,采用了BootStrap4、Jquery 等技術,為用戶提供了監控報警信息的頁面展示以及和監控有關的配置頁面.面向智能手機的展示層主要是用于接收瀏覽報警信息,報警信息會根據重要等級分別通過值班平臺、短信平臺、微信平臺推送給值班運維人員.

3 關鍵技術

3.1 Agent 監視方法

本系統采用在操作系統中部署監視代理(Agent)的方式對氣象云的物理服務器、虛擬機、關鍵應用進行監視,Agent 在獲取到監視信息后,會將這些信息發送給MCMMS Server.Agent 按照與MCMMS Server交互方式分為主動類型和被動類型.

主動類型的Agent與MCMMS Server 交互的流程如圖3所示.主動類型的Agent與MCMMS Server 交互分為準備期和運行期這兩個階段.首先Agent 發出與MCMMS Server 建立TCP 連接的請求,建立與MCMMS Server的TCP 通信通道.然后Agent 會向MCMMS Server 發送請求監視項目表的申請,Zabbix 會根據請求返回相應Agent 所需監視項目表.Agent 在獲取到自己的監視項目表后會對返回的監視項目表進行處理,處理完畢后斷開TCP 連接.接下來,Agent 進入運行期,首先會建立與MCMMS Server 發送監視信息的TCP連接通道,然后會根據配置文件中預定義的時間間隔發送監視信息給MCMMS Server.MCMMS Server 在收到監視信息后會對監視信息進行處理,并且存入到數據庫中.

圖3 主動類型Agent 交互流程

被動類型的Agent與MCMMS Server 交互的流程如圖4所示.對于被動類型的Agent,MCMMS Server 首先會發出與Agent 建立TCP 連接的請求,獲取與Agent 數據傳輸通信的通道.然后MCMMS Server 會向Agent 發送相關數據請求,該數據請求主要是需要監視項目的名字.Agent 在收到MCMMS Server發來的數據請求后,會讀取相應的監視數據,然后將獲取的監視信息返回給MCMMS Server.MCMMS Server收到返回的監視信息后會進行數據處理,然后存儲到數據庫中,最后斷開TCP 連接.

圖4 被動類型Agent 交互流程

兩種類型的Agent 都會按照設計約定的數據傳輸協議與MCMMS Server 進行通信,該數據協議采用JSON 數據格式,但是會在每條數據之前加上頭部標識符和數據長度標識符,格式順序如下所示:＜頭部標識＞＜數據長度標識＞＜監視數據＞.頭部標識一共是5 個字節,數據長度標識一共是8 個字節,每一條數據量大小不能超過64 M,這是為了防止內存消耗過快.

3.2 面向基礎云資源的監視

江西省氣象云虛擬化資源是基于libvirt 進行監視的,libvirt是一款用于虛擬化平臺管理的開源API 庫.libvirt 提供了針對不同虛擬化平臺的監視功能,對于不同的虛擬化平臺都提供了該平臺的驅動,并且為不同語言提供了統一的編程接口,通過調用接口可以實現對氣象云的虛擬化操作.對基礎云資源的監視主要包括對計算資源的監視、對存儲資源的監視、對網絡資源的監視.

對于計算資源的監視就是對物理服務器和虛擬機的CPU 利用率進行監視.開源庫libvirt 雖然沒有提供接口讓外部系統直接獲取CPU 利用率,但是外部系統可以通過計算CPU Time 間接獲取CPU 利用率,CPU利用率獲取算法如算法1 所示.

算法1.CPU 利用率獲取算法輸入:虛擬機實例集instanceList輸出:虛擬機使用率集合cpuMapList 1.for instancein instanceList:2.get time1,time2 from system time 3.get CPUTime1,CPUTime2,cores_nums,uuidfrom Qemu 4.//計算CPU 時鐘差5.ΔCPUTime=CPUTime2 - CPUTime1 6.//計算自然時間差7.Δtime=time2 - time1 8.//計算CPU 使用率9.CPU_usage=ΔCPUTime×100/(Δtime×cores_nums×109)10.cpuMapList ← map＜uuid,Cpu_usage＞11.return cpuMapList

對存儲資源的監視就是對物理服務器和虛擬機的內存資源和硬盤資源進行監視.內存資源的使用情況獲取比較簡單,只需要獲取宿主機上每個實例的Domain基礎信息,然后從基礎信息中提取與該實例相關的最大內存大小和已使用內存大小.硬盤資源的總量和使用量首先需要通過libvirt 接口獲取Domain的情況及XML 配置文件,然后通過XML 可以獲取每個機器的名稱,最后再通過Domain的設備塊信息接口blockinfo獲取需要監測的數值.另外,獲取硬盤的I/O 情況與獲取硬盤的使用量過程類似,但是在調用接口獲取設備信息時需要調用設備快查詢接口blockstats 獲取需要監測的數值.

對于網絡資源的監視就是對虛擬機的虛擬網卡數據流入流出量進行監視.首先需要使用libvirt的API獲取Domain的情況,然后將虛擬網卡設備的名稱作為參數傳遞給libvirt的API,通過interfaceStats 接口去獲取虛擬網卡設備的屬性字段值,這些值便是虛擬網卡流入流出的數據量.對于網絡設備如路由器和交換機的監視,需要使用SNMP 功能進行監視.使用SNMP首先需要使用snmpwalk 命令對對象標識符(OID)值進行遍歷,然后再根據具體的OID 值使用snmpget 命令獲取該設備的網口狀態和流量.

3.3 面向關鍵云應用的監視

對于運行在氣象云上的云應用主要監視常用的基礎軟件MySQL 數據庫和Tomcat Web 容器的性能以及C/S 架構和B/S 架構的應用軟件.

MySQL 數據庫是目前主流的關系型數據庫管理系統應用軟件.本系統將使用被動類型Agent 模式對Zabbix的監視進行擴展.Agent 將會對MySQl的存活狀態、更新類SQL 執行個數、查詢類SQL 執行個數、插入類SQL 執行個數、刪除類SQL 執行個數、慢查詢語句個數進行監視.首先需要在Agent的配置文件中進行自定義監視命令的配置.自定義的監視命令需要遵循Zabbix的規范,按照UserParameter=key,command的形式進行定義,這里監視命令基于MySQL自帶的mysqladmin 命令進行編寫.

由于Tomcat Web 應用容器是基于JAVA 語言開發的,所以MCMMS Server 可以通過JMX對Tomcat的性能進行監視.JMX是Java 管理的擴展,給應用程序提供了監控管理功能的接口.使用JMX 不需要在Tomcat 代碼中增加新的機制和代碼,只需要在啟動Tomcat 服務器前修改相關的配置文件開啟支持JMX接口的服務端口即可.通過JMX 監視用戶便可以監視到Tomcat 服務占用CPU的情況、并發線程數量、內存分配情況等.修改配置文件可以開啟JMX 支持.

對于用戶部署在氣象云上的應用,系統無法入侵式的監視應用程序應用情況,只能通過監視應用的日志達到監視應用運行狀態的目的.監視應用日志的Agent 工作流程如圖5所示.Agent 會定時掃描應用的日志目錄,對該日志目錄下的日志文件進行文件名正則表達式匹配,當匹配到文件名相符的日志文件,Agent 會去數據庫中讀取該日志文件的字節計數器和更新時間計數器.如果日志文件的大小小于字節計數器,那么Agent 將會從日志頭部開始讀取日志文件,計數器也會重置為0.如果日志文件大小大于字節計數器,那么Agent 將會從最新的位置開始讀取文件.Agent 逐行讀取文件時,會按照自定義的應用錯誤關鍵字檢查日志文件內容,如果發現應用錯誤信息,Agent會將該信息發送給MCMMS Server.Agent 每次結束一個日志文件檢查時,會將數據庫中該日志文件的計數器更新.另外,對B/S 架構的Web應用軟件,MCMMS Server 可以對自定義的Web 網頁URL 進行定時掃描,收集訪問該網頁的下載速度、響應時間以及返回的HTTP 網頁狀態碼.如果發現響應時間超時或者返回的狀態碼是404 等錯誤碼,那么將會觸發對該Web 應用的告警.

圖5 Agent 監視應用日志文件流程

3.4 報警運維技術

在收集的監視數據基礎上,系統會對監視數據進行處理,為值班人員提供報警功能和故障自動化處理功能.報警控制流程如圖所示.報警運維主要分為兩個模塊:觸發器和應急操作.

觸發器是當監視數據不滿足自定義的約束條件時,會發出觸發某個操作的指令.每一臺物理設備實例或者虛擬機實例都對應多條觸發器.每個觸發器都會定義一個邏輯表達式,該邏輯表達式是監事數據的約束條件.邏輯表達式按照約定的格式進行定義,約定的基本格式如下.{＜實例名＞:＜監視項＞.＜函數＞(＜參數＞)}＜邏輯運算符＞＜約束量＞,其中實例名是監視系統中物理設備或者虛擬機的名字,監視項是所需要監視項目的名稱,包含參數的函數是用來返回該函數指定的監視項數據,邏輯運算符是用來判斷監視數據是否滿足約束量.表達式中的函數一共有5 種,分別是avg、count、last、min、max,具體的作用如表1所示.觸發器的表達式由滿足約束到不滿足約束或者由不滿足約束到滿足約束,觸發器的狀態會由正常變為異常或者由異常變為正常,每次觸發器狀態的變化都會生成一個事件.事件按照問題的重要性會分成5 個等級,等級從輕到重分別是提示(Information)、警告(Warning)、一般(Average)、重要(High)、災難性(Disaster).

表1 各函數的作用

當觸發器的約束條件不被滿足后,系統會針對該觸發器采取應急操作.應急操作主要包括兩個部分,一是將產生的報警信息告知值班人員以及系統運維人員,二是對產生的問題執行相應的應急指令.發送報警提示的方法主要包括發出警報聲音、短信通知、微信通知、郵件通知.對于一線24 小時值班人員,一般采用直接發出警報聲音的方式進行通知.對于二線運維人員,由于不在值班室,會采用短信通知和微信通知兩種方式,短信通知主要通知重要和災難性的問題,微信通知主要通知一般性及以下的問題.對于產生的問題執行相應的應急指令主要是指通過遠程SSH和IPMI 連接到問題設備實例上,執行一定的系統恢復命令.在運維過程中,常見的需要恢復場景如表2所示.

表2 常見應急恢復場景

4 實驗測試

4.1 系統平臺部署

系統的平臺部署環境如圖6所示,一臺服務器部署了MySQL 監控數據庫,一臺服務器部署了Zabbix服務器,擴展Zabbix 功能的Web 應用部署在另外一臺服務器上.用戶可以通過Web 桌面訪問Zabbix 服務應用和擴展服務應用.值班運維人員的智能手機會從擴展應用服務上獲得監控運維信息.

圖6 系統的平臺部署環境

4.2 系統平臺展示

圖7是對監控告警信息的總覽,圖7上部分是各類告警個數的統計和當天值班人員的信息.圖7下部分是滾動的詳細告警信息和產生告警信息來源的區域告警.圖8和圖9是按照服務器以及虛擬機在實際環境中的機柜、網段分布信息繪制的告警分布圖,對于不同的告警信息系會用不同的顏色進行標注.圖10是監控運維系統通過短信平臺和微信平臺推送到智能手機上的監控告警信息.

圖7 監控告警信息總覽

圖8 服務器監控告警分布圖

圖9 虛擬機監控告警分布圖

圖10 智能手機接收監控告警信息

5 結束語

本文基于Zabbix 設計了一套面向氣象云的監控運維系統,為氣象云環境中的物理基礎設施、虛擬機以及運行在其上的云應用進行了實時監控.如果在氣象云中出現了故障,該系統能夠快速發現問題,通知值班運維人員,并且會根據預定義命令自動進行先行維護.這保障了氣象云的平穩運行,減輕了值班運維人員的工作量.目前系統對云應用的監控種類少、粒度粗,下一步將會研究擴展云應用監控的種類以及優化云應用監控的方法.