銀行Zabbix監(jiān)控架構部署最佳實踐

1、 銀行 Zabbix 監(jiān)控架構部署最佳實踐 【摘要】某銀行 Zabbix 系統(tǒng)經(jīng)過兩年多發(fā)展，從小范圍試用逐步擴展到涵蓋硬件、應用、平臺、業(yè)務等更大范圍的場景，架構上從單數(shù)據(jù)中心進化為三中心的分布式部署。除了逐漸替代舊的監(jiān)控系統(tǒng)，越來越多的第三方系統(tǒng)也開始對接起了 Zabbix，通過 API 或者數(shù)據(jù)庫抽數(shù)的方式，使用海量的運維監(jiān)控數(shù)據(jù)實現(xiàn)智能運維的工作模式。本文從架構部署、監(jiān)控維度、自動化方案、運營管理層面，分享 Zabbix 在銀行應用的實踐經(jīng)驗，希望對廣大同行有所幫助。Zabbix 平臺概述平臺介紹Zabbix 是一個基于 Web 界面提供分布式系統(tǒng)監(jiān)視及網(wǎng)絡監(jiān)視功能的企業(yè)級開源解決方案

2、。它能監(jiān)視各種網(wǎng)絡參數(shù)，保證服務器系統(tǒng)的安全運營，并提供靈活的通知機制以讓系統(tǒng)管理員快速定位、解決存在的各種問題，借助Zabbix 可很輕松地減輕運維人員繁重的服務器管理任務，保證業(yè)務系統(tǒng)持續(xù)運行。其后端使用數(shù)據(jù)庫存儲監(jiān)控配置和歷史數(shù)據(jù)，可以非常方便地對接數(shù)據(jù)分析、報表定制等渠道，在前端開放了豐富的 RESTful API 供第三方平臺調用，整體架構在當下的 DevOps 的趨勢下顯得非常亮眼。選型過程我們于 2017 年開始接觸 Zabbix，之前運維內主要使用的監(jiān)控系統(tǒng)是 Nagios，但 Nagios 的頁面展示、監(jiān)控配置、自動化等各項功能對基礎架構的運維人員來說不是特別友好，而風頭正勁

3、的 Zabbix 正好引起了我們的注意?；A架構的運維工作中，需要面對各種各樣的監(jiān)控場景，例如 PC 服務器的故障燈巡檢、存儲設備的陣列健康判斷、小型機 LPAR 的資源監(jiān)控、操作系統(tǒng)的多路徑檢查，等等。而 Zabbix 內置提供了 SNMP、IMPI、SSH、Agent 等多種監(jiān)控途徑，在系統(tǒng)架構的各層場景下都能很好的適配，其中 Agent 還支持自定義工具，總體的表現(xiàn)非常靈活。在網(wǎng)頁前端管理上，Zabbix 可以滿足各個粒度的監(jiān)控管理，從整個集群到單獨一個監(jiān)控項都能夠進行細分管控，自定義 dashboard 和歷史數(shù)據(jù)可視化功能也極大地方便運維人員對監(jiān)控數(shù)據(jù)的審查。綜合以上的考慮因素，行內

4、選擇了 Zabbix 作為一個新的監(jiān)控平臺試點，從基礎資源的監(jiān)控出發(fā)，首先將大部分存儲、主機和操作系統(tǒng)接管到 Zabbix。使用現(xiàn)狀2017 年底在基礎架構范圍內試行的 Zabbix 系統(tǒng)，從 3.2 版本開始逐步演進到現(xiàn)在的 4.4 版本，其中經(jīng)歷了各項監(jiān)控系統(tǒng)的里程碑事件。目前的 Zabbix 系統(tǒng)也由原先的小范圍試用，逐步擴展到涵蓋硬件、應用、平臺、業(yè)務等更大范圍的場景，架構上也從單數(shù)據(jù)中心進化為三中心的分布式部署。除了逐漸替代舊的監(jiān)控系統(tǒng)，越來越多的第三方系統(tǒng)也開始對接起了 Zabbix，例如自動化運維平臺、持續(xù)發(fā)布平臺、運維可視化平臺等，通過 API 或者數(shù)據(jù)庫抽數(shù)的方式，使用海量的

5、運維監(jiān)控數(shù)據(jù)實現(xiàn)智能運維的工作模式。在編寫此文前不久，我們也順利完成應用系統(tǒng)監(jiān)控遷移到 Zabbix 平臺，作為一名全程參與 Zabbix 系統(tǒng)推廣實施和自動化開發(fā)的運維人員，非常榮幸能夠見證我們運維力量的茁壯成長，在此，本人也將從架構部署、監(jiān)控維度、自動化方案、運營管理層面，分享我們 Zabbix 系統(tǒng)發(fā)展壯大的經(jīng)驗。硬件監(jiān)控數(shù)據(jù)中心的運維管理中，系統(tǒng)架構的縱向深度是非常陡長的，包括最基礎的硬件設備也需要運維人員費盡心思地去巡檢排查，但隨著數(shù)據(jù)中心的設備數(shù)量呈爆發(fā)式增長，人工巡檢已不能滿足當下監(jiān)控實時性、可靠性的要求。對于這種低層級的監(jiān)控，Zabbix 的多維度特性就非常好的解決了這個問題，

6、其內置的 SNMP/IPMI 協(xié)議能夠輕松對接相關硬件設備的帶外監(jiān)控。目前我們使用 SNMP Agent 的被動方式定期巡檢硬件設備的基礎指標，例如故障燈信號、電源功率、內存信息、磁盤陣列等，代替人工巡檢的方式來實現(xiàn)異常捕獲，并對數(shù)據(jù)中心內的所有設備做到硬件信息采集，定時更新至 CMDB。例如以下為部分華為 RH2288 V3 IBMC 監(jiān)控模板中自動發(fā)現(xiàn)的配置：Zabbix 配置硬件監(jiān)控的操作過程也非常便捷，大部分都是在網(wǎng)頁界面配置，只需要定義好 SNMP Agent/Trap 的接口或 IPMI 傳感器目標端口后即可靈活定義監(jiān)控項。對于 IPMI 監(jiān)控的配置，主要是將傳感器的名稱填入即可，

