基于Zabbix的企業(yè)級監(jiān)控系統(tǒng)建設(shè)探索與應(yīng)用

秦國華，李 良

（廣西廣電新媒體有限公司，廣西 南寧 530029）

0 引言

廣西廣電新媒體自2013年以來陸續(xù)建設(shè)和整合了IPTV集成播控、廣西視聽、IPTV看吧、臺網(wǎng)站、大數(shù)據(jù)、媒資源站等業(yè)務(wù)系統(tǒng)。這些業(yè)務(wù)系統(tǒng)的穩(wěn)定運行關(guān)系到廣西IPTV、廣西視聽和廣西網(wǎng)絡(luò)廣播電視的視頻內(nèi)容運營和終端用戶體驗。為了對各個系統(tǒng)的可用性和穩(wěn)定性進行量化，公司技術(shù)部在2017年年底通過管理層研討，并參照業(yè)界通用的SLA（Service Level Agreement，服務(wù)等級協(xié)議），定義了各個業(yè)務(wù)系統(tǒng)的故障等級和月度/年度考核規(guī)則。按照該考核規(guī)則，公司各業(yè)務(wù)系統(tǒng)年度可用率將逐漸從99%提升到99.99%。

這些考核管理辦法的逐步落地，使我們意識到對這些系統(tǒng)運行狀態(tài)進行實時監(jiān)控和及時預(yù)警的重要性。

1 監(jiān)控系統(tǒng)建設(shè)和維護過程中的問題

隨著Zabbix監(jiān)控系統(tǒng)的建設(shè)和使用，在給大家?guī)肀憷耐瑫r，一些使用過程中的問題也凸顯了出來。

1.1 監(jiān)控不全面

大部分系統(tǒng)除導(dǎo)入了Linux基礎(chǔ)監(jiān)控模板之外，尚未針對各業(yè)務(wù)系統(tǒng)進行自定義監(jiān)控。因此基本上只能監(jiān)控CPU、文件存儲、內(nèi)存、網(wǎng)卡出入口流量、業(yè)務(wù)進程狀態(tài)、業(yè)務(wù)端口等基礎(chǔ)性的應(yīng)用及監(jiān)控。

1.2 系統(tǒng)不集中

初期建設(shè)后，部門內(nèi)部的Zabbix系統(tǒng)共有5套。

伴隨著監(jiān)控系統(tǒng)使用，分散建設(shè)的弊端也逐步顯現(xiàn)：（1）由于搭建Zabbix先后不一致，因此有的Zabbix版本是2.1，有的是3.4，彼此之間的模板存在不兼容的情況。（2）分散建設(shè)的Zabbix系統(tǒng)基本都存在單點問題，如果要實現(xiàn)高可用，會消耗更多的虛擬機資源。（3）Zabbix的日常維護成本較高，且由于各小組對Zabbix的熟練程度有所差異，不利于Zabbix系統(tǒng)維護的專業(yè)化。

1.3 規(guī)范不統(tǒng)一

在同一個Zabbix系統(tǒng)上，由于缺乏前期統(tǒng)一的要求，在主機命名、告警級別定義、主機關(guān)聯(lián)模板等方面都沒有統(tǒng)一的規(guī)范，以致配置維護時偶爾會出現(xiàn)命名沖突、告警混亂（例如嚴(yán)重級別的告警被定義成致命級別）。對于Zabbix的管理沒有進行嚴(yán)格的權(quán)限劃分，使得在告警閾值調(diào)優(yōu)時都得在模板基礎(chǔ)上去修改主機的信息，優(yōu)化的配置信息難以通過模板進行復(fù)用。

1.4 指標(biāo)采集方式單一

不同的業(yè)務(wù)系統(tǒng)，實際上可以有不同的指標(biāo)采集方式，例如除了Zabbix Agent之外，還包括JMX，SNMP，ICMP，SSH等多種監(jiān)控方式。但各業(yè)務(wù)系統(tǒng)基本還停留在Zabbix Agent告警方式。

2 監(jiān)控運維體系建設(shè)的策略研討

通過在研討小組提交的調(diào)研報告基礎(chǔ)上綜合利弊分析，我們最終決策整個監(jiān)控運維體系的建設(shè)需要分階段進行，不適合盲目上馬一套大而全的監(jiān)控運維系統(tǒng)，以避免出現(xiàn)重型的監(jiān)控運維系統(tǒng)與公司當(dāng)前系統(tǒng)、管理流程、甚至理念上的分歧。在當(dāng)前階段，比較務(wù)實的策略是基于Zabbix開源軟件，進行監(jiān)控系統(tǒng)設(shè)備和規(guī)范的統(tǒng)一，完善立體化的監(jiān)控體系，并采取方式多樣的指標(biāo)采集手段。

3 監(jiān)控系統(tǒng)的規(guī)范化建設(shè)

3.1 Zabbix系統(tǒng)的高可用部署

