七年磨一劍：如何像MIUI同樣作Zabbix二次開發？

時間 2019-11-29

原文原文鏈接

如下是本人的分享，同時我的簡書也有登載：https://www.jianshu.com/u/5e7803f82b0d
本文根據DBAplus社羣第132期線上分享整理而成。前端

講師介紹
咱們的願望是基於Zabbix這個強大開源平臺，結合實際一線運維工做的須要+ITIL等運維理論，作成相似MIUI同樣的開發、易用、實用、人性和美觀的全新監控平臺。所以，今天我會從技術方向的選擇、開發、架構設計到深度定製，分享咱們在Zabbix二次開發上的一些前瞻性想法。ios

主題大綱：算法

一、爲何選擇Zabbix？數據庫

二、Zabbix二次開發有什麼意義？瀏覽器

三、咱們是怎麼作的？緩存

四、咱們還利用Zabbix解決了什麼問題？安全

五、咱們未來要怎麼作？前端框架

1、爲何選擇Zabbix 服務器

爲何要作監控？微信

運維的正確姿式確定不是從處理故障開始，必定是從監控開始的。

從軍事的角度出發，監控是一種積極防護戰略，是未戰之戰，有效的監控能夠拓寬戰略縱深，能夠更積極地保護咱們的重點軍事目標。如下是咱們要求運維團隊時時牢記的兩句話：

出了任何故障，其它環節均可能有問題，惟獨監控環節必定有問題。
海恩法則：每一塊兒嚴重事故的背後，必然有29次輕微事故和300起未遂先兆以及1000起事故隱患。

IT服務成熟度模型中，監控手段是轉被動運維爲主動運維的必然「預防「和」度量「手段。所以，在這麼多年的重大故障分析會議上，監控問題老是在會議前期和後期都拿出來重點討論的，會議一開始就要問「爲何故障沒有被監控出來」或者」在故障發生的先後都監控出來什麼異樣「。會議結束前的總結一般是「對於漏掉的監控項必定要被加入「或者是」對於監控到的指標或閥值必定要被優化「。

若是這四個問題都被很好地回答並改善，我想下次相似的故障是不可能出現的，所以，作監控須要有一個PDCA持續改進的過程，固然，改進的核心有且只有兩個：「覆蓋率「和」準確率」。

固然，對於一個更優秀的監控系統，它還能夠有以下價值：

對組織：

全局監控幫助組織制定IT管理戰略
從IT資源到組織業務的直接對接
制定IT資源、IT組織工做管理的基礎
組織與內外部IT組織的溝通樞紐

對IT管理者：

IT管理者工做價值體現
幫助IT管理者全面瞭解IT現狀
方便IT管理者管理IT組織的工做績效
搞高IT部門的工做效率，減小企業成本
下降業務系統宕機風險

對IT操做者：

及時發現業務系統各個單元故障
深度定位系統的故障根源，及時解決
拉近IT操做者與組織業務的距離
直接體現具體IT操做者的工做業績
幫助從IT的角度提升促進業務高效穩定

爲何是Zabbix？

前不久看到一則路邊社報道，在中國有80%的企業在使用Zabbix作監控，不知道統計的方法和口徑是怎樣的，不過，80%這個數值也感性地傳達了它的熱度。

統計數據

在Zabbix的官網上找到一個清單，一堆國外知名公司都是它的合做夥伴，就最近的交流溝通中，但凡是有計劃作監控的組織無不試用Zabbix的，若是有網友有更值得參考的統計數據，能夠回覆本文，並註明數據來源。

目前，從IT Central Station的官網找到一份統計信息，這份統計數據是由加入這個網站的企業CIO反饋的信息實時獲得，如下這份數據是2017年11月18日生成的。

這份統計數據主要來自北美的參與者，在國內沒有表明性，不過相信在國內的數據會比這個更高，國內對於免費和開源的被教育程度顯然是更高，這個得益於紅衣教主周鴻禕，以及一堆互聯網公司的推高和強化，至於背後的商業倫理和其餘成本問題姑且不論。

Zabbix的特色