7、目前我們對 IPMI 的帶外監(jiān)控使用的相對較少，主要是部分浪潮 PC 服務器在使用，對 IPMI 更多地考慮應用于在如 VMware vSphere 的 DPM 等帶外管理上。在硬件監(jiān)控選擇監(jiān)控協(xié)議時，保持的一項原則是：能用 SNMP 就不用其他，能用 SNMPv3 就不用 SNMPv2 。因為 SNMP 在 Zabbix 中可以非常靈活的實現(xiàn)自動發(fā)現(xiàn)，而 SNMPv3 可以提供更健壯的認證機制，因為在開放硬件監(jiān)控的同時也必須考量網(wǎng)絡安全的風險。對單個 SNMPv3 的監(jiān)控項配置如下，大部分參數(shù)都提供了輸入窗口：對于上述提及的 SNMP 配置自動發(fā)現(xiàn)的靈活性，這也是依賴于 SNMP 設計的原理

8、，借助樹結構的索引方式，可以根據(jù) index 字段枚舉現(xiàn)有元素的數(shù)量，然后再根據(jù)數(shù)量長度來遍歷下一層元素。對于這種遍歷，Zabbix 自身提供了友好的 discovery#SNMPVALUE,OID 函數(shù)來完成，無縫對接到內部通用的自動發(fā)現(xiàn)數(shù)據(jù)結構。整個 SNMP 自動發(fā)現(xiàn)的機制原理如下由于我們 Zabbix 的起步試點是從基礎設施運維開始，加上 Zabbix 對 SNMP/IPMI 協(xié)議配置的操作非常方便，所以經(jīng)常可以根據(jù)廠家提供的 mib 文件及 mib 文檔說明即可篩選出需要自定義的監(jiān)控，這樣既可以通過減少采集來降低管理系統(tǒng)的繁忙度，又能優(yōu)化監(jiān)控質量。例如以下為根據(jù) Lenovo XCC

9、 帶外管理系統(tǒng)的 mib 說明（http:/www.circitor.fr/Mibs/Html/L/LENOVO-XCC-MIB.php）來自定義配置的 ThinkSystem SR650 的 SNMPv3 監(jiān)控使用效果：上圖中的電源、陣列、磁盤等均是通過自動發(fā)現(xiàn)的規(guī)則來生成的，這對擁有不同陣列卡數(shù)量、網(wǎng)卡數(shù)量、路數(shù)等的 XCC 帶外服務器，都可以使用同一個模板，設備變化完全交給 Zabbix 維護。另外，分享一個定制 SNMP 監(jiān)控過程中的經(jīng)驗，首先在 MIB 文件中收集所有需要監(jiān)控的指標，對篩選的指標做分組，找到每個組的最高父級索引的 OID，然后在 Zabbix Proxy 上使用 sn

10、mpwalk 遍歷這個 OID 找到所有 OID 內容，區(qū)分出 Index 和 Detail 后，劃分常規(guī)監(jiān)控和自動發(fā)現(xiàn)監(jiān)控，最后使用 snmpget 來逐個獲取 OID 的值確定對應 Zabbix 上的數(shù)值類型。需要特別注意，snmpwalk 是遍歷，并不需要 OID 的完整值，而 snmpget 則是根據(jù)一個完整的 OID 來檢索，對應于 Zabbix 則是 snmpwalk 類似自動發(fā)現(xiàn)，snmpget 類似常規(guī)監(jiān)控項。存儲監(jiān)控在數(shù)據(jù)中心中，存儲設備是非常核心且關鍵的基礎設施，任何一個相關告警都會讓運維人員警覺。在推進 Zabbix 的存儲監(jiān)控的過程中，體會到一個非常棘手的困難點，即存儲

11、不單單是硬件設備，SNMP 的協(xié)議不能獲取到帶內的性能信息，但也不像主流操作系統(tǒng)那樣可以安裝 Zabbix Agent 來做數(shù)據(jù)采集。對于這種問題的處理，我們積累的經(jīng)驗是，首選使用 RESTful 等外部接口來獲取監(jiān)控數(shù)據(jù)，在不支持此條件的情況下，在 Zabbix Proxy 服務器上通過自定義監(jiān)控封裝廠家推薦工具或方法來監(jiān)控。Zabbix Agent 支持運維人員自定義監(jiān)控，將執(zhí)行命令封裝成一個 Zabbix Item Key 來供 Zabbix 調用，也支持額外的安全策略，例如 AllowRoot 可以設置是否允許 root 來執(zhí)行 agent，UnsafeUserParameters 參

12、數(shù)能夠過濾特殊符號注入。我們對自定義配置的標準，以 RedHat 基線為例，在 /etc/zabbix/zabbix_agentd.d 目錄一個監(jiān)控類為一份 conf 文件的形式保存，命名形式為 ClassA_ClassB_Detail.conf，并且定義的執(zhí)行文件均放置于 /usr/local/zbxexec/ClassA/ClassB/xxxx.xx。對于自定義監(jiān)控項的方法，能夠便捷地對接各個存儲廠家的產(chǎn)品監(jiān)控方式，將廠家建議的監(jiān)控命令封裝為 Zabbix 的一個監(jiān)控項。這類被封裝的方法主要是 CLI、RESTful 和 SSH，例如以下我們目前對各產(chǎn)品使用的監(jiān)控方式：除了跟廠家溝通對接

