基于Zabbix的分布式數(shù)字化監(jiān)控系統(tǒng)設計與實現(xiàn)

于 濱 劉鵬宇 陸麗麗 孫玉強 崔建偉

中國聯(lián)通濟南軟件研究院 濟南 250100

背景

隨著企業(yè)服務器和應用服務數(shù)量的不斷增加，運營管理人員面對越來越多的應用，除了監(jiān)控服務器自身節(jié)點是否正常運轉外， 還需監(jiān)控服務器上運行的Web、數(shù)據(jù)庫、DNS等應用服務是否正常運行。傳統(tǒng)運維方式中，運維人員疲于處理各種故障、效率低下，即使加班加點地調試、部署、維護，也經(jīng)常因設備故障而導致業(yè)務中斷，嚴重影響業(yè)務的正常運轉；因此，部署一套高效可靠的監(jiān)控系統(tǒng)，實時監(jiān)控服務器與應用服務的運行狀態(tài)，提供便捷、及時的通知機制讓運維人員快速定位并解決故障尤為重要。

Zabbix作為一款企業(yè)級開源網(wǎng)絡監(jiān)控項目，提供分布式系統(tǒng)監(jiān)控及網(wǎng)絡監(jiān)控功能，其高度集成的解決方案目前已廣泛應用于各行各業(yè)[1]。Zabbix具有node和proxy兩種分布式部署方式，能夠監(jiān)控幾乎所有類型的設備，提供完善API接口，能夠實現(xiàn)與其他運維管理系統(tǒng)的完美對接，其提供對外開放接口，支持自定義告警，方便及時有效地發(fā)布通知，這對于構建分布式監(jiān)控系統(tǒng)具有重要作用[2]?；赯abbix與Web應用和微信、APP等移動端應用結合，可以建設一套能夠及時告警、快速定位、減輕運維人員繁重工作的監(jiān)控系統(tǒng)。

1 系統(tǒng)整體架構

該系統(tǒng)由Zabbix與監(jiān)控應用兩部分組成。Zabbix完成對服務器和應用服務的監(jiān)控，應用則對Zabbix所監(jiān)控的項目進行展示和告警機制的處理。

Zabbix會定時獲取服務器和應用服務的監(jiān)控信息，并將數(shù)據(jù)存入數(shù)據(jù)庫，此部分為應用端監(jiān)控展示信息的數(shù)據(jù)來源。

Zabbix可通過配置觸發(fā)器，在被監(jiān)控的服務器和應用服務監(jiān)控到達某個自定義閾值時觸發(fā)觸發(fā)器，執(zhí)行相應動作。Zabbix提供了高擴展性的觸發(fā)器及動作執(zhí)行方式，便于進行自定義監(jiān)控進而得到理想結果。Zabbix自身提供郵件通知告警方式，但由于郵件接收具有延時并容易被被通知人員忽略，因此該系統(tǒng)建立了微信和移動APP告警推送的機制，以保證運維人員可及時接受告警信息(如圖1)。

圖1 整體架構

1.1 Zabbix架構

Zabbix主要由Zabbix Server、Proxy、Agent、Web前端及Database等部分組成(如圖2)。

圖2 Zabbix架構圖

Server為Zabbix核心組件，主要負責接收Agent發(fā)送的信息數(shù)據(jù)，管理系統(tǒng)配置信息和歷史數(shù)據(jù)。Proxy為代理服務器，可視為Server的擴展部分，可代替Server收集監(jiān)控設備上的數(shù)據(jù)并轉發(fā)給Server，主要適用于分布式環(huán)境中[3]。Agent部署在被監(jiān)控設備上，主要負責收集監(jiān)控數(shù)據(jù)并發(fā)送至Server或Proxy。Web前端方便運維管理人員對Zabbix進行配置及查看監(jiān)控設備的狀態(tài)，通常與Server部署在同一臺服務器中。Database負責存儲收集的監(jiān)控數(shù)據(jù)及Zabbix配置信息等。

1.2 Zabbix配置管理

Zabbix配置管理在Zabbix攜帶的web前端中進行，主要包括以下3個步驟。

步驟一：在需要監(jiān)控的主機中，創(chuàng)建監(jiān)控項Item，監(jiān)控指定的數(shù)據(jù)。

步驟二：創(chuàng)建觸發(fā)器Trigger，將創(chuàng)建好的監(jiān)控項添加進觸發(fā)器，并設置觸發(fā)條件。

步驟三：創(chuàng)建動作Action，將觸發(fā)器和用戶關聯(lián)起來，當觸發(fā)器被觸發(fā)時，執(zhí)行相應動作(如圖3)。

圖3 Zabbix配置流程圖

