![]()
本文來自江蘇電信智能雲網調度運營中心張哲峯在Zabbix Meetup南京站的演講，張哲峯也是Zabbix中文手冊譯者，感謝張哲峯對社區的大力支持！
![]()
雲計算在江蘇電信是一項比較新的業務，只有十幾年的歷史，不像核心網等傳統通信業務，由一或幾個廠家主導，可以提供一個非常完善的網管，因此雲底層的監控天然具有解耦性。一路走來，從最初的人工巡檢、寫腳本執行定時任務，到採用的定製化網管商業產品。從17年左右，江蘇電信開始積極擁抱開源，選擇了Zabbix作爲集中監控系統，最終融合江蘇電信自研雲運維平臺——凌霄，成爲監控的底層實現模塊。
Zabbix作爲一款成熟的開源產品，在江蘇電信的應用非常廣泛。省管平臺中的CT雲，也就是我們部門負責維護的私有云，主要是底層硬件，共計10000+主機，是省內最大規模的監控；其次是IT雲，以虛擬機監控爲主，也有10000臺以上的體量；除了雲之外，Zabbix還承載了諸如核心網、數通等專業部門的通用硬件和業務系統約5000臺的監控量。
江蘇電信的專業子公司，號百、智恆、全渠道，地市分公司維護的行業雲、政務雲以及一些自建的業務平臺，也都應用了Zabbix進行監控。此外電信負責的一些客戶項目，比如說華泰桌面雲、蘇果混合雲，也選擇了Zabbix作爲底層監控系統。總而言之，Zabbix在江蘇電信應用規模大、範圍廣，可以說是監控的中流砥柱。
![]()
聚焦到我負責的私有云方面，去年完成物理機上雲後，版本從4.0升級爲6.0，採用的是docker部署的雙server高可用架構，後端採用Postgresql+timescaledb的時序數據庫插件，通過電信內網連接位於其他資源池的proxy。系統劃分爲兩套，一套位於吉山數據中心，負責儀徵資源池的監控，另一套位於儀徵數據中心，負責儀徵以外資源池的監控，兩套Zabbix以agent和web撥測的方式相互監控。我們維護的雲底層，硬件設備包括網絡設備、服務器、磁陣等，涉及華三、華爲、中興、浪潮、曙光等，可以說幾乎涉及所有主流廠商，硬件監控方式以snmp get方式爲主，這是傳統的網管協議，絕大多數產品都支持，不過具體監控效果就取決於廠家的的協議實現，此外有一些不支持snmp協議的老舊設備，我們用ssh監控方式通過運行腳本登錄巡檢的方式加以補充。
在軟件方面，主要涉及虛擬化軟件，比如vmware的vsphere、中電數智，也就是電信自研的基於openstack的虛擬化產品，分佈式存儲，比如華爲等廠商的存儲軟件，以上軟件都支持snmp trap，先將告警發送至內部私網的proxy，再送至外部的server，此外還有一些軟件的監控通過廠家開發的Zabbix trapper程序。除了軟件硬件，我們內部的操作系統、零星的內部運維繫統也會通過Zabbix agent監控，進行常規的端口、進程、自定義監控項，以及通過HTTP撥測業務API等。
雖然Zabbix的功能強大，但是隨着使用的深入也逐步發現一些系統之外的問題。隨着資源池的增大，一次擴容動輒成百上千，手工添加監控已經人力所不能及，此外隨着主機羣組、用戶、告警方式的增多，賬號的權限、告警條件的設置都變得非常複雜容易出錯，此時再指望完全由個人去維護監控就變得不太現實了。爲了解決這些問題，我們將省內的雲運維平臺——凌霄平臺與Zabbix結合起來，通過平臺去管控監控的生命週期。
凌霄平臺主要做了兩件事，第一是由CMDB保證資源的準確，通過調用Zabbix的API實現監控任務的下發，第二是Zabbix不直接調用告警系統，而是將告警匯聚至凌霄平臺，由平臺去做告警的預處理和訂閱，確保派發策略的可見和統一管理。
![]()
當有新設備入網時，集成人員準備好網絡環境、設備資料，在設備上完成snmp配置；Zabbix系統管理員完成proxy的部署和羣組創建等準備工作；維護人員在CMDB中錄入信息，平臺進行規範稽覈後完成錄入，實現主機的創建和關聯對應模板，這樣三路並進，全部完成之後新設備的監控就完成了。通過這樣的方式，首先極大的提高了工作效率，可以一次性下發大量的主機，迅速完成擴容設備的監控納管；第二，通過CMDB確保了資產的準確，資產錄入是在一張excel表完成，表格的設計原則是”儘量避免人工填寫、儘量避免重複信息“，一些相對固定的字段比如廠家、型號，採用下拉表格的方式進行選擇，儘可能避免人工填寫可能導致的錯誤，而設備的名稱也有明確的規範，包含了平臺、機房、機櫃等物理信息，通過多個字段拼接合成，確保命名不會重複，第三，監控下發過程全部由平臺完成，確保不會出現人工操作的比如遺漏和錯誤，我還將snmp無數據設置爲了告警，確保監控項的有效性，第四，取消了普通用戶Zabbix賬號的操作權限，所有增刪修改操作全部通過系統執行，每一步操作都有記錄留痕，權責分明。
除了Zabbix之外，我們還有其他的告警源，例如天翼雲、prometheus、內部業務以及外部客戶的監控系統，如果在每一個系統中進行告警的處理會導致管理的碎片化，因此告警被統一匯聚到凌霄平臺，實現告警的預處理和發送。首先實現了統一的大屏展示，對於值班人員接到告警工單時瞭解全局狀況是十分重要的；第二可以對告警進行一些預處理，目前實現的主要是告警壓縮和關聯預警。在日常工作中有時會遇到告警風暴，比如網絡問題導致的大量ping不可達，比如某服務器宕機導致的多個相連交換機端口dwon，在平臺上可以自定義告警歸併策略，例如按照相同主機、按照相同告警歸併，以及根據拓撲將對端相同的交換機端口down告警合併，這樣可以有效壓縮告警數量，減少重複告警的打擾。除了歸併之外，還可以進一步進行故障面的分析，實現告警到業務之間的關聯預警，例如宿主機宕機會導致承載的虛擬機重啓，此時平臺會自動給業務維護人員發郵件通知，儘量減少業務中斷時間。
告警經過預處理之後就通過各種媒介進行發送，目前採用的是短信、工單和即時通訊工具三種方式，三種方式各有利弊，因此需要相互補充。短信最爲便捷，但是由於缺乏管控手段，也容易被忽略和遺忘。工單會通過語音外呼通知維護人員直至接單爲止，確保通知到人，實現了告警的處理留痕和閉環管控，爲了減少夜間工單對維護人員的打擾，工單被分成三等，第一等是24小時立即派單，針對的是可能大規模影響業務的重要告警，二等是24小時延時派單，延時期間如果告警恢復了則不派單僅僅短信通知，針對的是可能自恢復的次級告警，三等是僅僅白天派單，夜間工單會延遲至早晨補派，針對的是硬件故障一類無需立即處理的告警。除了告警工單之外，例如帶寬利用率偏高等不直接影響業務、但是長期下來可能形成隱患的問題，會通過隱患工單派發給維護人員。以上兩種傳統方式由於依賴於電信內部系統存在隱患，因此增加了企業微信和釘釘發送羣消息作爲補充，即時通訊軟件消息可以非常方便在電腦上處理故障，另外還具備一定的二次開發能力。
![]()
Zabbix的使用在官網手冊上已經有了很詳盡的介紹，下面和大家分享一下我的經驗和教訓。
一套原生的Zabbix就只適合一箇中小規模的監控場景。單套Zabbix有其性能瓶頸，最初我們用物理機部署了一套4.0版Zabbix對全省業務做集中監控，儘管物理機性能很強大，但是在8000臺主機時就超出了系統負荷，不得不進行拆分，而且涉及部門一多需求就變得複雜，人員、權限的變更也變得難以控制，所以這是我的第一個建議，控制系統規模和範圍，把系統限制在一個管理單位之內。
第二就是做好系統本身的監控，如果server發生宕機那麼是發不出任何告警的，所以最好有另一套系統對server進行監控，這也是我們沒有用位於儀徵資源池的Zabbix監控儀徵資源池，而是另外在吉山建了一套的緣故。
第三是確保告警渠道有效，任何系統都不可能保證永不宕機，因此不要把所有的希望都寄託到單一告警渠道上，最好通過多個相互補充，同時再做好告警撥測，比如我們的系統每天早上都會發一條短信、一個工單、一條企微信息，幫助維護人員發現系統問題。
如果Zabbix規模很大或者有多套，那麼就可以通過一個上層系統去統一管控就很有必要了。在創建監控的時候，儘可能的通過模板而非直接在主機上創建監控項，這樣一方面方便複用，另一方面變更需求時只需修改模板。在選擇監控方法時，首選通過web即可配置的方法而非需要在proxy或者主機上放置腳本的方式，這樣在遇到涉及重裝、更換proxy的時候可以避免很多麻煩。最後，嚴格控制好用戶的權限，以免出現用戶私自停用主機、停用觸發器，甚至修改模板的情況。
最後給大家分享一些教訓。Zabbix的功能非常強大，但它並不是無所不能，我們曾經做過很多嘗試，比如通過ssh監控項進行設備巡檢，但是這種方式一來無法靈活控制執行，二來修改密碼或者檢查執行結果時需要逐臺進行查看；我們還嘗試過用Zabbix採集數據，通過設置監控項採集例如設備序列號、配置之類的硬件信息，這樣做的後果是監控項數量的暴增，甚至於導致最新數據界面無法打開；我們還嘗試過用Zabbix做安全掃描之類的定時任務，嘗試做業務的日誌檢查，技術上都可以實現，但是會造成管理的困難，如果維護跟不上，後期就會出現大量失敗監控項、無人認領的腳本和文件各種問題。
所以
我的建議是明確Zabbix的系統定位，讓Zabbix做好自己監控的的本職工作，遠程作業有ansible，日誌採集有elk，讓更專業系統做專業的事，避免職責不清的情況，保證工作的長期有序。
![]()
![]()
本文分享自微信公衆號 - Zabbix開源社區（china_zabbix）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