13、Zabbix 外，其實也可以借助開源生態(tài)和 Zabbix 的合作推廣，也有很多企業(yè)與我們一樣會分享 Zabbix 的經(jīng)驗、模板、工具到 Zabbix Share，可以斟酌篩選后使用。同時，Zabbix 也一直努力與其他廠家共同合作，共同推出每個廠家在 Zabbix 上的官方監(jiān)控模板，例如 DELL EMC 在 Zabbix 中推出的各個產(chǎn)品的監(jiān)控模板（/integrations/emc）。通過上述的監(jiān)控方式，Zabbix 對生產(chǎn)環(huán)境存儲設備的監(jiān)控效果讓運維人員感到比較滿意，agentless 的架構避免對重要設備的侵入，同時相關的存儲告警也能夠及時觸發(fā)，并幫助存儲管理人員迅速發(fā)現(xiàn)問題、定位原因

14、。主機監(jiān)控我們目前的主機監(jiān)控主要包含了 Power 的小型機和 x86 的 ESXi，這類對象有一非常明顯的特點，就是數(shù)量和信息不固定。一臺小型機可能需要為新部署的數(shù)據(jù)庫劃分物理分區(qū)或虛擬分區(qū)，亦或者要調整某個數(shù)據(jù)庫的 CPU 分配；一個 vSphere 集群可能會擴容 ESXi 主機數(shù)量或資源，亦或新建一個集群。在這種多變的的環(huán)境里，首先考慮的是使用 Zabbix 的自動發(fā)現(xiàn)來適配，并且此場景有一個非常明顯的相似特性，就是需要一個主控端來管理整個主機資源池。因此，我們對主機的監(jiān)控常常采用的原則是，通過監(jiān)控主控端來自動發(fā)現(xiàn)主機，讓被發(fā)現(xiàn)的主機自動使用對應模板。上述的監(jiān)控流程主要是依賴 Zabb

15、ix 的自動注冊主機來實現(xiàn)，不同于硬件監(jiān)控中提及的自動注冊監(jiān)控項，這里的自動注冊會直接根據(jù)主控端獲取的資源列表，自動注冊一個待監(jiān)控的主機，相關的主機配置包括主機名、可見名稱、agent 接口等都會繼承主控，然后會為每個主機都綁定一個預先配置的監(jiān)控模板。如果主控端發(fā)現(xiàn)某一個主機不在上一次收集的資源列表中，會在超過資源保留策略時間后，自動刪除該主機。例如自動發(fā)現(xiàn)的 ESXi 主機：操作系統(tǒng)監(jiān)控操作系統(tǒng)的監(jiān)控是非常龐大的，除了操作系統(tǒng)種類多，每個操作系統(tǒng)內的監(jiān)控項數(shù)量也是覆蓋面廣，再乘上物理機、虛擬機的數(shù)量，整個監(jiān)控面積會非常之大。另外，將每一臺服務器納管至 Zabbix 中的操作也變得異常繁瑣。對

16、此，我們保持的思路是，通過自動化手段讓服務器自動上報到 Zabbix，優(yōu)化模板以減少重復監(jiān)控，定制觸發(fā)器的依賴關系。操作系統(tǒng)的監(jiān)控都是使用 Zabbix Agent 方案來實現(xiàn)的，Zabbix 也推出了各種操作系統(tǒng)的 agent，不需要編譯就能直接運行。對此，我們的所有虛擬機基線、小型機備份、物理機 Ansible 部署腳本里，都會事先準備好對應操作系統(tǒng)的 Agent 安裝和配置。其中，推薦使用被動方式，并且主要修改 agent 配置的如下內容：# .# 眾多 Zabbix Proxy 中的兩個ServerActive = ,# 其中 /24 為當前機房的 Zabbix Proxy 節(jié)點網(wǎng)段S

17、erver = ,/24# Hostname 是這臺服務器的管理 IPHostname = 這種配置主要是方便于 agent 在多個 Proxy 中平移，在故障恢復、Zabbix 升級等場景下，可以非常便利的保證 agent 的持續(xù)有效。另外將本地回環(huán)地址也寫入 Server 中，方便以后需要在此操作系統(tǒng)中通過 agent 調用本地腳本。Hostname 在被動模式下并不是必須的，配置管理 IP 可以保證主動模式和配置管理的便利。以上僅是 agent 的配置標準，如果需要自動上報至 Zabbix，還需要其他步驟。目前我們對于物理機和虛擬機的 x86 操作系統(tǒng)實現(xiàn)了自動上報主機的機制，每天上午八

18、點會做一次上報，然后對新增的主機自動加入維護模式，避免部署階段中各種不關鍵的異常帶來告警風暴，直至系統(tǒng)穩(wěn)定才會退出維護模式。在物理機的部署中，我們除了一套完善的自動化 RAID 配置、PXE 安裝系統(tǒng)外，還有對操作系統(tǒng)配置基線的 Ansible 方案，每個操作系統(tǒng)的 roles 里，都有一個 Install Zabbix Agent And Report 的 task，這樣通過實現(xiàn)配置的好的 vars 即可將此主機以標準命名添加到 Zabbix 中。而對于數(shù)量龐大的虛擬機，我們編寫了一套 Python 腳本，掃描各個機房 vCenter 中的虛擬機獲取到每日的虛擬機差異，再使用其在 CMDB

19、的屬性、vCenter 上的備注，來填充業(yè)務系統(tǒng)、應用集群、服務器描述等，最后注冊到 Zabbix。這種機制除了極大程度地解放運維人員對新系統(tǒng)的主機監(jiān)控注冊外，還可以在腳本中指定納管策略來實現(xiàn)各種額外的預期目標，列舉以下幾點：根據(jù)網(wǎng)段信息，將同機房的服務器接口對接同機房的 Proxy，避免機房流量交叉。通過判斷當前 Zabbix 各個 Proxy 的 vps，將新增主機接入到低負載的 Proxy。將 CMDB 中現(xiàn)有的信息填入到被注冊主機的標簽和資產(chǎn)信息中。其架構上的拓撲簡化如下：在這套自動化機制下，極大地減輕了運維人員對監(jiān)控配置的厭惡，也加到了對我們 CMDB 的關聯(lián)，為以后的工單系統(tǒng)打下架