Zabbix是一個基於WEB界面且提供分佈式系統監控的開源解決方案，經過瀏覽器監視，作到告警分級處理、網絡訪問安全可控，該開源平臺在全球有普遍的用戶基礎，它的特色：

開放性：源代碼全公開，任何用戶均可以編譯和發佈本身的版本。同時，社區和互聯網能夠找到大量的模板。
可擴展性：支持用戶自定義監控項，只要能想獲得的指標，基本都能監控的到。
數據採集：可用性和性能檢測，自動發現，支持agent、SNMP、JMX、telnet等多種採集方式，支持主動和被動模式數據傳輸。
高可用：Server對設備性能要求低，支持Proxy分佈式監控，分佈式集中管理，開放式接口，擴展性強。
告警管理：支持多條件告警，支持多種告警方式。
模板能力：支持多組模板，模板繼承。
告警設置：告警週期、告警級別、告警恢復通知、告警暫停，時段閾值、支持維護週期、支持單機停用。
歷史數據：歷史數據查詢可配置，內置housekeeping數據清理機制。
安全審計：具有安全的用戶審計日誌、權限認證，用戶能夠限制容許維護的列表。
無商業版本：平臺自己沒有商業版和社區版本的區分，ZABBIX只對商業服務收費（如培訓、定製開發、部署服務等）。
等等……

Zabbix的全棧監控能力：官網有一句很是「囂張「的話，Monitor everything！

與其它商業產品對比

各個大廠都有提供相關監控產品，好比說微軟的SCOM、IBM的Tivoli、華爲的Esight、HP的BSM等，若是環境都是單一的某一家廠家的產品，用該廠家提供的監控工具確定是合適的，筆者就曾經深度使用過SCOM，2005年還叫MOM，是System Center中的一個套件，這個產品對於微軟周邊的產品如AD、Exchange、Windows、SQL Server、SharePoint、Lync等監控很是深刻，同時微軟官方還提供了相關故障知識庫，報表也作得很是不錯，九一樂維團隊甚至在2011年之前還拿SCOM作過定製開發。

可是，若是拿SCOM去監控Linux、AIX、Oracle或者網絡通信設備就很是不合適了。這裏，Zabbix就可以很好地平衡監控的深度和廣度，並且源於開源的力量，在全球用戶的持續貢獻下，它的深度和廣度是在持續不斷地延展的。

如下引用翔華兄（Shawn沙恩）的一張圖說明Zabbix的深度和廣度，見：https://www.jianshu.com/u/c7663d8c3fa8。

與其它開源項目對比

前文提到在IT Central Station中，Nagios X排在Zabbix的前面，咱們團隊在定技術方向時，也深入對比過，二者簡言之：Zabbix安裝好後，作一些簡單的設置基本上就能夠用了，Nagios X部署完成後至關於只是一個平臺，須要安裝第三方插件才能起做用。詳細對好比下：

固然，市面上還有諸如：Open-Falcon、Zenoss、Ganglia、Prometheus、Cacti等開源產品，簡單分析以下：

Open-Falcon：小米開源，時間不長，成熟度有待提升，如今的版本是V1.0。
Zenoss：區分社區版和企業版本，資源消耗高，社區版本有些雞肋。
Ganglia：適合監控系統性能，成熟度和完整度不高，如報警、消息系統，須要更多二次開發。
Prometheus：開源的業務監控和時序數據庫，剛發佈2.0，在穩定性、性能、文檔上仍有很大提高空間，互聯網上可用資料，案例還不豐富。
Cacti：經過 SNMPget來獲取數據，使用 RRDtool繪畫圖形，畫圖功能強大，報警機制及相關功能不完善。

以上這些產品，筆者認爲Prometheus會是個不錯的方向，最根本是它的時序數據庫，有興趣的讀者能夠先行先試。

2、深度定製的意義

綜合來說，Zabbix是一個很是強大的監控平臺，簡單拿來完成監控一些Hosts，沒有什麼問題，並且目前國內大部分客戶都是這麼作的，基本上是安裝完後，網上找到一些相關模板，配置後把Hosts監控起來就差很少了，固然也不乏像PPTV、攜程、惟品會等這樣優秀的互聯網公司，作了深度定製和改造。

一個剝離的工具平臺