其中，主機即被監(jiān)控的設備，監(jiān)控項來源于被監(jiān)控的主機，是監(jiān)控數(shù)據(jù)收集的核心。觸發(fā)器可以看作是一個控制中心，觸發(fā)器會設定一個條件，當監(jiān)控項中接收到的監(jiān)控數(shù)據(jù)達到觸發(fā)器設定的條件時，觸發(fā)器便會執(zhí)行相應的動作。本文設計的分布式數(shù)字化監(jiān)控系統(tǒng)在觸發(fā)器被觸發(fā)后調用服務層接口，執(zhí)行相應的消息處理流程，將處理后的消息推送至微信和移動APP中，及時通知相關人員，幫助其快速定位并解決問題。Zabbix作為分布式監(jiān)控系統(tǒng)，其優(yōu)勢之一在于提供了自動發(fā)現(xiàn)功能，可自動發(fā)現(xiàn)并添加主機，這對于大規(guī)模的網(wǎng)絡管理十分有效。同時Zabbix提供了模板功能，主要將一些共性的監(jiān)控項如主機CPU、內存、磁盤等抽取出來，在添加監(jiān)控項時只需添加模板即可將模板中的監(jiān)控項全部納入系統(tǒng)管理中，避免了重復性工作，提高工作效率。

2 基于Zabbix的分布式數(shù)字化監(jiān)控系統(tǒng)應用

2.1 實時監(jiān)控

報警信息推送的時效性將直接影響運維質量，實際工作中，運維人員無需時刻緊盯系統(tǒng)的運行情況，一切事件信息均通過微信、移動APP獲取。Zabbix收集監(jiān)控數(shù)據(jù)存儲至數(shù)據(jù)庫，該數(shù)據(jù)庫作用于應用監(jiān)控展示，通過對這些監(jiān)控數(shù)據(jù)進行處理，可對監(jiān)控信息進行個性化展示，滿足企業(yè)的個性化需求。

Zabbix Server可通過Zabbix Agent、SNMP、ping、IPMI等方法對遠程服務器及網(wǎng)絡設備進行狀態(tài)監(jiān)控和數(shù)據(jù)采集。通過B/S模式在Web端進行系統(tǒng)配置和信息呈現(xiàn)。在Zabbix系統(tǒng)中將監(jiān)控主機抽象為主機，系統(tǒng)采集服務器的信息抽象為監(jiān)控項，通過設置觸發(fā)器監(jiān)測監(jiān)控項的返回值，當滿足觸發(fā)條件便執(zhí)行相應動作。Zabbix可設置的動作包括執(zhí)行腳本程序、發(fā)送報警信息和執(zhí)行命令，整個過程為毫秒級，能夠很好地實現(xiàn)實時監(jiān)控。

針對不同監(jiān)控目標端又可分為對主機性能監(jiān)控、對Web服務監(jiān)控、對中間件監(jiān)控等不同監(jiān)控應用。

對主機性能監(jiān)控：Zabbix Server有多種監(jiān)控主機性能模板，用戶可根據(jù)自身需要選擇適當模板，對Cent OS系統(tǒng)性能監(jiān)控，可包括磁盤、CPU、內存、流入流量、流出流量、丟包率等多項主機性能(如圖4)。

圖4 zabbix主機資源監(jiān)控

對Web服務監(jiān)控：采用net.tcp.listen[8080]監(jiān)控服務器8080端口是否在監(jiān)聽狀態(tài)，返回值為0表示8080端口沒有處于監(jiān)聽狀態(tài)，返回值為1表示8080端口處于監(jiān)聽狀態(tài)；另外可通過net.tcp.port[IP，8080]檢測是否對服務器8080端口進行TCP連接，通過該命令可驗證服務器的連通性，返回值為0表示8080端口無法進行TCP連接，返回值為1表示8080端口可進行TCP連接(如圖5)。

圖5 WEB服務端口及進程監(jiān)控

對中間件監(jiān)控：隨著分布式服務不斷擴增，對中間件的監(jiān)控刻不容緩。Zabbix自定義監(jiān)控項便很好地滿足個性化監(jiān)控需求。通過對Zabbix Server配置文件UserParameter修改，以添加自定義監(jiān)控項。如：UserParameter=cio.str[＊]，/opt/Zabbix/script/cipan_io.sh'$1'；通過配置自定義監(jiān)控項時將鍵值設置為cio.str[＊]，在監(jiān)控項獲取數(shù)據(jù)時，將執(zhí)行其對應/opt/Zabbix/script/cipan_io.sh腳本，'$1'則為執(zhí)行該腳本時傳遞的參數(shù)。

在zabbix基礎監(jiān)控的基礎上建立的對應用中間件的監(jiān)控效果如圖6所示。

2.2 消息處理

圖6 應用中間件監(jiān)控信息