20、構基礎。但是，我們對監(jiān)控系統(tǒng)的分析和探索沒有僅僅止步于此，考慮到操作系統(tǒng)監(jiān)控中觸發(fā)器帶來的大量告警，我們也研究了一些額外的措施，避免太寬泛的告警涌現(xiàn)。首先，將模板細分為各個類別作為基類的 template，然后根據(jù)應用場景來指定上層的模板由哪些基類組合，避免太多的定制模板中近似功能的監(jiān)控帶來重復監(jiān)控。然后，對每個模板中的觸發(fā)器指定嚴格的依賴關系，避免告警的連帶觸發(fā)導致風暴。例如 Linux 系統(tǒng)的分區(qū)容量監(jiān)控觸發(fā)器，我們制定了幾個水位線之間的依賴：數(shù)據(jù)庫監(jiān)控數(shù)據(jù)庫監(jiān)控也是一條每個運維人員心中緊繃的弦，除了普通的表空間使用、會話數(shù)量、SGA 使用、ASM 使用、緩存命中、刷臟頻率等，還有宕機、切

21、換等狀態(tài)檢查。加上我們近幾年分布式數(shù)據(jù)庫落地，及嘗試國產(chǎn)數(shù)據(jù)庫的背景下，越來越多的數(shù)據(jù)庫產(chǎn)品需要對接至 Zabbix。目前我們對數(shù)據(jù)庫的監(jiān)控，結合了多種監(jiān)控思路，制定了各種數(shù)據(jù)庫產(chǎn)品的監(jiān)控指標，在性能數(shù)據(jù)追溯與故障告警的場景下都體現(xiàn)出非常優(yōu)秀的表現(xiàn)。在金融行業(yè)的傳統(tǒng)架構中，Oracle 數(shù)據(jù)庫往往是不可或缺的一個基座，我們通過模板定制，提供了 Sinlge-Instance、RAC、DG、F5 等多種架構的模板，覆蓋了大部分 Oracle DBA 關心的監(jiān)控項。在 Zabbix 中專門使用一臺高性能的 Proxy，通過自定義監(jiān)控的方式來執(zhí)行 Oracle 監(jiān)控腳本。除了應急的故障告警外，現(xiàn)在

22、Zabbix 也成為了 DBA 分析數(shù)據(jù)庫性能的工具，對比歷史數(shù)據(jù)排查數(shù)據(jù)庫問題，這也依賴于 Zabbix 保存的大量監(jiān)控信息。如下為其中有給數(shù)據(jù)庫的性能與 RAC 部分監(jiān)控指標：除了傳統(tǒng)架構的數(shù)據(jù)庫，我們對其他數(shù)據(jù)庫產(chǎn)品也提供了全面的監(jiān)控，并且對此監(jiān)控采用了主控服務（RootService）的思路，將數(shù)據(jù)庫更自動的納入監(jiān)控中。這種方法的優(yōu)點是可以完美展現(xiàn) Zabbix 自動注冊主機的機制，將數(shù)據(jù)庫添加到監(jiān)控中，并使用自動注冊監(jiān)控原型的方式來識別數(shù)據(jù)庫開啟了哪些需要監(jiān)控的細節(jié)。目前我們編寫了 OceanBase、MySQL、DRDS 等數(shù)據(jù)庫產(chǎn)品的監(jiān)控腳本，在 Zabbix 中以全新的數(shù)據(jù)庫監(jiān)

23、控架構運行自管理。此框架的工作流程如下。以 MySQL 的監(jiān)控為例作為詳細描述整個過程，參見下圖。在 MySQL 實例的配置 zbx_mysql.py 文件中，新增一個 testenv_zabbix 的數(shù)據(jù)庫實例，這份文件是通過 acl 設置僅為 zabbix 用戶讀取的。當作為 MySQL RootService 的主機執(zhí)行自動發(fā)現(xiàn)主機的監(jiān)控時，會將新增的實例配置生成 Zabbix 自動發(fā)現(xiàn)的 json 規(guī)則，根據(jù)配置信息創(chuàng)建監(jiān)控實例，并附加使用 MySQL 基礎模板。在 MySQL 基礎模板中，配置了一系列特殊的監(jiān)控自動發(fā)現(xiàn)規(guī)則，例如 Discovery MySQL Replication

24、 Enable 會對發(fā)現(xiàn)的實例執(zhí)行 show slave status 命令，這里仍會調用 MySQL RootService 的腳本，如果發(fā)現(xiàn)目標實例開啟了主從，則會在自動發(fā)現(xiàn)返回 josn 中包含一個 #REPLICATION: enabled 的字段，從而觸發(fā)主從復制的監(jiān)控項生效。創(chuàng)建一臺邏輯主機作為主控服務，以鏈式發(fā)散的傳播模式自動注冊主機，然后根據(jù)模板內的自動發(fā)現(xiàn)判斷是否需要附加額外的監(jiān)控配置，這種在我們創(chuàng)新使用的監(jiān)控方法，取到了非常好的成效，讓監(jiān)控系統(tǒng)變得更加智能，也不用像某些數(shù)據(jù)庫監(jiān)控還需要將連接的用戶與密碼寫入到 Zabbix 的宏，而只要保證讀取的配置文件在文件系統(tǒng)的 ACL

