![]()
（本文整理自民生銀行王斐在2023Zabbix中國峯會上的演講，點擊圖片查看視頻，更多內容可在B站“Zabbix中國”查看）
大家好，我是來自民生銀行的王斐，給大家分享民生銀行在Zabbix相關管理上的應用成果，還有Zabbix管理平臺的建設——潛望者的處理過程和效果。
通過打造自主加開源的一套監控體系，保障數據中心基礎關鍵設施的穩定運行，爲業務保駕護航。
2023年，中國民生銀行位居
英國《銀行家》“全球銀行1000強”第22位，
美國《財富》“世界500強企業”第329位；
中國銀行業協會“中國銀行業100強”第11位，
全國工商聯“中國民營企業500強”第54位。
民生銀行於1996年1月12日在北京成立，是中國第一家主要由民營企業發起設立的全國性股份制商業銀行，2000年、2009年先後在上海證券交易所和香港聯合交易所上市，現已發展成爲一家總資產逾7.5萬億元、淨資產逾6300億元，分支機構2700多家、員工逾6.6萬名，擁有商業銀行、金融租賃、基金管理、境外投行、銀行理財等金融牌照的銀行集團。
監控場景：服務於故障發現、應急協同、生產運營和監控管理這4大類場景。監控能力提供了監控指標體系、計算中心、故障分析中心和運營中心4個方面。支撐系統涵蓋Zabbix潛望者、交易監控、網絡監控、機房監控等等。其中Zabbix潛望者作爲基礎監控能力最重要的一個環節。
![]()
可靠的基礎才能決定上層良性的應用搭建。對於Zabbix潛望者和Zabbix本身提出了以下運營保障的要求。
第一，配置統一化管理，要求覆蓋整個數據中心的關鍵基礎設施。
第三，把配置信息作爲整體資產納入到長期的管理規劃中。
實施部分，因爲民生銀行存在有大量的新老混合運行的各種類型的信息系統，對這些信息系統標準的監控，就需要建設一套標準的監控實施規則，同時每年民生銀行規模以20%的速度增長，整個生產規模在持續的增長。也需要滿足生產的要求，把這些相關的監控實施還有部署交付給用戶，讓他們參與到整個建設環節裏。
監控可靠性建設。提出了需要提供一套監控值守保障的能力，同時對於監控出現的問題，實現故障的管理和跟蹤機制。監控異常引發告警風暴的時候，能做到異常控制以及止損。
數據場景建設。監控是整個數據中心的重要的數據輸出源頭，要求在故障發現環節提供更爲豐富的告警信息作爲支撐。應急協同的時候，需要提供更多的數據的關聯運營。
運營管理場景下，需要爲各個應用系統和大屏管理的運營，提供數據消費的支撐。最後自身的場景，也希望降低運營管理的費用。
![]()
問題管理，包括問題採控，以及異常止損等等一系列的能力。
Zabbix集羣管理，維護越來越龐大的 Zabbix集羣，把整個集羣作爲一個整體的監控任務的資源池，實現監控任務的及時調度。
數據管理，要滿足高吞吐以及數據增強的效果。底部依託於 Zabbix原生的能力，包含API事件，持續數據的持續消費，同時還要依賴於行裏的相應管理規則，以及相應的問題的處置流程。
第一、現在的監控規模非常龐大，導致所有的監控配置分散在不同的環境上，可能這些環境都不是相同的一個server和同一個版本。
第二、關於配置的信息，雖然已經有采集，但是這些信息是否足夠完整，是否可以在後續的過程中進行跟蹤，同時相關的知識經驗該如何記錄，面對如此龐大的這些信息，應該提供多大的維護力量。
![]()
建設的過程分爲4個週期。
第一個階段通過週期性的採集，把所有的server相關的配置集中獲取。
第二個階段當發現這些實時或者是定時的處理效率已經不足以滿足實際使用需求時，藉助於CDC的技術，實現了在數據庫層面把配置信息做彙總。
之後，又開始提出了參考數倉的建設，持續完善數據的消費和使用場景。
最後把監控配置作爲資產化的管理，進行整個生命週期和過程的完整記錄。
實時同步，採取什麼樣的方式？設計之前，有兩個構想。第一種方式，在Zabbix前置，同時API或者server前置進行攔截，發現到底有哪些自發現，可能還有API調用，看看當前有哪些配置的變化。第二種方式，在數據庫層面初始數據，捕獲數據變動。
比較這兩方案，認定是通過底層處理邏輯，對於整個Zabbix運行更爲可靠或更爲獨立的旁路方式去獲取配置，可靠性會更高。藉助 CDC消費數據庫的binlog，通過KAFKA推到ETL的清洗流裏，最終實現集中彙總，完成統一彙總。
之後建設相應的數據場景，參考數倉建設，完善數據層領域，把偏底層或者源頭這些原始數據進行擴展，豐富它的使用場景。
通過引入了兩種知識，一是關於運維，靜態的庫的配置，通過定時採集的方式彙總在配置中心。第二關於cmdb主題，通過實時推送最終彙總到整體配置中心。最後結合數據標籤和數據標記，配置實現了策略或者自動的維護能力。
數據過程，對於數據資產的管理，記錄它相應的過程。實施過程、異常過程以及發現過程，引入Zabbix渠道，流程渠道，把日常的變化、處理過程信息，寫入當前配置以及日誌變更庫裏，實現幾個應用場景，完成回顧，能夠看到記錄。
如果出現變更異常，能夠快速回退。涉及到外部的審計調閱，提供一個長期持續的記錄。
實施管理痛點與訴求
兩個痛點。首先爲了保障基礎設施建設可靠性，在設定指標層面,並不是通過單一的維度和單一種方式，Agent或者HTTP的方式，通常會設置多種探測角度去觀測被監管對象是否運行正常，監控指標就非常多。監控的維度和渠道也特別多，如何做到快速精準的完成實施工作，這是第一個痛點。第二在維護大量指標時，用戶通常也需要對於這些監控的閾值規則進行相應的調整。
對於監控的邏輯來講，它有一定的學習成本。用戶一般會人工溝通，或者登錄服務器，結合觀察的情況處理，這種溝通還有相應的學習成本，對於用戶來講負擔較重且學習時間較長，如何解決這些問題。
實施規則化建設歷程
![]()
1定義哪些策略，定義的是監控對象，行裏有大量的基礎設施，這些對象有不同的指標，需要維護一個更爲完善的規則。
2監控任務具體運行在哪些環境中，需要實現相應的調度的規則。
3客戶化如何簡化用戶維護監控的配置。結合這幾點規則，定義做了如下過程.
第一，指標模板，在原有的模板基礎之上，通過識別到的這些監控可能來自於不同的模板項，可能來自於不同的採集數據源頭，需要將多種模板或數據指標或者特殊監控項進行整合。
同時在日常的指標開發和維護過程中，像JMX或者數據庫中間件之類的，會發現他們有很多個共用的或者通用的指標，還有個性的指標，這種指標，通過做公用指標能減少開發成本，但是這對於實施部署來說會有些麻煩。如何通過這種組裝的方式，把特殊和通用形成一個標準的規則，最終實現成一個模板的 plus版本。
第二，在API這一側做相應的包裝和增強，通過提供限流角色校驗和多server的一個路由能力，保證API的高可用，同時也保證底層在維持server作爲的資源池，能夠實現最佳性能容量的均衡。
第三，環境選擇，如同上面所講，藉助整個大數據框架的模式，把server作爲具體的運行資源的一個節點，對於server上的環境做特殊的限定，來自於網絡域，或者來自於特殊的版本的要求，最終達到性能和容量的最優解。
最後，關於客戶服務，因爲Zabbix trigger提供非常自由靈活的方式，但是靈活對於用戶來講未必是最佳解。對錶達式進行精簡簡化，還有相應的一系列翻譯的手段實現它易讀易用性的。最後同時和行內的工具工單平臺，還有各種管理平臺進行集成，實現整個自動化的操作。模板實際上是通過在現在基礎模板加特殊監控項再加環境，共同維護相應的配置規則，通過定義對象的採集渠道、監控的維度，最後還有環境的一系列要求來定義的一個plus版本的模板規則。
API部分，通過定義認證中心，藉助網關，加入了渠道和身份信息的校驗，還有規則中心，把每一個對象級別的監控拆解成不同的模板，或者監控指標級的實施任務，最後交給路由層，分發給不同的具體需要承載的Zabbix server的環境。最後在API層又增加了一層API的代理，提供了相應的併發流量的管控，提供了升降級的機制。
客戶服務，這裏列了一個類似CPU的使用率的例子，識別出其中存在的宏變量。
還有自定義的變量顯示，這種變量最終在給用戶展示的時候就會變成一個客戶化的表單，實際上是屏蔽了具體的函數，還有具體使用的細節。最終形成了一個用戶可以填選的表單，節省了用戶對監控配置維護的學習的成本。
![]()
同樣也有兩個方面的痛點，在日常的配置維護，甚至還有工具運行的過程中，經常會遇到這些工具存在異常，不採集數據或者心跳異常等等，如何感知並且幫他們區分到底是一個小故障還是大問題，這是第一個痛點。
第二在遇到出現這種問題的時候，恢復故障很關鍵，但同時觸發這些異常的時候，也會導致有大量的無效告警和誤告警，對用戶也是極大的干擾。那麼如何定義防禦策略和應急策略，如何在兩者策略之中平衡，這是重點需要討論的。
可靠性認定需要通過多種渠道，內部外部共同來對工具運行，還有工具本身進行觀測和維護。對多種數據源進行比對，或內外部渠道進行探測，以及定義止損和恢復的策略。首先是關於配置可靠，配置實施永遠可能存在誤操作的風險，這定義瞭如何與CMDB進行綁定，要求與CMDB的內容或者監控對象達到一致。
第二是內部，依賴於Zabbix 自發現的能力，實現了這些內部的指標庫等等對象的細粒度的發現。
採集可靠，定義了需要涵蓋點對於點和麪上的問題都需要發現，包含通過no data這些對於單個指標採集結果的檢查，還有延遲的情況進行判定，同時也增加了自監控，還有流量的統計從而發現更粗粒度層面上數據的異常。
數據鏈路是在上送的過程中給上層的應用提供支撐信息最重要的一個通道，這裏提供了相應的心跳檢測，還有故障的遷移，同時在建設的時候也設定了多活的鏈路，保證鏈路多活可靠。
最後關於數據補發，提供了數據補發以及告警風暴壓降無效告警丟棄等一系列的策略，保障出現異常的時候及時止損。
第一，出了問題之後，實際上需要有一套非常完整的問題管理的機制。實際上參考ITIL相應的問題建設思路，定義了問題感知問題分類止損，還有相應的一系列工具箱。
通過實時的定時的巡檢採集，還有實時的異常告警推送，把相應的問題推送給問題管理中心，通過對問題進行創建分發標記，以及主動防禦策略的相應的處罰，實現問題的分類與治理。
同時也提供了相應的一組運維保障的工具箱，通過大盤日常的可視以及告警壓降等等一系列策略，保證故障不會突破整個監控管理的範圍和體系框架。運營大盤，這是運維最常見和需要的，它把日常所需的數據投射在這相應的視圖裏，比較關注的是對日常監控覆蓋的差異比對。還有disabled/ not supported等一系列的狀態，相應的差異的變化，幫助在每天的巡檢提供一個主動的窗口，方便運維人員及時發現異常。
第二，告警壓降，當告警風暴出現的時候，尤其是大量的之前經常出現像nodata告警風暴或者是異常，或者模板變更，大量的無關的或者說需要待觀測的告警，需要定義一個在壓制策略引擎裏一系列的規則，通過對特定的時間窗口的檢測，還有數量累積的檢測，具體哪些指標去判定，對現有的規則進行檢查，最後它會命中相應的一系列的壓制的動作，對原始告警的屏蔽或壓制。
第三，同時持續監聽現在的恢復的過程，最後可能還會派生出來相應的新的告警，保障告警迅速得到收斂，同時也能及時告知給相應的運維人員，還有保障人員。
那麼配置遷移，實際上是提供了一套可靠的方案，可能大家也看到個p0級別的故障，他們可能基本上來自於原地升級等等一系列的這些問題，這種原地升級在數據中心層面來看，是有一定的風險的。
我們建設了一套相應的包括遷移也好，或者計劃內或計劃外的遷移也好，能幫助把這些監控的配置任務，從一個server或一個proxy遷移到另一個環境上。
這裏分別引入這些過程，包括故障的評估，配置，以及完成了配置的集中收集，可以通過API方式給別的 server執行相應的任務，還有創建相應的主機，分析運行大盤，做事後的評估，觀測故障是否得以恢復，以及遷移後是否運行穩定。最後整個監控任務再切回原有的環境，保障監控的連續性，避免單點的存在。
![]()
第一，輸出了大量的告警，輸出了一組相應的許多規則，同時還支撐很多數據的分享，告警之後，用戶常問什麼原因甚至是不是有更多的詳情支撐我去分析。
第二，有關閾值，當不需要關注時，如何優化閾值，怎麼預優化才能達到最優的一個平衡解，或者如何幫助他們去減少閾值優化層面的困擾。
第三，需要很多持續的數據支撐用戶在其他的大盤等等一系列的場景監控的觀測，對這些數據層面面臨的訴求，數據場景是明確的價值，希望提供一組易於分析的數據，通過定義的規範，還有接口，幫助大家快速消費或者捕獲所急需的數據，包含告警閾值，還有時序。
第一個案例，講到對於故障這一方面輸出告警。捕獲相應的故障快照，這裏提供了類似的，像數據庫或者操作系統或者應用，爲了提高也是避免統計這種數據通常需要耗費比較長的時間，把它做成異步的方式。自動化的信息採集，通過訪問Ansible，嘗試調用採集的腳本，通過告警觸發，實現了對上述的關鍵信息的採集和推送的能力。
第二關於閾值推薦，閾值推薦因爲已經建設了一套相應的告警，還有一套分析的中心的能力，等於說是把這些關於預測還有動態基線的能力，反哺於相應的告警，閾值優化的場景中，藉助了計算中心裏的兩大異常，還有動態基線和異常點檢測的兩種模型，補充相應的度量因子，最後給出相應的最佳推薦的閾值。
舉個例子，如何做到閾值推薦，首先獲取了所有的歷史趨勢數據，對歷史趨勢的數據排除一系列的離羣點、異常點的干擾。
接下來計算相應的數據分佈基帶的情況，再補充相應的度量因子，度量因子來自於很多都是配置層面的數據，交易類的，或者日間類的，還有夜間跑批類的，通過給出對於基帶相應的係數的增強，擴寬它相應的容忍的一個區間，最終給出一個估算的閾值，降低整個用戶的使用成本。
最後關於持續建設，也是使用了規範的數據協議，建設了一套自己的TSDB持續集羣庫，通過網關，還有讀寫分離這一套邏輯，實現寫入層還有查詢還有匯聚層的獨立。最後有一組相應的一個TSDB的集羣和分片庫，實際保證這些數據在不通過訪問Zabbix的情況下能快速交付給用戶。
![]()
在做整個監控的過程中，實際上認爲整個監控體系，並不是一個單獨的系統，而是一個系統工程性。每一個組件不能作爲整個系統的一個銀蛋來去處理，需要引入這一堆系統，達到整體的一個平衡。作爲配置管理系統，幫助整個管理團隊實現管理和改進的良性循環。
第二技術層面，又向數據中心上層提供了一個完美的數據底座。
第三關於數據中心的各方面能力的程度，相互支撐，相互演進
。
最後感謝整個Zabbix社區和宏時數據給予這一次機會，希望在未來，共同成長。
延伸閱讀
![]()
本文分享自微信公衆號 - Zabbix開源社區（china_zabbix）。
如有侵權，請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”，歡迎正在閱讀的你也加入，一起分享。