即使是再強大的監(jiān)控系統(tǒng)，也不乏有誤告發(fā)生。為降低Zabbix系統(tǒng)壓力，Zabbix系統(tǒng)配置自定義監(jiān)控項均采用異步處理方式，即agent每分鐘獲取一次自定義監(jiān)控項的結果并存放于日志文件中，而Zabbix僅需定時獲取日志即可，無需進行復雜的邏輯處理，大大提高了Zabbix系統(tǒng)性能，但其缺點為，異步數(shù)據(jù)處理容易導致數(shù)據(jù)延時。因此，對Zabbix的告警消息進行二次處理是十分必要的，能夠極大地降低誤告頻率。

另外Zabbix告警內容存在局限性，例如某個分布式服務中某節(jié)點掛掉，無法獲取具體節(jié)點；某臺機器CPU負載過高，無法獲取該機器部署了哪些應用；消息隊列中消息積壓超過閾值，卻無法獲取具體哪個Topic積壓數(shù)量過多；消息隊列中出現(xiàn)離線消費者，卻無法獲知該離線消費者所對應的Topic等；因此需要對告警消息進行二次處理。

當監(jiān)控項監(jiān)控數(shù)據(jù)達到閾值同時觸發(fā)觸發(fā)器發(fā)起動作時，告警消息將發(fā)送至消息處理接口，將告警消息進行過濾、加工、處理為更加準確易讀的消息，便于運維人員更快定位問題(如圖7)。

圖7 zabbix觸發(fā)動作執(zhí)行腳本

觸發(fā)動作采用腳本形式，通過調用zabbix-server機器中的shell腳本，調用消息處理的JAVA程序，對消息進行過濾處理。下面將要介紹的告警模塊，告警內容均是經(jīng)過處理的，獲取主機部署的應用，虛擬機的宿主機等信息均是通過消息處理過程獲取。

2.3 告警

監(jiān)控消息處理后，垃圾消息已經(jīng)被過濾，一些可讀性不高的消息在被處理之后獲得良好的可讀性，因此需要一個良好的通知機制將這些消息推送給相關人員。Zabbix默認支持郵件告警功能，但郵件接收不及時甚至容易被忽視[4]。手機作為人們日常生活中必不可少的工具，適合作為告警消息的接收端，便于運維人員及時收到告警消息，快速定位故障處理問題。在大規(guī)模告警消息產(chǎn)生時，通過調用短信網(wǎng)關實現(xiàn)短信告警方式，對于消息接收者來說是一個很不友好的體驗，同時會帶來相應的費用，經(jīng)過多方面考慮，最終我們選擇使用微信和移動APP來作為告警消息的接收端。

微信在注冊后通過配置相應參數(shù)搭建服務，可為企業(yè)不同項目創(chuàng)建不同應用，每一應用對應唯一標識agentId，在調用微信消息推送接口時，只需在參數(shù)中添加相應agentId，便可將告警消息推送至相應項目中，該項目負責人員便會即時接收到告警消息(如圖8)。

圖8 微信推送流程圖

移動APP的消息推送機制通過IOS和Android各自推送服務器實現(xiàn)，用戶在安裝APP后，APP會向各自推送服務器注冊相應的設備信息，當消息經(jīng)過處理流程到達APP推送部分時，這些處理后的消息會被推送至IOS和Android推送服務器上，推送服務器會查看當前服務器注冊的設備信息，并將該消息發(fā)送至相應設備(如圖9)。

圖9 APP推送流程圖

因服務器負載過高推送的經(jīng)過消息處理后的APP和微信告警如圖10所示。

圖10 經(jīng)過消息處理后APP和微信推送的告警信息

2.4 信息統(tǒng)計

預測分析是一種統(tǒng)計或數(shù)據(jù)挖掘解決方案，通過對歷史數(shù)據(jù)進行計算，以確定未來結果的算法和技術[5]。該方法可用于預測、優(yōu)化、預報、模擬等。在本文的監(jiān)控系統(tǒng)中，基于歷史數(shù)據(jù)進行預測分析，可判斷何時會發(fā)生系統(tǒng)故障，例如基于1小時歷史數(shù)據(jù)，分析未來3小時系統(tǒng)狀態(tài)。

Zabbix的監(jiān)控告警，僅能在出現(xiàn)問題后通知運行維護人員，雖然Zabbix3.0已支持預警功能，但仍存在有局限性，無法較好地滿足當前個性化的需求，因此本監(jiān)控系統(tǒng)中對Zabbix監(jiān)控的歷史數(shù)據(jù)進行統(tǒng)計分析，以提前預知問題[6]。