25、 上是最小權限即可，提高了數(shù)據(jù)庫的訪問安全。另外一點，現(xiàn)在很多的分布式數(shù)據(jù)庫也是采用 控制+計算+存儲 的架構，例如 TiDB 的 PD 負責元數(shù)據(jù)管理、DB 負責 SQL 解析與計算、KV 負責底層鍵值對存儲，面對眾多的分區(qū)也好，副本也罷，最有效的監(jiān)控方式就是直接對接其管控部件，將 Zabbix 主控服務的起點映射至數(shù)據(jù)庫集群的管控上，不斷順著架構分層，將各個組件之間的監(jiān)控項固化成自動發(fā)現(xiàn)規(guī)則，實現(xiàn)精準有效的監(jiān)控覆蓋。以目前我們的 OceanBase 分布式數(shù)據(jù)庫監(jiān)控為例，以下從 OB RootService 自動發(fā)散出 OB Zone、OB Tenant、OB Server、OB Part

26、ition 等監(jiān)控細節(jié)。除了監(jiān)控架構的不斷靈活，我們也在考慮更加深入的監(jiān)控效果，對于數(shù)據(jù)庫的監(jiān)控排查，DBA 更多地希望所有相關的告警都是同一個時間點的，這樣更加便于橫向參照。根據(jù)這個出發(fā)點，運維人員利用“監(jiān)控快照”的思想，將監(jiān)控項盡可能多地集中在同一個時間點上，這樣也能極大減少監(jiān)控數(shù)據(jù)庫時頻繁交互帶來的性能損耗。實現(xiàn)這一點，主要借助于自定義腳本規(guī)范和 Zabbix 監(jiān)控項中的相關項目依賴特性。以巨杉數(shù)據(jù)庫的監(jiān)控為例，也正好通過其動作具有一定的性能消耗來說明減少交互頻率的重要性。這臺測試環(huán)境的數(shù)據(jù)庫集群的 Coord 主機，總共有 56 個監(jiān)控項，如果每一個監(jiān)控項都需要單獨連接到其中一個協(xié)調節(jié)

27、點并做快照獲取對應的監(jiān)控指標，那么集群對于這些頻繁的快照操作會付出非常大的性能成本。但實際上，這里真實的監(jiān)控項只有 3 個，也就是截圖中的 multi_snapshot_SDBSNAP* 開頭的，其余的都是由這三個監(jiān)控項派生出來的，也就表示交互次數(shù)可以從 56 次縮減到 3 次。我們對這種方案的實施，是通過自定義腳本或 LDD macros 來生成一個包含各個子監(jiān)控項的 JSON，并設置為不保存歷史記錄，這一點非常重要，因為子監(jiān)控項的生成是在父監(jiān)控項轉儲前計算得到的，保存大量被拆分的冗余 JSON 字符串也沒有實際意義。在子監(jiān)控項的生成動作中，主要使用了 Zabbix 監(jiān)控項的預處理操作，使用

28、 JSONPath 將對應的 K/V 抽出，再通過倍數(shù)/每秒變更/正則等方式獲取到最終的子監(jiān)控值。雖然預處理會消耗 Zabbix 的 CPU，但是實測調大 StartPreprocessors 參數(shù)后，CPU 沒有明顯的攀升，而且 Zabbix Proxy 是分布式可擴展的，這種瓶頸也非常容易通過擴容來解決。綜合評估下來，這種方案帶來的回報是很可觀的，當出現(xiàn)數(shù)據(jù)庫問題時，或許更多的 DBA 希望回溯監(jiān)控歷史，能夠看到的是這樣同一時間平面上的各項指標：應用監(jiān)控當監(jiān)控的考慮維度上升至應用組件時，我們依舊堅持使用自動化的方式去面對眼花繚亂的監(jiān)控需求，思考如何讓應用的監(jiān)控更加富有生命力，同時也分析了在

29、過去使用 Nagios 進行應用監(jiān)控時遇到的痛點，最終，編寫一個框架級別的工具，接管應用的監(jiān)控生命周期。這個框架在我們內部稱為 zbx_app，通過一個文件服務器和應用監(jiān)控的準則來完成運行，可以自動完成自定義腳本拉取、版本迭代、自動注冊監(jiān)控項等，運維人員僅需要編寫一份應用監(jiān)控的聲明文件，其他工作完全交由框架執(zhí)行。此框架的內部原理，主要是通過 Zabbix 發(fā)送來特定的監(jiān)控項和自動發(fā)現(xiàn)作為更新配置與自動檢查基礎環(huán)境的信號，如果發(fā)現(xiàn)文件服務器的相關模塊版本更新則會主動拉取文件，從而實現(xiàn)自管理的操作。這個接收特定信號并管理自身的環(huán)境的模塊我們內部稱之為基類，所有的模塊監(jiān)控會有一個自動發(fā)現(xiàn)規(guī)則與基類交

30、互，如果基類聲明文件里包含了請求的自動發(fā)現(xiàn)模塊，那么就會應答，讓 Zabbix 感知并利用返回的結果來生成此模塊的監(jiān)控項。對應的監(jiān)控項生成后，每個監(jiān)控項會使用快照的方法去捕獲一次監(jiān)控目標，然后再由監(jiān)控相關項來拆分同一時間點上的各個子項。在這個調用的階段，也是與基類交互的，只不過基類會根據(jù)其模塊名來調用同步過來的模塊方法的固定接口，這些接口是編寫這類模塊的開發(fā)準則，目的是為了保證基類能夠順利調用并解析。把考慮對象限制在一臺主機上，簡化這個流程，可以有如下的時間線，由上至下是時間前進的方向。_Zabbix Proxy 會調用 Discovery APP 自動發(fā)現(xiàn)，觸發(fā)主機初始化一次當前的 zbxa

