運維思索：cmdb與zabbix監控系統的融合

這是我參與8月更文挑戰的第3天。

簡述

各位小夥伴，近期技術文感受發的有點多，不知是否給你們在工做中解決實際問題帶來了一些靈感。爲何這麼說呢？由於正是文章中涉及的細小知識點聚沙成塔，讓我從零碎繁忙的運維工做中獲得了必定程度的解放。相信認真讀過的小夥伴，必定會以爲工做中並不是只有什麼高大上的技術才能解決痛點，偏偏相反，正是那些咱們平時忽視的細節纔是問題的要害。那麼只有切中要害，咱們才能對症下藥。

所以接下來一段時間，我可能會陸續分享運維過程當中對一些問題的思考，但願給你們帶來必定的啓發。

本次分享的是cmdb與zabbix監控系統的融合。

現狀

1.維護不足

（1）當前運維環境下，監控系統比較獨立，須要手動進行分組、建立模板、添加監控等一系列操做；並且隨着主機、業務不斷增多，分組已經嚴重脫離當前業務分組、架構分組等； （2）部門多人協做，溝通協調不足，致使監控系統混亂，雖然當前監控系統指定了一些列維護規範，如：命名、監控間隔、故障分級等；可是監控仍然混亂；

2.性能不足

（1）隨着server愈來愈多，監控覆蓋基礎監控、網絡監控、業務監控、日誌監控等；監控的細節須要不斷放大，勢必會致使監控的性能降低；所以須要經過調整被動爲主動、監控分級、監控間隔等一些優化； （2）網絡抖動或其餘因素致使的告警氾濫、誤報警，給運維人員帶來沒必要要的麻煩，所以須要告警收斂來避免；

3.融合不足

（1）目前經過藍鯨標準運維實現虛擬機到jumpserver、cmdb的交付；到zabbix監控系統的交付依靠zabbix的自動發現主機，即主機的基礎監控；cmdb沒有和zabbix打通； （2）端口監控和業務監控是經過「系統上線流水線」來自動添加到監控系統；業務沒法映射到zabbix； （3）zabbix和藍鯨故障自愈打通，能夠基於cmdb進行自愈；

思考

1.維護不足的問題爲什麼發生？

從server的上架流程出發，在server上架前咱們已經肯定此server部署什麼業務、此業務的端口及url。在上架過程當中咱們須要通過操做系統安裝、jumpserver添加、cmdb註冊，這些都已經過藍鯨標準運維打通；到監控系統，咱們只是經過自動發現添加主機基礎監控，而後再經過系統上線時自動添加端口監控和業務監控，徹底忽略了業務分組，只能經過後期人工維護。

2.性能不足問題爲什麼發生？

（1）性能不足的緣由不是一次性致使，而是隨着監控項不斷增多而引發的連鎖反應，所以咱們須要對每一個層次使用提早作好分級的模板，自動下發匹配模板，避免各級人員由於對監控理解不足致使系統性能突發性降低。此種狀況只是避免了監控系統的突發性降低，並不能完全隨着時間推移的性能降低。 （2）zabbix雖然在必定程度上知足了咱們的大部分需求，可是咱們經過其餘監控工具和zabbix的互補來分擔其性能，如：

• grafana，咱們能夠將部分的告警源接入到grafana；
• alertmanager，經過更高級的告警管理手段，能夠有效解決咱們的一部分告警方面的問題；
• Cacti，將網絡層面的監控控交給更正專業的網絡監控工具；
• Prometheus，實現容器層面的監控；
• ELK，實現應用流量方面的監控；
• APM，實現鏈路跟蹤等；

所以咱們的監控必定是一個多種監控工具融合的平臺，而並不是徹底靠Zabbix覆蓋全部的監控需求，這是不顯示的。

cmdb和zabbix的融合不足爲什麼發生？ cmdb在監控系統中扮演的角色是什麼？若是隻是資產管理，那cmdb在企業中的角色將會不斷弱化，最終成爲雞肋。所以咱們須要將cmdb做爲一切運維繫統的數據支撐，固然也包括監控系統。那麼融合不足的問題也就找到了，就是cmdb沒有在監控系統中起到數據支撐的做用。

展望

1.融合cmdb

cmdb打通到監控系統的通道，在新的對象加入CMDB的時候可以自動將該對象加入監控系統；同時在配置數據發生變化的時候，可以經過監控系統發出必要的告警信息； 如機器上線，則自動註冊到cmdb；業務變動，自動註冊到cmdb；角色變動、停機維護也要變成cmdb。此時監控系統只須要維護好相應的規則，便可讓監控自主添加，從而彌補自動發現的不足；同時靈活性大大加強，只要cmdb獲取到設備的相關信息和狀態，而後主動更新監控系統，而且糾正之前添加好的但沒有持續更新的監控。

2.cmdb數據支撐

cmdb須要爲監控系統提供必要的支撐數據，來立體化、標準化告警信息； 這個怎麼理解？一般狀況下咱們收到zabbix監控系統的信息只是「XX對象的XX指標告警和詳情信息等」，可是咱們不知道這條告警信息屬於應用系統、哪一個環境、是否高可用、應用負責人是誰、哪些系統依賴它、是否進行過變動，以便運維可以作出進一步的判斷和安排。那麼這個時候，咱們就須要一個系統可以提供：應用層次拓撲、集羣信息、模塊信息、資源實例、關聯關係等信息，這個系統就是CMDB。

經過以上二者的結合在告警發生的時候呢，咱們就可讓告警系統前往CMDB中查詢跟這一告警對象有關的綜合配置信息，以便提供最爲準確、豐富和標準的告警信息。

解決思路

1.藍鯨監控、zabbix、grafana多監控系統互補運行

• a.藍鯨監控有融合cmdb的自然優點，並且已經內存tcp監控、nginx、mysql等各組件監控，覆蓋了目前生產環境使用的開源工具；所以能夠用來實現業務監控、部分基礎監控；
• b.zabbix做爲基礎監控、網絡監控、硬件監控、vsphere監控等藍鯨監控不具有的；
• c.grafana+elk+alertmanager用來做爲可視化監控工具，利用其收斂的特色進行應用運行狀態方面的監控；

2.統一數據源 顧名思義，監控須要cmdb做爲統一的數據源，可是在多套系統共存的狀況下，就須要咱們有強大的API整合能力。此時須要在系統內部選擇一個具備良好整合能力的切入點，例如藍鯨的標準運維，實現不一樣平臺的API調用。

延伸：關於監控系統的3個客觀事實

1. 企業監控治理的目的是爲了及時發現問題、解決問題、直至預測問題，不是爲了整合監控系統；
2. 企業it架構如今很複雜，將來更復雜，難以經過1-2個監控產品就解決全部監控訴求；也不存在這樣的產品和廠商，必然各有所長；
3. 新的業務、系統和場景催生新的監控需求（如：容器），企業將來監控必定是多種監控產品並存，構建功能可持續成長的監控平臺勢在必行；

總結

本文從zabbix監控的現狀及cmdb的角色定位，闡述了兩者的關係，更引伸出了往後監控系統的目的及其可持續性的成長方式。固然運維並非脫離了這些就無法幹，而是在合適的階段選擇適當的工具，保證業務的可靠性。