通常在監(jiān)控系統(tǒng)中有兩個主要關注點，一是歷史數(shù)據(jù)的存儲與展示，二是定義報警策略并及時發(fā)現(xiàn)問題。為能更加細致、精確地分析數(shù)據(jù)，在監(jiān)控系統(tǒng)中，將監(jiān)控數(shù)據(jù)采集進行細粒度存儲[7]。

Zabbix系統(tǒng)每分鐘獲取一次監(jiān)控數(shù)據(jù)，若系統(tǒng)監(jiān)控大批量主機，這些機器的監(jiān)控數(shù)據(jù)存儲代價和查詢繪圖代價較高。因此，本監(jiān)控系統(tǒng)中，每日凌晨1點，定時獲取Zabbix前一天的監(jiān)控歷史數(shù)據(jù)，每臺機器獲取Top5并取平均值，本監(jiān)控系統(tǒng)Web界面展示Zabbix報表，直觀地展示某臺機器某段時間CPU、內存、磁盤、流入流量、流出流量等基本性能?？筛鶕?jù)所繪趨勢圖預測機器未來一段時間的性能及資源使用情況。

隨著分布式系統(tǒng)的廣泛應用，使用的機器越來越多，如何對這些機器進行合理的資源分配也是當前運維人員需要考慮的問題[8]。通過對Zabbix監(jiān)控數(shù)據(jù)存儲，將數(shù)據(jù)進行篩選、處理、聚合后，展示每一臺機器的CPU、內存、磁盤等使用情況，可直觀展現(xiàn)每臺機器的資源使用情況，以便采取相應措施，提高資源利用率。

對主機資源信息監(jiān)控如圖11所示。告警信息統(tǒng)計結果如圖12所示。

2.5 權限管理

通過增加權限的管理，系統(tǒng)可以有效地控制不同人員查看不同項目的監(jiān)控和告警內容，保證了數(shù)據(jù)的安全性。

圖11 主機資源監(jiān)控信息統(tǒng)計

圖12 告警信息統(tǒng)計分析結果

Web和APP使用服務端的權限管理模塊，該模塊下，不同角色對應不同權限，在Web應用下，通過對不同用戶賬號配置不同角色，賦予這些用戶不同權限。用戶在登陸Web后，只能查看其權限范圍內的監(jiān)控信息，權限范圍外的信息對該用戶屏蔽。APP與Web相同，對于監(jiān)控信息只有權限范圍內的信息才可以查看，同時APP上推送的告警消息，用戶也只能接收到其權限范圍內項目的告警消息。

微信提供了一種權限管理方式，在微信中為不同項目創(chuàng)建不同應用，可在不同應用中添加不同人員，只有用戶是該應用下的成員時，才能接收到相應的推送消息。

3 總結

通過Zabbix優(yōu)秀的監(jiān)控能力，與自建應用系統(tǒng)相結合，開發(fā)出一套滿足企業(yè)個性化需求的分布式數(shù)字化監(jiān)控系統(tǒng)。通過其內置的模板功能，可對服務器主機的CPU、內存等共性指標快速監(jiān)控，大大提高配置效率，另外通過自定義監(jiān)控項的配置，極大滿足了企業(yè)的個性化需求，保證監(jiān)控內容的全方位覆蓋，通過Zabbix對不同監(jiān)控項配置不同觸發(fā)策略，并結合移動端應用的搭建，使運維人員可以實時獲取監(jiān)控消息和經(jīng)過過濾、分類并結構化處理后的告警信息，幫助運維人員快速定位故障，解決問題，提高工作效率，保證企業(yè)應用的穩(wěn)定性。

[1] 毛承國,張衛(wèi)華,張進鐸,等.大規(guī)模集群運維自動化的探索與實踐[J].信息安全與技術,2014,5(2): 60-63

[2] 鐘志勇.微信公眾平臺應用開發(fā)實戰(zhàn)[M].北京:機械工業(yè)出版社,2013

[3] 郭曉慧,李潤知,張茜,等.基于Zabbix的分布式服務器監(jiān)控應用研究[J].通信學報,2013,34(Z2):94-98

[4] 劉遠超,李樹彬.基于Zabbix和微信企業(yè)號實現(xiàn)網(wǎng)絡監(jiān)控的研究[J],山東科學,2017,30(4):124-130

[5] 車路,張煥遠,夏亞東.基于開源軟件的云監(jiān)控平臺設計與實現(xiàn)[J].計算機技術與自動化,2015,34(1):136-140

[6] 龍煒.自動化運維工具在企業(yè)信息系統(tǒng)管理中的應用[J].微型機與應用,2017,36(5):102-104

[7] 肖海琴.Zabbix性能監(jiān)控軟件在高性能集群上的應用[J].中國管理信息化,2017,20(3):139

[8] 李磊.IT自動化運維平臺建設和應用[J].信息技術與標準化,2016,1(10):59-61