31、pp 基類，基類收到信號后也會掃描環(huán)境，主要是收集各目錄下的聲明文件（lps.cfg），并根據(jù)聲明文件做一次基礎環(huán)境配置拉取，然后返回 Zabbix Proxy 相關信息。Zabbix Proxy 收到了基類生效，其他模塊的自動發(fā)現(xiàn)也會緊隨著對主機做一次探測，發(fā)送各自的自動發(fā)現(xiàn)信號?；惏l(fā)現(xiàn)聲明文件里存在 redis 的模塊聲明，那么會把內部信息整合為自動發(fā)現(xiàn)返回結構體，Zabbix Proxy 感知后會生成對應的監(jiān)控項。Redis 模塊持續(xù)發(fā)送監(jiān)控快照請求至基類，基類收到后會調用已經(jīng)從 HTTPFileServer 上拉取下來的 redis 模塊來執(zhí)行監(jiān)控請求，并返回結果集。如果過程中應用維

32、護人員將 url 模塊的監(jiān)控需求寫入聲明文件，下一次接收到 Discovery APP 信號時，基類會發(fā)現(xiàn)新增聲明，迅速前往 HTTPFileServer 拉取指定版本的 url 監(jiān)控模塊。后續(xù) URL 的監(jiān)控也會與 Redis 一樣持續(xù)生效，直至聲明文件刪除或注釋了此模塊。如果過程中自動化開發(fā)人員對版本庫里的 redis 模塊更新了代碼，基類也會在下一次接收到 Discovery APP 信號后對比 MD5 列別發(fā)現(xiàn)版本更新，從而拉取替換為最新版本。使用自管理的基類實現(xiàn)了應用監(jiān)控的閉環(huán)納管，監(jiān)控的操作上，細分了自動化開發(fā)人員開發(fā)模塊職能，也給應用維護人員更多的自由度去聲明自己需要的應用監(jiān)控。

33、而且，對基類的動作也納入一個監(jiān)控項，能保證基類自己的穩(wěn)定，不至于罷工后無人知曉。通過這個框架，我們將應用監(jiān)控從上一代的 Nagios 系統(tǒng)成功地遷移到了 Zabbix 系統(tǒng)，并且維護成本變得更低，運行模式更加穩(wěn)定。業(yè)務監(jiān)控當有了強大的應用監(jiān)控框架支撐后，運維人員也開始更往上地關注更上層的業(yè)務監(jiān)控，業(yè)務的特征也是整套架構運行穩(wěn)定的最直白表現(xiàn)。Zabbix 提供了數(shù)據(jù)庫的監(jiān)控，直接在網(wǎng)頁界面直接編寫 SQL 語句，由 Proxy/Server 通過 unixodbc 加載對應驅動去連接目標數(shù)據(jù)庫，最終返回執(zhí)行結果。目前我們利用這種方法，對業(yè)務的狀態(tài)信息、交易成功率、設備報活、跑批等進行數(shù)據(jù)庫查詢，

34、再通過 Zabbix 的告警渠道發(fā)送告警信息給全行訂閱了這個業(yè)務系統(tǒng)的技術人員。直接在網(wǎng)頁界面編寫 SQL 能夠適應業(yè)務查詢的多變性，當受監(jiān)控業(yè)務新增一個子系統(tǒng)時，僅需要在其監(jiān)控項里連接一個新表，不需要修改自定義腳本。另外，這種方法可以降低自定義腳本的維護成本，ODBC 提供了多種數(shù)據(jù)庫的驅動，在網(wǎng)頁端開來底層一切都是封裝好的，沒有必要去考慮連接如何初始化、怎么建立游標、合適釋放會話等。當獲取到各個業(yè)務的監(jiān)控數(shù)據(jù)后，能夠平滑地對接到 Zabbix 的 dashboard，為各個業(yè)務創(chuàng)建一個監(jiān)控面板，實現(xiàn)大屏展示的效果。在實踐過程中，對于這種便捷的監(jiān)控方式，要特別注意幾點：在文件系統(tǒng)上縮小 od

35、bc 連接配置文件 odbc.ini 的權限，僅保證 zabbix 用戶可訪問，修改由特殊用戶修改。規(guī)范 SQL 編寫規(guī)則，不允許出現(xiàn)執(zhí)行成本較大的語句，這也需要跟 DBA 溝通好。盡可能地讓結果集返回一行甚至一行一列。把數(shù)據(jù)計算操作分攤給 Zabbix 預處理，不能把太多的計算操作下推至數(shù)據(jù)庫層面。頁面監(jiān)控從上面討論的各個監(jiān)控維度上看，在一個運維的縱向坐標上，從硬件監(jiān)控到業(yè)務監(jiān)控，實現(xiàn)了最底層到最頂層的全方面的監(jiān)控覆蓋，多個層面保證了監(jiān)控系統(tǒng)能夠快速發(fā)現(xiàn)問題故障，進行準確的告警報送。但運維人員對監(jiān)控的思考還沒有結束，進而思考一個問題，監(jiān)控的點位夠否不單單在縱坐標上移動，而是可以前移至“未來”

36、的時間點。例如不僅僅是用戶登錄系統(tǒng)進行交易后才觸發(fā)一次失敗才產(chǎn)生數(shù)據(jù)被監(jiān)控，而是周期性地去探測一次交易前置條件，即便在沒有客戶進行交易時，也會有 Zabbix 在交易頁面上探測需要資源是否具備。這樣能夠保證比真實客戶更早的發(fā)現(xiàn)一些交易平臺的頁面異常，在邏輯上實現(xiàn)了”預知“的效果。另外，可以通過多個運營商線路去做頁面監(jiān)控，更加全面地覆蓋客戶案例，在發(fā)現(xiàn)異常時，也能夠對比其他線路是否存在運行商的網(wǎng)絡問題，例如 CDN、黑名單等。我們使用 Zabbix Web 的監(jiān)控方式，通過防火墻和 NAT 的網(wǎng)絡隔離，使用 Squid 實現(xiàn)線路選擇，以及運用 selenium 等自動化工具進行頁面動作模擬，實現(xiàn)