Zabbix的全部監控對象都被認爲是Host，包括主機、網絡設備、中件間和數據庫等，這樣除了作監控，以後的運維管理工做就很不方便了，好比說配置管理、統計報表、權限、知識庫、業務服務管理、CFIA等都會受影響。因此，原生的Zabbix仍然是一個原生的高度剝離的工具平臺。

其它問題：

性能瓶頸，監控系統沒有低估高峯期，具備持續性和週期性，機器量越大，數據的增大會使數據庫的寫入成爲必定的瓶頸，每秒1萬個指標（咱們在項目實施過程當中，達到過3萬多個指標），聽說4.0每秒40萬個指標。
項目二次開發，須要分析MySQL表結構，表結構很是複雜，對開發能力有較高要求。
內置housekeeping在執行過程當中會對數據庫增長壓力，須要對數據庫進行優化。
圖形功能較爲單1、簡陋。
使用有難度，要求操做人員的技術水平很豐富且全面，須要熟悉被監控對象，已經具有至關的開發能力。
API介紹比較粗糙，若是數據庫表結構更改可能會影響API調用。
Zabbix 監控的模板比較複雜，沒有一個比較簡潔易懂監控模板建立的嚮導，使得模板配置比較困難。
Zabbix 的用戶權限控制粒度不夠。
Zabbix的交互界面還不美觀，操做不人性化。

固然，還有那些你沒有深刻使用就永遠也發現不了的坑。

顯性化的需求

在界面展現上，目前使用較多的Grafana+Zabbix，能達到必定的展現效果，實施效果以下圖：

也有58同城運維團隊開源的Zatree插件，實施效果以下：

若是要求再高一些，就有些困難了，常常能看到但願能夠用ECharts展現Zabbix數據的需求，甚至能夠看到很多Zabbix數據與第三方商業顯示插件的集成需求。

深度集成的需求

監控軟件於信息化體系不是孤立存在的，把監控平臺獨立成一個信息孤島，是不符合信息化初衷的，可能存在的集成系統列舉以下：

其它運維工具：ITSM（也多是獨立的工單系統、服務檯系統、CMDB或資產管理系統）、動環管理系統、APM系統、DevOps系統、自動化運維工具平臺、日誌平臺、端對端撥測系統、安全系統、4A系統、審計系統私有云平臺等。
消息通知：短信、微信、郵件、釘釘、內部IM系統等。
組織架構系統：組織架構、人員同步、權限系統、單點登陸系統等。
統一展現：Portal系統、投屏、OA系統、微信公衆號、業務數據統一呈現等。
其它：組織APP、企業知識庫、音視頻交互平臺、大數據平臺等。

信息系統的集成是信息化建設很是困難的一環，數據信任、源數據穩定、接口對接、例外處理，考驗着信息化整合架構能力和信息系統質量。

業務保障的須要

監控的核心意義在於保障業務系統高可用性，尤爲是核心業務系統的高可用性，而不僅是監控那些Hosts，完成Host的監控只是完成了第一步，還須要作好三道必選題：

Hosts和業務系統存在怎樣的關係？
業務系統出現故障時，哪些Hosts的狀態和性能存在什麼直接或間接影響？
當前Hosts的告警，到底對哪些其它Hosts或業務系統存在怎樣的影響？

3、咱們是怎麼作的

作監控源於咱們早期作運維服務的必然需求，咱們的願望是基於Zabbix這個強大開源平臺，結合實際一線運維工做的須要+ITIL等運維理論，作成相似MIUI同樣的開發、易用、實用、人性和美觀的全新監控平臺。

架構設計

下圖是咱們的軟件邏輯架構：

這個架構有兩個最重要的基礎：

將Hosts區分爲主機、網絡通信設備、數據庫、中件間、業務系統、虛擬機、硬件、鏈路等實體IT基礎架構組件。
深度定製的基於Zabbix API實現，以PHP語言實現，把Zabbix原生頁面保留在系統後臺。

軟件平臺在功能邏輯上分爲四層：

基礎層：這一層以一個分佈式、高可用、高併發的軟件服務端爲基礎，構建以被馴服了的監控模板、指標和閥值爲基礎的底層監控體系，這一層純粹是咱們使用Zabbix的積累和經驗。
功能層：基於Zabbix API實現的管理功能，這些功能抽取了大部企事業單位的監控需求的公約數。