為了滿足Zabbix系統(tǒng)安全穩(wěn)定可靠的運行，選擇采用物理機而不是虛擬機來進行Zabbix的部署安裝，并且支持Zabbix應(yīng)用和數(shù)據(jù)庫的主備切換。優(yōu)化之前我司的Zabbix部署，多個小組各自有一套服務(wù)器，且彼此之間的版本不一致。優(yōu)化之后將業(yè)務(wù)運維、大數(shù)據(jù)、播控組及臺網(wǎng)3個小組的Zabbix Server進行了合并，如圖1所示，然后將Zabbix監(jiān)控數(shù)據(jù)通過Grafana進行統(tǒng)一的圖形化展示[1]。

圖1 優(yōu)化之后的Zabbix部署

3.2 Zabbix監(jiān)控的規(guī)范化管理

3.2.1 模板命名規(guī)范

根據(jù)不同的監(jiān)控對象設(shè)置不同的監(jiān)控模板，我們規(guī)定模板名稱需要遵守以下規(guī)則。

模板名稱示例：zbx_os_linux_xxx，其中第一位zbx固定，第二位os代表監(jiān)控大類，表示操作系統(tǒng)，第三位linux代表監(jiān)控小類，表示具體的操作系統(tǒng)，第四位根據(jù)具體情況可以是應(yīng)用系統(tǒng)名稱/版本/IP等。名稱盡量都采用小寫[2]。

3.2.2 監(jiān)控項數(shù)據(jù)保留時長規(guī)范

統(tǒng)一規(guī)定采集數(shù)據(jù)的歷史保留時長和趨勢數(shù)據(jù)保留時長，如果沒有特殊要求，歷史數(shù)據(jù)保留兩周，趨勢數(shù)據(jù)保留1年。

3.2.3 觸發(fā)器命名規(guī)范

觸發(fā)器的名稱盡量能夠包含最直觀的信息，比如，操作系統(tǒng)：ABCD（11.22.33.44）CPU使用率大于70%。

對不同的監(jiān)控大類需要在觸發(fā)器名稱的開頭添加相應(yīng)內(nèi)容。

3.2.4 觸發(fā)器閾值規(guī)范

模板中觸發(fā)器表達式中設(shè)置的閾值，除狀態(tài)值外都需要使用用戶宏，這樣在主機中就能夠修改從模板繼承的用戶宏，而不影響其他的主機。

3.2.5 主機關(guān)聯(lián)模板規(guī)范

主機層面無特殊情況不允許創(chuàng)建主機、觸發(fā)器等元素，只能將這些元素定義在模板中然后與主機關(guān)聯(lián)。在主機層面修改繼承來的用戶宏是允許的，也是比較推薦的。

3.2.6 告警動作配置規(guī)范

告警動作根據(jù)現(xiàn)有環(huán)境配置，支持可擴展，不能因為添加一臺主機或一個群組就要單獨創(chuàng)建另外的告警動作。

設(shè)置合理的告警升級策略，避免發(fā)送嚴(yán)重級別不高的信息給上級，造成告警泛濫[3]。

3.3 Zabbix系統(tǒng)權(quán)限管理

每套Zabbix系統(tǒng)只指定兩人擁有Zabbix超級管理員權(quán)限，其他人員只有查看權(quán)限，所有的修改操作只能由兩名管理員執(zhí)行。管理員進行修改操作時，需要將操作內(nèi)容記錄下來，并共享給另一位管理員。默認的Admin用戶禁止開啟，管理員不能將自己的用戶和密碼提供給不熟悉Zabbix的人員，獲取用戶密碼的人員如果沒有獲得修改允許，不能進行修改操作。

4 結(jié)語

經(jīng)過近兩個月的咨詢和整改，基本完成了基于Zabbix開源軟件進行監(jiān)控系統(tǒng)設(shè)備和規(guī)范的統(tǒng)一，基于Agent，JMX，SSH，ICMP等多種形式的指標(biāo)采集手段，初步實現(xiàn)了基礎(chǔ)硬件環(huán)境、操作系統(tǒng)軟件、業(yè)務(wù)應(yīng)用系統(tǒng)以及用戶業(yè)務(wù)入口的立體化監(jiān)控，為業(yè)務(wù)系統(tǒng)的穩(wěn)定可靠運行提供保障。

今后，對已有的指標(biāo)告警項需要分析核實，并將告警閾值調(diào)整至與業(yè)務(wù)應(yīng)用相協(xié)調(diào)統(tǒng)一的范圍；根據(jù)業(yè)務(wù)系統(tǒng)建設(shè)規(guī)劃和部署，繼續(xù)補充和完善監(jiān)控指標(biāo)應(yīng)用集；根據(jù)業(yè)務(wù)系統(tǒng)日志，通過自定義Python腳本，完善業(yè)務(wù)系統(tǒng)各接口和代碼的業(yè)務(wù)層面告警；根據(jù)釘釘電子流審批的接口文檔，研究Zabbix告警與釘釘電子流的對接，實現(xiàn)告警處理的工單化。