37、了網(wǎng)銀系統(tǒng)的內外網(wǎng)、運營商線路層面的監(jiān)控。平臺監(jiān)控除了上面提到的監(jiān)控以外，有一個特殊場景，是運維人員難以回避的，那就是某一些系統(tǒng)自帶了一套監(jiān)控平臺，但目前使用的主流監(jiān)控卻無法兼容或替換掉它，當引入組件、產(chǎn)品逐漸增多時，這種問題就越發(fā)明顯。例如移動開發(fā)平臺 mPaaS 中自帶了例如 monitorkernel、corewatch、monitorguard 等監(jiān)控組件，對整個 mPaaS 平臺運行具有非常重要的作用，如果考慮使用其他監(jiān)控系統(tǒng)將其替換，技術磨合的成本也會非常巨大，而且也丟失了平臺自身的穩(wěn)定性。對此，我們決定使用自建外部渠道加 Zabbix Sender 實現(xiàn)外部平臺以監(jiān)控流的方式對接

38、至 Zabbix，這樣既能既能避免對原有第三方監(jiān)控系統(tǒng)的侵入，也能讓其監(jiān)控數(shù)據(jù)匯聚到 Zabbix。首先，這里介紹一下 Zabbix Sender 的原理。當受監(jiān)控的主機在 Zabbix 中是處于主動模式的話（大部分主機是被動模式），該主機可以自行構建一個已存在的監(jiān)控項數(shù)據(jù)發(fā)送給 Zabbix，而 Zabbix 收到數(shù)據(jù)進行驗證后，也會作為該主機的監(jiān)控項數(shù)據(jù)，這樣也可以實現(xiàn)監(jiān)控的實時性。當對接主機的上游是第三方監(jiān)控平臺時，整個流程看起來就像動態(tài)的數(shù)據(jù)流一樣，從上游不斷流入至 Zabbix。對接上游第三方平臺的實現(xiàn)，我們目前有如下方案：當外部平臺支持 HTTP RESTful 的監(jiān)控對接時，將其

39、對接至一個專門負責接受此類告警的 HTTP 服務器，并為其設置一個獨立的資源路徑的 handler。當外部平臺不支持監(jiān)控對接，但支持告警推送，可以將接受的告警級別調至最低或全量，將其發(fā)送給 HTTP 服務器、TCP/UDP 服務器或郵件服務器。當外部平臺沒有任何渠道外送信息時，會選擇網(wǎng)頁爬蟲、數(shù)據(jù)庫監(jiān)控等方式，當這樣也會丟失監(jiān)控流式的特性。以目前遇到的情況，幾乎沒有第三種情況，一般都是提供 HTTP 外推監(jiān)控或告警的，所以這類都會接入到我們一個使用 Golang 編寫的專用 HTTP 服務器，在每次新增對接平臺時，增加對應的 handler 中的 OtherReader 和 ZBXSender

40、 接口實現(xiàn)即可。但需要注意對于這種方式的觸發(fā)器，需要著重關心 change()/diff() 函數(shù)的依賴，因為有時候同一個監(jiān)控項推送頻率會非常高。還是以上面提到的 mPaaS 為例，通過這種方式對接其核心監(jiān)控平臺 corewathc，能夠獲取到此平臺的所有告警監(jiān)控。告警通知監(jiān)控覆蓋的話題，到此也算是結束了，下面進而討論下一個環(huán)節(jié)，那就是監(jiān)控觸發(fā)的告警需要如何才能推送到需要接收的技術人員。其實，Zabbix 自身也提供了非常多樣的告警推送渠道，也可以自定義腳本來處理告警內容再推送給至渠道。但我們選擇將這個推送的渠道稍微拉長，讓告警發(fā)揮出更多的作用。如果告警無法推送，那么監(jiān)控的意義就少了一大半，但

41、推送的太多，告警也就沒有價值可言。Zabbix 的告警消息結構體只是一個字符串，有些特殊符號混雜會對后面的序列化動作觸發(fā)異常，抑或發(fā)送告警的 Proxy 宕機了，而大量告警卻發(fā)不出來。由此種種產(chǎn)生的困擾，想必每一個接觸過告警的技術人員，都會深有感觸。為了解決這些最后一百米的問題，我們也不斷地嘗試各種方法，目前也依舊在努力尋求突破。我們編寫了一個內部命名為 Zabbxi Robot 的工具，可以按照預定的 Zabbix 告警字符串進行 JSON 解析，并在預處理完后，會判斷此告警是否需要抑制，是否屬于一次需要收斂的抖動，然后才把告警推送至下游。另外，在 Zabbix 的架構設計上，將一個負責主要

42、告警推送的 Proxy 與 Server 配置為互相監(jiān)控，而 Server 會有兩個推送渠道在主渠道失效后進行通知，進而避免告警空白。這里的短息貓通過 gnokii 調用串行接口實現(xiàn)的短信發(fā)送，發(fā)送效率非常低，僅當探測發(fā)現(xiàn) Zabbix 架構出現(xiàn)重大故障時，會應急發(fā)送給幾位負責監(jiān)控系統(tǒng)的運維人員。而備用渠道與主要驅動實現(xiàn)方法都是把告警信息以 curl POST 的方式傳送給 Zabbix Robot，不同點在于兩者使用了不同的 Header，從而在 Zabbix Robot 中區(qū)分出具體的渠道，也會對此過濾。Zabbix Robot 是我們使用 Golang 開發(fā)的 HTTP 服務器，目前具備

43、兩個模塊，先觸發(fā)抑制模塊，后觸發(fā)收斂模塊。這里的抑制操作是以 LimitUnitGroup 來生效的，當期觸發(fā)條件滿足每一個 gorup 的三元組（flag, number, second，當判斷為 flag 的告警，在 second 秒內收到了超過 number 數(shù)量）時，則會使用 flag 派生出一個 InhibitionUnit 的 goroutine，而這個 flag 如果存在 InhibitionUnit，那么就可以判斷處于抑制狀態(tài)，不會發(fā)送出去。InhibitionUnit 也是一個三元組（flag, number, second），當判斷為 flag 的告警，在收到 number