展現層：監控效率的顯性化表達，大屏設計，業務地圖（CFIA的顯性化），網絡拓撲圖，大部分客戶都會須要業務量監控的顯性化集成，業務量監控自己又是另一個話題，固然這裏的業務量核心在於源數據的獲取，剩下的套路都基本一致，設計指標、設置閥值、觸發告警通知等。
接口層：主要對接外部接口，如IM、短信、郵件、聲音等。

在功能上最大的三個特色是結合生產實際，實現了拓撲的自動生成、自定製投屏和業務地圖（CFIA，故障組件影響分析樹），拉近了Zabbix和業務生產運維的實際須要。

前端交互

界面採用了Twitter開源的Bootstrap的前端框架，圖表採用了Baidu開源的ECharts控件。

踩過的那些坑

從2011年開始玩Zabbix，踩過的坑着實很多，被研發的同事吐了無數槽，所謂「情到深處又愛又恨「。如下簡述印象比較深入的幾個坑：

二次開發的方式：2011剛開始作的時候，咱們直接修改Zabbix開源的源代碼，實現了一些功能，自覺得作得還不錯，但後來Zabbix升級一個大版本，發現Zabbix作得比咱們高明多了，因此以後咱們都儘可能不去改Zabbix的源碼，動也只是作操做層面的改進，用戶交互的改良。
模板：一開始咱們想得很簡單，網上收集一堆模板，這個事就算作完了，後來發現這只是個開始，默認模板考慮的深度還不夠，須要持續改良和積累。
沒必要要的Item：在作IT基礎架構監控尤爲是網絡監控的時候，對於Item的啓用、對於指標收集的及時性和數據容量的控制相當重要，一開始咱們幾乎啓用了全部Item，後來發現監控的效率和數據庫日增量實在讓人受不了，最後想辦法壓制了一些不多被用到的Item，改進的效果很是明顯。
Oracle的監控：用原生的Orabbix監控Oracle時會有些問題，好比說常見的審計問題，須要DBA持續優化。
數據清理的問題：Zabbix默認配置了Housekeeping來清理數據，但根據咱們的經驗，在執行清理時除了影響數據庫運行，還有約15%的系統資源的損耗，所以，咱們默認關閉了這個功能，將這個功能腳本頁面化了。

其它問題：

監控頻率沒法作到秒級別；
Web撥測只支持get和post，中文亂碼；
腳本下發只支持Shell，而且搭配告警等觸發，沒法手動；
IPMI輪訓存在延時；
告警有時會沒法自動恢復；
SNMP監控請求一個監控項一個鏈接請求；
… …

常見優化的方向

如下簡單列舉咱們常見優化的幾個方向：

高可用部署：高可用部署依賴可預見的監控規模和組織，對監控系統的重視程度漸次增強，最簡單的起碼作到Web和DB的分離；其次，作到數據庫層面的高可用；而後是分佈式代理，甚至代理層的高可用；再是考慮Web層的負載，最後，有條件的能夠加一層冷備。
數據庫優化：Zabbix的數據庫優化是被提到最多的，一般矛盾最突出的也是MySQL的性能，一般的解決辦法是：表分區；優化Item；多采用主動方式採集；Housekeeper優化；優化觸發器表達式；數據庫主從，Proxy模式；Zabbix配置文件調優；分表；提升機器配置（SSD）。
在本文章要交付發表的時候，收到一則新聞：Zabbix 3.4.5 可能使用基於 Elasticsearch 的歷史數據服務接口，再也不受限於單機 MySQL 的容量和性能了。
數據庫監控：上一節提到Oracle監控的坑，其它數據庫也同樣，多采用本身可控的監控方式。
鏈路監控：單獨把鏈路監控提出來，對於一些有分支機構的組織來講顯得尤爲必要。
歷史數據存檔與清理：一般限定詳細監控數據的保存時間，只保留趨勢數據，轉存或清理歷史數據，咱們採用腳本頁面化的方式實現。
監控平臺的自監控：監控Zabbix自己的狀態