44、 數(shù)量后或超過 second 秒后退出此次抑制。而在 Zabbix-Robot 的配置文件里，細分了每個 flag 和其屬性。一般而言，目前常用的 flag 就是 Zabbix 的 TRIGGER.SEVERITY，即告警級別。收斂模塊是目前在測試階段的一個功能，優(yōu)先實現(xiàn)了 Weights 的方法，即判斷收到告警與過去三十分鐘（可調）樣本中的 hostidX_+_itemidY+triggerid*Z 總分，如果超過預定值 K，則會被判定為抖動進而收斂。這里的 X/Y/Z 是可自定義的權重，比如可以通過提高 X 來把收斂權重傾向于主機，那么同一臺主機發(fā)送的告警數(shù)則會被優(yōu)先收斂。另外還有其他收斂

45、的方法，比如字符串特征和機器學習，這兩個也是我們嘗試的方向。當走完抑制和收斂，告警會流向我們的自動化平臺，并由平臺判斷是否派生工單，然后再經(jīng)訂閱系統(tǒng)把告警發(fā)送給指定負責人后，負責人將在工單系統(tǒng)反饋處理情況。這里的訂閱系統(tǒng)也對接了 Zabbix 的一些元數(shù)據(jù)，Zabbix 在 4.0 后推出的標簽功能（tags）非常便利與做告警篩選，如果使用過 K8S，那么可以將這種篩選過程理解為 Labels 和 Selectors。目前這套告警推送流程，解決了原先的大部分問題，也能讓 Zabbix 為工單系統(tǒng)、訂閱系統(tǒng)提供有力支持，Golang 天生強大的并發(fā)能力也能非常有效的抵抗告警泛洪，而且其也是無狀態(tài)

46、的，在未來甚至可以部署雙節(jié)點來實現(xiàn)高可用。報表生成為了讓 Zabbix 具備更多的報表展示能力，我們也對其前端進行了一定的定制開發(fā)，將常用的一些報表對接至 Zabbix。同時，Zabbix 也提供了資產(chǎn)清單、自定義拓撲、dashboard 等功能，具備了一定的報表生成能力。像上面提到的頁面監(jiān)控，其實也是一個內外網(wǎng)的流向拓撲，可以將各個層面的頁面分別前后對接，那么就可以提供非常優(yōu)秀的問題定位能力。除此，還有每日一更的容量清單、硬件信息、巡檢報告等。就如其中一個 VMware 虛擬機互斥檢查為例，其通過樹形圖的形式，展示出每個業(yè)務系統(tǒng)的應用模塊中，判斷冗余節(jié)點是否部署在相錯的資源（ESXi 或 L

47、UN 或 Cluster）上的，這樣方便虛擬機管理員分離關聯(lián)虛擬機，降低發(fā)生 HA 時受影響的系統(tǒng)模塊，也能夠保應用證同城災備的建設是否符合預期。高可用在 5.0 之前，并沒有官方的 Zabbix 高可用方案，我們采用的是數(shù)據(jù)庫級別的恢復方案。通過定時腳本，每日凌晨（注意，這里要盡可能錯開 Housekeeping）將 Zabbix 中排除 history* 的表和 zabbix web 前端文件備份到災備機房。如果發(fā)生不可恢復的故障，可以重新部署 Zabbix Server，并恢復數(shù)據(jù)庫，這樣的代價僅會丟失歷史數(shù)據(jù)和趨勢，但能夠快速恢復監(jiān)控運行的狀態(tài)。此外，建議 Zabbix Agent 的

48、被動模式 Server 的地址配置為 Proxy 的網(wǎng)段，這樣當 Proxy 出現(xiàn)故障時，也能夠快速平移至其他 Proxy。未來規(guī)劃在我們使用 Zabbix 的兩年里，運維也開始了全面的自動化，在這個背景下，我們越來越多地認識到監(jiān)控的價值，監(jiān)控也不單純是告警廣播，需要有更多智能的方式去挖掘監(jiān)控的潛能。在這兩年多的時間里，我們對 Zabbix 系統(tǒng)進行了各方面的功能擴展，也期待未來會有更多的發(fā)展可能?，F(xiàn)在，對未來的規(guī)劃，細數(shù)下來，有如下幾點。Zabbix 數(shù)據(jù)庫選型目前生產(chǎn)使用的 Zabbix 數(shù)據(jù)庫架構是 Zabbix 4.4 + Percona 8.0 + TokuDB，TokuDB 主要是

49、用于 history 表，并且對 history 表都進行了分區(qū)，而其他的配置表仍是使用 Innodb，TokuDB 使用 QUICKLZ 的壓縮算法。另外，對數(shù)據(jù)庫的配置進行了優(yōu)化，例如雙 1 這類需要性能成本的設置也統(tǒng)統(tǒng)改為性能為主。在剛遷移到這個架構時，壓縮率和歷史數(shù)據(jù) QPS 都有非常顯著的提升，但是隨著監(jiān)控項數(shù)量的增加，也開始慢慢感受到了瓶頸與壓力。歷史數(shù)據(jù)即便開了壓縮也不能抑制上漲的趨勢，而開啟管家后每次刪除過期數(shù)據(jù)帶來的 CPU iowait 也令人煩惱，當查詢大量冷的歷史數(shù)據(jù)時，漫長的加載時間也讓人崩潰。我們在測試環(huán)境的 Zabbix 平臺，納管了幾倍于生產(chǎn)環(huán)境的主機數(shù)量，可以當成是一個實打實的壓測場景。為了尋求最佳實踐，我們在測試環(huán)境先后測試了 TokuDB、RocksDB、TiDB、Elasticsearch、Timesca