銀行 Zabbix 監(jiān)控架構(gòu)

Zabbix平臺(tái)概述平臺(tái)介紹Zabbix是一個(gè)基于Web界面提供分布式系統(tǒng)監(jiān)視及網(wǎng)絡(luò)監(jiān)視功能的企業(yè)級(jí)開源解決方案。它能監(jiān)視各種網(wǎng)絡(luò)參數(shù)，保證服務(wù)器系統(tǒng)的安全運(yùn)營(yíng)，并提供靈活的通知機(jī)制以讓系統(tǒng)管理員快速定位、解決存在的各種問(wèn)題，借助Zabbix可很輕松地減輕運(yùn)維人員繁重的服務(wù)器管理任務(wù)，保證業(yè)務(wù)系統(tǒng)持續(xù)運(yùn)行。其后端使用數(shù)據(jù)庫(kù)存儲(chǔ)監(jiān)控配置和歷史數(shù)據(jù)，可以非常方便地對(duì)接數(shù)據(jù)分析、報(bào)表定制等渠道，在前端開放了豐富的RESTfulAPI供第三方平臺(tái)調(diào)用，整體架構(gòu)在當(dāng)下的DevOps的趨勢(shì)下顯得非常亮眼。選型過(guò)程我們于2017年開始接觸Zabbix，之前運(yùn)維內(nèi)主要使用的監(jiān)控系統(tǒng)是Nagios，但Nagios的頁(yè)面展示、監(jiān)控配置、自動(dòng)化等各項(xiàng)功能對(duì)基礎(chǔ)架構(gòu)的運(yùn)維人員來(lái)說(shuō)不是特別友好，而風(fēng)頭正勁的Zabbix正好引起了我們的注意?；A(chǔ)架構(gòu)的運(yùn)維工作中，需要面對(duì)各種各樣的監(jiān)控場(chǎng)景，例如PC服務(wù)器的故障燈巡檢、存儲(chǔ)設(shè)備的陣列健康判斷、小型機(jī)LPAR的資源監(jiān)控、操作系統(tǒng)的多路徑檢查，等等。而Zabbix內(nèi)置提供了SNMP、IMPI、SSH、Agent等多種監(jiān)控途徑，在系統(tǒng)架構(gòu)的各層場(chǎng)景下都能很好的適配，其中Agent還支持自定義工具，總體的表現(xiàn)非常靈活。在網(wǎng)頁(yè)前端管理上，Zabbix可以滿足各個(gè)粒度的監(jiān)控管理，從整個(gè)集群到單獨(dú)一個(gè)監(jiān)控項(xiàng)都能夠進(jìn)行細(xì)分管控，自定義dashboard和歷史數(shù)據(jù)可視化功能也極大地方便運(yùn)維人員對(duì)監(jiān)控?cái)?shù)據(jù)的審查。綜合以上的考慮因素，行內(nèi)選擇了Zabbix作為一個(gè)新的監(jiān)控平臺(tái)試點(diǎn)，從基礎(chǔ)資源的監(jiān)控出發(fā)，首先將大部分存儲(chǔ)、主機(jī)和操作系統(tǒng)接管到Zabbix。使用現(xiàn)狀2017年底在基礎(chǔ)架構(gòu)范圍內(nèi)試行的Zabbix系統(tǒng)，從3.2版本開始逐步演進(jìn)到現(xiàn)在的4.4版本，其中經(jīng)歷了各項(xiàng)監(jiān)控系統(tǒng)的里程碑事件。目前的Zabbix系統(tǒng)也由原先的小范圍試用，逐步擴(kuò)展到涵蓋硬件、應(yīng)用、平臺(tái)、業(yè)務(wù)等更大范圍的場(chǎng)景，架構(gòu)上也從單數(shù)據(jù)中心進(jìn)化為三中心的分布式部署。除了逐漸替代舊的監(jiān)控系統(tǒng)，越來(lái)越多的第三方系統(tǒng)也開始對(duì)接起了Zabbix，例如自動(dòng)化運(yùn)維平臺(tái)、持續(xù)發(fā)布平臺(tái)、運(yùn)維可視化平臺(tái)等，通過(guò)API或者數(shù)據(jù)庫(kù)抽數(shù)的方式，使用海量的運(yùn)維監(jiān)控?cái)?shù)據(jù)實(shí)現(xiàn)智能運(yùn)維的工作模式。在編寫此文前不久，我們也順利完成應(yīng)用系統(tǒng)監(jiān)控遷移到Zabbix平臺(tái)，作為一名全程參與Zabbix系統(tǒng)推廣實(shí)施和自動(dòng)化開發(fā)的運(yùn)維人員，非常榮幸能夠見(jiàn)證我們運(yùn)維力量的茁壯成長(zhǎng)，在此，本人也將從架構(gòu)部署、監(jiān)控維度、自動(dòng)化方案、運(yùn)營(yíng)管理層面，分享我們Zabbix系統(tǒng)發(fā)展壯大的經(jīng)驗(yàn)。硬件監(jiān)控?cái)?shù)據(jù)中心的運(yùn)維管理中，系統(tǒng)架構(gòu)的縱向深度是非常陡長(zhǎng)的，包括最基礎(chǔ)的硬件設(shè)備也需要運(yùn)維人員費(fèi)盡心思地去巡檢排查，但隨著數(shù)據(jù)中心的設(shè)備數(shù)量呈爆發(fā)式增長(zhǎng)，人工巡檢已不能滿足當(dāng)下監(jiān)控實(shí)時(shí)性、可靠性的要求。對(duì)于這種低層級(jí)的監(jiān)控，Zabbix的多維度特性就非常好的解決了這個(gè)問(wèn)題，其內(nèi)置的SNMP/IPMI協(xié)議能夠輕松對(duì)接相關(guān)硬件設(shè)備的帶外監(jiān)控。目前我們使用SNMPAgent的被動(dòng)方式定期巡檢硬件設(shè)備的基礎(chǔ)指標(biāo)，例如故障燈信號(hào)、電源功率、內(nèi)存信息、磁盤陣列等，代替人工巡檢的方式來(lái)實(shí)現(xiàn)異常捕獲，并對(duì)數(shù)據(jù)中心內(nèi)的所有設(shè)備做到硬件信息采集，定時(shí)更新至CMDB。例如以下為部分華為RH2288V3IBMC監(jiān)控模板中自動(dòng)發(fā)現(xiàn)的配置：Zabbix配置硬件監(jiān)控的操作過(guò)程也非常便捷，大部分都是在網(wǎng)頁(yè)界面配置，只需要定義好SNMPAgent/Trap的接口或IPMI傳感器目標(biāo)端口后即可靈活定義監(jiān)控項(xiàng)。對(duì)于IPMI監(jiān)控的配置，主要是將傳感器的名稱填入即可，目前我們對(duì)IPMI的帶外監(jiān)控使用的相對(duì)較少，主要是部分浪潮PC服務(wù)器在使用，對(duì)IPMI更多地考慮應(yīng)用在如VMwarevSphere的DPM等帶外管理上。在硬件監(jiān)控選擇監(jiān)控協(xié)議時(shí)，保持的一項(xiàng)原則是：能用SNMP就不用其他，能用SNMPv3就不用SNMPv2。因?yàn)镾NMP在Zabbix中可以非常靈活的實(shí)現(xiàn)自動(dòng)發(fā)現(xiàn)，而SNMPv3可以提供更健壯的認(rèn)證機(jī)制，因?yàn)樵陂_放硬件監(jiān)控的同時(shí)也必須考量網(wǎng)絡(luò)安全的風(fēng)險(xiǎn)。對(duì)單個(gè)SNMPv3的監(jiān)控項(xiàng)配置如下，大部分參數(shù)都提供了輸入窗口：

對(duì)于上述提及的SNMP配置自動(dòng)發(fā)現(xiàn)的靈活性，這也是依賴于SNMP設(shè)計(jì)的原理，借助樹結(jié)構(gòu)的索引方式，可以根據(jù)index字段枚舉現(xiàn)有元素的數(shù)量，然后再根據(jù)數(shù)量長(zhǎng)度來(lái)遍歷下一層元素。對(duì)于這種遍歷，Zabbix自身提供了友好的discovery[{#SNMPVALUE},OID]函數(shù)來(lái)完成，無(wú)縫對(duì)接到內(nèi)部通用的自動(dòng)發(fā)現(xiàn)數(shù)據(jù)結(jié)構(gòu)。整個(gè)SNMP自動(dòng)發(fā)現(xiàn)的機(jī)制原理如下

由于我們Zabbix的起步試點(diǎn)是從基礎(chǔ)設(shè)施運(yùn)維開始，加上Zabbix對(duì)SNMP/IPMI協(xié)議配置的操作非常方便，所以經(jīng)?？梢愿鶕?jù)廠家提供的mib文件及mib文檔說(shuō)明即可篩選出需要自定義的監(jiān)控，這樣既可以通過(guò)減少采集來(lái)降低管理系統(tǒng)的繁忙度，又能優(yōu)化監(jiān)控質(zhì)量。例如以下為根據(jù)LenovoXCC帶外管理系統(tǒng)的mib說(shuō)明（http://www.circitor.fr/Mibs/Html/L/LENOVO-XCC-MIB.php）來(lái)自定義配置的ThinkSystemSR650的SNMPv3監(jiān)控使用效果：

上圖中的電源、陣列、磁盤等均是通過(guò)自動(dòng)發(fā)現(xiàn)的規(guī)則來(lái)生成的，這對(duì)擁有不同陣列卡數(shù)量、網(wǎng)卡數(shù)量、路數(shù)等的XCC帶外服務(wù)器，都可以使用同一個(gè)模板，設(shè)備變化完全交給Zabbix維護(hù)。另外，分享一個(gè)定制SNMP監(jiān)控過(guò)程中的經(jīng)驗(yàn)，首先在MIB文件中收集所有需要監(jiān)控的指標(biāo)，對(duì)篩選的指標(biāo)做分組，找到每個(gè)組的最高父級(jí)索引的OID，然后在ZabbixProxy上使用snmpwalk遍歷這個(gè)OID找到所有OID內(nèi)容，區(qū)分出Index和Detail后，劃分常規(guī)監(jiān)控和自動(dòng)發(fā)現(xiàn)監(jiān)控，最后使用snmpget來(lái)逐個(gè)獲取OID的值確定對(duì)應(yīng)Zabbix上的數(shù)值類型。需要特別注意，snmpwalk是遍歷，并不需要OID的完整值，而snmpget則是根據(jù)一個(gè)完整的OID來(lái)檢索，對(duì)應(yīng)于Zabbix則是snmpwalk類似自動(dòng)發(fā)現(xiàn)，snmpget類似常規(guī)監(jiān)控項(xiàng)。存儲(chǔ)監(jiān)控在數(shù)據(jù)中心中，存儲(chǔ)設(shè)備是非常核心且關(guān)鍵的基礎(chǔ)設(shè)施，任何一個(gè)相關(guān)告警都會(huì)讓運(yùn)維人員警覺(jué)。在推進(jìn)Zabbix的存儲(chǔ)監(jiān)控的過(guò)程中，體會(huì)到一個(gè)非常棘手的困難點(diǎn)，即存儲(chǔ)不單單是硬件設(shè)備，SNMP的協(xié)議不能獲取到帶內(nèi)的性能信息，但也不像主流操作系統(tǒng)那樣可以安裝ZabbixAgent來(lái)做數(shù)據(jù)采集。對(duì)于這種問(wèn)題的處理，我們積累的經(jīng)驗(yàn)是，首選使用RESTful等外部接口來(lái)獲取監(jiān)控?cái)?shù)據(jù)，在不支持此條件的情況下，在ZabbixProxy服務(wù)器上通過(guò)自定義監(jiān)控封裝廠家推薦工具或方法來(lái)監(jiān)控。ZabbixAgent支持運(yùn)維人員自定義監(jiān)控，將執(zhí)行命令封裝成一個(gè)ZabbixItemKey來(lái)供Zabbix調(diào)用，也支持額外的安全策略，例如AllowRoot可以設(shè)置是否允許root來(lái)執(zhí)行agent，UnsafeUserParameters參數(shù)能夠過(guò)濾特殊符號(hào)注入。我們對(duì)自定義配置的標(biāo)準(zhǔn)，以RedHat基線為例，在/etc/zabbix/zabbix_agentd.d目錄一個(gè)監(jiān)控類為一份conf文件的形式保存，命名形式為ClassA_ClassB_Detail.conf，并且定義的執(zhí)行文件均放置于/usr/local/zbxexec/ClassA/ClassB/xxxx.xx。對(duì)于自定義監(jiān)控項(xiàng)的方法，能夠便捷地對(duì)接各個(gè)存儲(chǔ)廠家的產(chǎn)品監(jiān)控方式，將廠家建議的監(jiān)控命令封裝為Zabbix的一個(gè)監(jiān)控項(xiàng)。這類被封裝的方法主要是CLI、RESTful和SSH，例如以下我們目前對(duì)各產(chǎn)品使用的監(jiān)控方式：除了跟廠家溝通對(duì)接Zabbix外，其實(shí)也可以借助開源生態(tài)和Zabbix的合作推廣，也有很多企業(yè)與我們一樣會(huì)分享Zabbix的經(jīng)驗(yàn)、模板、工具到ZabbixShare，可以斟酌篩選后使用。同時(shí)，Zabbix也一直努力與其他廠家共同合作，共同推出每個(gè)廠家在Zabbix上的官方監(jiān)控模板，例如DELLEMC在Zabbix中推出的各個(gè)產(chǎn)品的監(jiān)控模板（/integrations/emc）。通過(guò)上述的監(jiān)控方式，Zabbix對(duì)生產(chǎn)環(huán)境存儲(chǔ)設(shè)備的監(jiān)控效果讓運(yùn)維人員感到比較滿意，agentless的架構(gòu)避免對(duì)重要設(shè)備的侵入，同時(shí)相關(guān)的存儲(chǔ)告警也能夠及時(shí)觸發(fā)，并幫助存儲(chǔ)管理人員迅速發(fā)現(xiàn)問(wèn)題、定位原因。主機(jī)監(jiān)控我們目前的主機(jī)監(jiān)控主要包含了Power的小型機(jī)和x86的ESXi，這類對(duì)象有一非常明顯的特點(diǎn)，就是數(shù)量和信息不固定。一臺(tái)小型機(jī)可能需要為新部署的數(shù)據(jù)庫(kù)劃分物理分區(qū)或虛擬分區(qū)，亦或者要調(diào)整某個(gè)數(shù)據(jù)庫(kù)的CPU分配；一個(gè)vSphere集群可能會(huì)擴(kuò)容ESXi主機(jī)數(shù)量或資源，亦或新建一個(gè)集群。在這種多變的的環(huán)境里，首先考慮的是使用Zabbix的自動(dòng)發(fā)現(xiàn)來(lái)適配，并且此場(chǎng)景有一個(gè)非常明顯的相似特性，就是需要一個(gè)主控端來(lái)管理整個(gè)主機(jī)資源池。因此，我們對(duì)主機(jī)的監(jiān)控常常采用的原則是，通過(guò)監(jiān)控主控端來(lái)自動(dòng)發(fā)現(xiàn)主機(jī)，讓被發(fā)現(xiàn)的主機(jī)自動(dòng)使用對(duì)應(yīng)模板。上述的監(jiān)控流程主要是依賴Zabbix的自動(dòng)注冊(cè)主機(jī)來(lái)實(shí)現(xiàn)，不同于硬件監(jiān)控中提及的自動(dòng)注冊(cè)監(jiān)控項(xiàng)，這里的自動(dòng)注冊(cè)會(huì)直接根據(jù)主控端獲取的資源列表，自動(dòng)注冊(cè)一個(gè)待監(jiān)控的主機(jī)，相關(guān)的主機(jī)配置包括主機(jī)名、可見(jiàn)名稱、agent接口等都會(huì)繼承主控，然后會(huì)為每個(gè)主機(jī)都綁定一個(gè)預(yù)先配置的監(jiān)控模板。如果主控端發(fā)現(xiàn)某一個(gè)主機(jī)不在上一次收集的資源列表中，會(huì)在超過(guò)資源保留策略時(shí)間后，自動(dòng)刪除該主機(jī)。例如自動(dòng)發(fā)現(xiàn)的ESXi主機(jī)：

操作系統(tǒng)監(jiān)控操作系統(tǒng)的監(jiān)控是非常龐大的，除了操作系統(tǒng)種類多，每個(gè)操作系統(tǒng)內(nèi)的監(jiān)控項(xiàng)數(shù)量也是覆蓋面廣，再乘上物理機(jī)、虛擬機(jī)的數(shù)量，整個(gè)監(jiān)控面積會(huì)非常之大。另外，將每一臺(tái)服務(wù)器納管至Zabbix中的操作也變得異常繁瑣。對(duì)此，我們保持的思路是，通過(guò)自動(dòng)化手段讓服務(wù)器自動(dòng)上報(bào)到Zabbix，優(yōu)化模板以減少重復(fù)監(jiān)控，定制觸發(fā)器的依賴關(guān)系。操作系統(tǒng)的監(jiān)控都是使用ZabbixAgent方案來(lái)實(shí)現(xiàn)的，Zabbix也推出了各種操作系統(tǒng)的agent，不需要編譯就能直接運(yùn)行。對(duì)此，我們的所有虛擬機(jī)基線、小型機(jī)備份、物理機(jī)Ansible部署腳本里，都會(huì)事先準(zhǔn)備好對(duì)應(yīng)操作系統(tǒng)的Agent安裝和配置。其中，推薦使用被動(dòng)方式，并且主要修改agent配置的如下內(nèi)容：32.2#其中/24為當(dāng)前機(jī)房的ZabbixProxy節(jié)點(diǎn)網(wǎng)段Server=,/24#Hostname是這臺(tái)服務(wù)器的管理IPHostname=這種配置主要是方便于agent在多個(gè)Proxy中平移，在故障恢復(fù)、Zabbix升級(jí)等場(chǎng)景下，可以非常便利的保證agent的持續(xù)有效。另外將本地回環(huán)地址也寫入Server中，方便以后需要在此操作系統(tǒng)中通過(guò)agent調(diào)用本地腳本。Hostname在被動(dòng)模式下并不是必須的，配置管理IP可以保證主動(dòng)模式和配置管理的便利。以上僅是agent的配置標(biāo)準(zhǔn)，如果需要自動(dòng)上報(bào)至Zabbix，還需要其他步驟。目前我們對(duì)于物理機(jī)和虛擬機(jī)的x86操作系統(tǒng)實(shí)現(xiàn)了自動(dòng)上報(bào)主機(jī)的機(jī)制，每天上午八點(diǎn)會(huì)做一次上報(bào)，然后對(duì)新增的主機(jī)自動(dòng)加入維護(hù)模式，避免部署階段中各種不關(guān)鍵的異常帶來(lái)告警風(fēng)暴，直至系統(tǒng)穩(wěn)定才會(huì)退出維護(hù)模式。在物理機(jī)的部署中，我們除了一套完善的自動(dòng)化RAID配置、PXE安裝系統(tǒng)外，還有對(duì)操作系統(tǒng)配置基線的Ansible方案，每個(gè)操作系統(tǒng)的roles里，都有一個(gè)InstallZabbixAgentAndReport的task，這樣通過(guò)實(shí)現(xiàn)配置的好的vars即可將此主機(jī)以標(biāo)準(zhǔn)命名添加到Zabbix中。而對(duì)于數(shù)量龐大的虛擬機(jī)，我們編寫了一套Python腳本，掃描各個(gè)機(jī)房vCenter中的虛擬機(jī)獲取到每日的虛擬機(jī)差異，再使用其在CMDB的屬性、vCenter上的備注，來(lái)填充業(yè)務(wù)系統(tǒng)、應(yīng)用集群、服務(wù)器描述等，最后注冊(cè)到Zabbix。這種機(jī)制除了極大程度地解放運(yùn)維人員對(duì)新系統(tǒng)的主機(jī)監(jiān)控注冊(cè)外，還可以在腳本中指定納管策略來(lái)實(shí)現(xiàn)各種額外的預(yù)期目標(biāo)，列舉以下幾點(diǎn)：根據(jù)網(wǎng)段信息，將同機(jī)房的服務(wù)器接口對(duì)接同機(jī)房的Proxy，避免機(jī)房流量交叉。通過(guò)判斷當(dāng)前Zabbix各個(gè)Proxy的vps，將新增主機(jī)接入到低負(fù)載的Proxy。將CMDB中現(xiàn)有的信息填入到被注冊(cè)主機(jī)的標(biāo)簽和資產(chǎn)信息中。其架構(gòu)上的拓?fù)浜?jiǎn)化如下：在這套自動(dòng)化機(jī)制下，極大地減輕了運(yùn)維人員對(duì)監(jiān)控配置的厭惡，也加到了對(duì)我們CMDB的關(guān)聯(lián)，為以后的工單系統(tǒng)打下架構(gòu)基礎(chǔ)。但是，我們對(duì)監(jiān)控系統(tǒng)的分析和探索沒(méi)有僅僅止步于此，考慮到操作系統(tǒng)監(jiān)控中觸發(fā)器帶來(lái)的大量告警，我們也研究了一些額外的措施，避免太寬泛的告警涌現(xiàn)。首先，將模板細(xì)分為各個(gè)類別作為基類的template，然后根據(jù)應(yīng)用場(chǎng)景來(lái)指定上層的模板由哪些基類組合，避免太多的定制模板中近似功能的監(jiān)控帶來(lái)重復(fù)監(jiān)控。然后，對(duì)每個(gè)模板中的觸發(fā)器指定嚴(yán)格的依賴關(guān)系，避免告警的連帶觸發(fā)導(dǎo)致風(fēng)暴。例如Linux系統(tǒng)的分區(qū)容量監(jiān)控觸發(fā)器，我們制定了幾個(gè)水位線之間的依賴：數(shù)據(jù)庫(kù)監(jiān)控?cái)?shù)據(jù)庫(kù)監(jiān)控也是一條每個(gè)運(yùn)維人員心中緊繃的弦，除了普通的表空間使用、會(huì)話數(shù)量、SGA使用、ASM使用、緩存命中、刷臟頻率等，還有宕機(jī)、切換等狀態(tài)檢查。加上我們近幾年分布式數(shù)據(jù)庫(kù)落地，及嘗試國(guó)產(chǎn)數(shù)據(jù)庫(kù)的背景下，越來(lái)越多的數(shù)據(jù)庫(kù)產(chǎn)品需要對(duì)接至Zabbix。目前我們對(duì)數(shù)據(jù)庫(kù)的監(jiān)控，結(jié)合了多種監(jiān)控思路，制定了各種數(shù)據(jù)庫(kù)產(chǎn)品的監(jiān)控指標(biāo)，在性能數(shù)據(jù)追溯與故障告警的場(chǎng)景下都體現(xiàn)出非常優(yōu)秀的表現(xiàn)。在金融行業(yè)的傳統(tǒng)架構(gòu)中，Oracle數(shù)據(jù)庫(kù)往往是不可或缺的一個(gè)基座，我們通過(guò)模板定制，提供了Sinlge-Instance、RAC、DG、F5等多種架構(gòu)的模板，覆蓋了大部分OracleDBA關(guān)心的監(jiān)控項(xiàng)。在Zabbix中專門使用一臺(tái)高性能的Proxy，通過(guò)自定義監(jiān)控的方式來(lái)執(zhí)行Oracle監(jiān)控腳本。除了應(yīng)急的故障告警外，現(xiàn)在Zabbix也成為了DBA分析數(shù)據(jù)庫(kù)性能的工具，對(duì)比歷史數(shù)據(jù)排查數(shù)據(jù)庫(kù)問(wèn)題，這也依賴于Zabbix保存的大量監(jiān)控信息。如下為其中有給數(shù)據(jù)庫(kù)的性能與RAC部分監(jiān)控指標(biāo)：除了傳統(tǒng)架構(gòu)的數(shù)據(jù)庫(kù)，我們對(duì)其他數(shù)據(jù)庫(kù)產(chǎn)品也提供了全面的監(jiān)控，并且對(duì)此監(jiān)控采用了主控服務(wù)（RootService）的思路，將數(shù)據(jù)庫(kù)更自動(dòng)的納入監(jiān)控中。這種方法的優(yōu)點(diǎn)是可以完美展現(xiàn)Zabbix自動(dòng)注冊(cè)主機(jī)的機(jī)制，將數(shù)據(jù)庫(kù)添加到監(jiān)控中，并使用自動(dòng)注冊(cè)監(jiān)控原型的方式來(lái)識(shí)別數(shù)據(jù)庫(kù)開啟了哪些需要監(jiān)控的細(xì)節(jié)。目前我們編寫了OceanBase、MySQL、DRDS等數(shù)據(jù)庫(kù)產(chǎn)品的監(jiān)控腳本，在Zabbix中以全新的數(shù)據(jù)庫(kù)監(jiān)控架構(gòu)運(yùn)行自管理。此框架的工作流程如下。

以MySQL的監(jiān)控為例作為詳細(xì)描述整個(gè)過(guò)程，參見(jiàn)下圖。

在MySQL實(shí)例的配置zbx_mysql.py文件中，新增一個(gè)testenv_zabbix的數(shù)據(jù)庫(kù)實(shí)例，這份文件是通過(guò)acl設(shè)置僅為zabbix用戶讀取的。當(dāng)作為MySQLRootService的主機(jī)執(zhí)行自動(dòng)發(fā)現(xiàn)主機(jī)的監(jiān)控時(shí)，會(huì)將新增的實(shí)例配置生成Zabbix自動(dòng)發(fā)現(xiàn)的json規(guī)則，根據(jù)配置信息創(chuàng)建監(jiān)控實(shí)例，并附加使用MySQL基礎(chǔ)模板。在MySQL基礎(chǔ)模板中，配置了一系列特殊的監(jiān)控自動(dòng)發(fā)現(xiàn)規(guī)則，例如DiscoveryMySQLReplicationEnable會(huì)對(duì)發(fā)現(xiàn)的實(shí)例執(zhí)行showslavestatus命令，這里仍會(huì)調(diào)用MySQLRootService的腳本，如果發(fā)現(xiàn)目標(biāo)實(shí)例開啟了主從，則會(huì)在自動(dòng)發(fā)現(xiàn)返回josn中包含一個(gè){#REPLICATION}:"enabled"的字段，從而觸發(fā)主從復(fù)制的監(jiān)控項(xiàng)生效。創(chuàng)建一臺(tái)邏輯主機(jī)作為主控服務(wù)，以鏈?zhǔn)桨l(fā)散的傳播模式自動(dòng)注冊(cè)主機(jī)，然后根據(jù)模板內(nèi)的自動(dòng)發(fā)現(xiàn)判斷是否需要附加額外的監(jiān)控配置，這種在我們創(chuàng)新使用的監(jiān)控方法，取到了非常好的成效，讓監(jiān)控系統(tǒng)變得更加智能，也不用像某些數(shù)據(jù)庫(kù)監(jiān)控還需要將連接的用戶與密碼寫入到Zabbix的宏，而只要保證讀取的配置文件在文件系統(tǒng)的ACL上是最小權(quán)限即可，提高了數(shù)據(jù)庫(kù)的訪問(wèn)安全。另外一點(diǎn)，現(xiàn)在很多的分布式數(shù)據(jù)庫(kù)也是采用控制+計(jì)算+存儲(chǔ)的架構(gòu)，例如TiDB的PD負(fù)責(zé)元數(shù)據(jù)管理、DB負(fù)責(zé)SQL解析與計(jì)算、KV負(fù)責(zé)底層鍵值對(duì)存儲(chǔ)，面對(duì)眾多的分區(qū)也好，副本也罷，最有效的監(jiān)控方式就是直接對(duì)接其管控部件，將Zabbix主控服務(wù)的起點(diǎn)映射至數(shù)據(jù)庫(kù)集群的管控上，不斷順著架構(gòu)分層，將各個(gè)組件之間的監(jiān)控項(xiàng)固化成自動(dòng)發(fā)現(xiàn)規(guī)則，實(shí)現(xiàn)精準(zhǔn)有效的監(jiān)控覆蓋。以目前我們的OceanBase分布式數(shù)據(jù)庫(kù)監(jiān)控為例，以下從OBRootService自動(dòng)發(fā)散出OBZone、OBTenant、OBServer、OBPartition等監(jiān)控細(xì)節(jié)。除了監(jiān)控架構(gòu)的不斷靈活，我們也在考慮更加深入的監(jiān)控效果，對(duì)于數(shù)據(jù)庫(kù)的監(jiān)控排查，DBA更多地希望所有相關(guān)的告警都是同一個(gè)時(shí)間點(diǎn)的，這樣更加便于橫向參照。根據(jù)這個(gè)出發(fā)點(diǎn)，運(yùn)維人員利用“監(jiān)控快照”的思想，將監(jiān)控項(xiàng)盡可能多地集中在同一個(gè)時(shí)間點(diǎn)上，這樣也能極大減少監(jiān)控?cái)?shù)據(jù)庫(kù)時(shí)頻繁交互帶來(lái)的性能損耗。實(shí)現(xiàn)這一點(diǎn)，主要借助于自定義腳本規(guī)范和Zabbix監(jiān)控項(xiàng)中的相關(guān)項(xiàng)目依賴特性。以巨杉數(shù)據(jù)庫(kù)的監(jiān)控為例，也正好通過(guò)其動(dòng)作具有一定的性能消耗來(lái)說(shuō)明減少交互頻率的重要性。

這臺(tái)測(cè)試環(huán)境的數(shù)據(jù)庫(kù)集群的Coord主機(jī)，總共有56個(gè)監(jiān)控項(xiàng)，如果每一個(gè)監(jiān)控項(xiàng)都需要單獨(dú)連接到其中一個(gè)協(xié)調(diào)節(jié)點(diǎn)并做快照獲取對(duì)應(yīng)的監(jiān)控指標(biāo)，那么集群對(duì)于這些頻繁的快照操作會(huì)付出非常大的性能成本。但實(shí)際上，這里真實(shí)的監(jiān)控項(xiàng)只有3個(gè)，也就是截圖中的multi_snapshot_SDBSNAP*開頭的，其余的都是由這三個(gè)監(jiān)控項(xiàng)派生出來(lái)的，也就表示交互次數(shù)可以從56次縮減到3次。我們對(duì)這種方案的實(shí)施，是通過(guò)自定義腳本或LDDmacros來(lái)生成一個(gè)包含各個(gè)子監(jiān)控項(xiàng)的JSON，并設(shè)置為不保存歷史記錄，這一點(diǎn)非常重要，因?yàn)樽颖O(jiān)控項(xiàng)的生成是在父監(jiān)控項(xiàng)轉(zhuǎn)儲(chǔ)前計(jì)算得到的，保存大量被拆分的冗余JSON字符串也沒(méi)有實(shí)際意義。在子監(jiān)控項(xiàng)的生成動(dòng)作中，主要使用了Zabbix監(jiān)控項(xiàng)的預(yù)處理操作，使用JSONPath將對(duì)應(yīng)的K/V抽出，再通過(guò)倍數(shù)/每秒變更/正則等方式獲取到最終的子監(jiān)控值。雖然預(yù)處理會(huì)消耗Zabbix的CPU，但是實(shí)測(cè)調(diào)大StartPreprocessors參數(shù)后，CPU沒(méi)有明顯的攀升，而且ZabbixProxy是分布式可擴(kuò)展的，這種瓶頸也非常容易通過(guò)擴(kuò)容來(lái)解決。綜合評(píng)估下來(lái)，這種方案帶來(lái)的回報(bào)是很可觀的，當(dāng)出現(xiàn)數(shù)據(jù)庫(kù)問(wèn)題時(shí)，或許更多的DBA希望回溯監(jiān)控歷史，能夠看到的是這樣同一時(shí)間平面上的各項(xiàng)指標(biāo)：

應(yīng)用監(jiān)控當(dāng)監(jiān)控的考慮維度上升至應(yīng)用組件時(shí)，我們依舊堅(jiān)持使用自動(dòng)化的方式去面對(duì)眼花繚亂的監(jiān)控需求，思考如何讓應(yīng)用的監(jiān)控更加富有生命力，同時(shí)也分析了在過(guò)去使用Nagios進(jìn)行應(yīng)用監(jiān)控時(shí)遇到的痛點(diǎn)，最終，編寫一個(gè)框架級(jí)別的工具，接管應(yīng)用的監(jiān)控生命周期。這個(gè)框架在我們內(nèi)部稱為zbx_app，通過(guò)一個(gè)文件服務(wù)器和應(yīng)用監(jiān)控的準(zhǔn)則來(lái)完成運(yùn)行，可以自動(dòng)完成自定義腳本拉取、版本迭代、自動(dòng)注冊(cè)監(jiān)控項(xiàng)等，運(yùn)維人員僅需要編寫一份應(yīng)用監(jiān)控的聲明文件，其他工作完全交由框架執(zhí)行。此框架的內(nèi)部原理，主要是通過(guò)Zabbix發(fā)送來(lái)特定的監(jiān)控項(xiàng)和自動(dòng)發(fā)現(xiàn)作為更新配置與自動(dòng)檢查基礎(chǔ)環(huán)境的信號(hào)，如果發(fā)現(xiàn)文件服務(wù)器的相關(guān)模塊版本更新則會(huì)主動(dòng)拉取文件，從而實(shí)現(xiàn)自管理的操作。這個(gè)接收特定信號(hào)并管理自身的環(huán)境的模塊我們內(nèi)部稱之為基類，所有的模塊監(jiān)控會(huì)有一個(gè)自動(dòng)發(fā)現(xiàn)規(guī)則與基類交互，如果基類聲明文件里包含了請(qǐng)求的自動(dòng)發(fā)現(xiàn)模塊，那么就會(huì)應(yīng)答，讓Zabbix感知并利用返回的結(jié)果來(lái)生成此模塊的監(jiān)控項(xiàng)。對(duì)應(yīng)的監(jiān)控項(xiàng)生成后，每個(gè)監(jiān)控項(xiàng)會(huì)使用快照的方法去捕獲一次監(jiān)控目標(biāo)，然后再由監(jiān)控相關(guān)項(xiàng)來(lái)拆分同一時(shí)間點(diǎn)上的各個(gè)子項(xiàng)。在這個(gè)調(diào)用的階段，也是與基類交互的，只不過(guò)基類會(huì)根據(jù)其模塊名來(lái)調(diào)用同步過(guò)來(lái)的模塊方法的固定接口，這些接口是編寫這類模塊的開發(fā)準(zhǔn)則，目的是為了保證基類能夠順利調(diào)用并解析。把考慮對(duì)象限制在一臺(tái)主機(jī)上，簡(jiǎn)化這個(gè)流程，可以有如下的時(shí)間線，由上至下是時(shí)間前進(jìn)的方向。

_ZabbixProxy會(huì)調(diào)用DiscoveryAPP自動(dòng)發(fā)現(xiàn)，觸發(fā)主機(jī)初始化一次當(dāng)前的zbxapp基類，基類收到信號(hào)后也會(huì)掃描環(huán)境，主要是收集各目錄下的聲明文件（lps.cfg），并根據(jù)聲明文件做一次基礎(chǔ)環(huán)境配置拉取，然后返回ZabbixProxy相關(guān)信息。ZabbixProxy收到了基類生效，其他模塊的自動(dòng)發(fā)現(xiàn)也會(huì)緊隨著對(duì)主機(jī)做一次探測(cè)，發(fā)送各自的自動(dòng)發(fā)現(xiàn)信號(hào)。基類發(fā)現(xiàn)聲明文件里存在redis的模塊聲明，那么會(huì)把內(nèi)部信息整合為自動(dòng)發(fā)現(xiàn)返回結(jié)構(gòu)體，ZabbixProxy感知后會(huì)生成對(duì)應(yīng)的監(jiān)控項(xiàng)。Redis模塊持續(xù)發(fā)送監(jiān)控快照請(qǐng)求至基類，基類收到后會(huì)調(diào)用已經(jīng)從HTTPFileServer上拉取下來(lái)的redis模塊來(lái)執(zhí)行監(jiān)控請(qǐng)求，并返回結(jié)果集。如果過(guò)程中應(yīng)用維護(hù)人員將url模塊的監(jiān)控需求寫入聲明文件，下一次接收到DiscoveryAPP信號(hào)時(shí)，基類會(huì)發(fā)現(xiàn)新增聲明，迅速前往HTTPFileServer拉取指定版本的url監(jiān)控模塊。后續(xù)URL的監(jiān)控也會(huì)與Redis一樣持續(xù)生效，直至聲明文件刪除或注釋了此模塊。如果過(guò)程中自動(dòng)化開發(fā)人員對(duì)版本庫(kù)里的redis模塊更新了代碼，基類也會(huì)在下一次接收到DiscoveryAPP信號(hào)后對(duì)比MD5列別發(fā)現(xiàn)版本更新，從而拉取替換為最新版本。使用自管理的基類實(shí)現(xiàn)了應(yīng)用監(jiān)控的閉環(huán)納管，監(jiān)控的操作上，細(xì)分了自動(dòng)化開發(fā)人員開發(fā)模塊職能，也給應(yīng)用維護(hù)人員更多的自由度去聲明自己需要的應(yīng)用監(jiān)控。而且，對(duì)基類的動(dòng)作也納入一個(gè)監(jiān)控項(xiàng)，能保證基類自己的穩(wěn)定，不至于罷工后無(wú)人知曉。通過(guò)這個(gè)框架，我們將應(yīng)用監(jiān)控從上一代的Nagios系統(tǒng)成功地遷移到了Zabbix系統(tǒng)，并且維護(hù)成本變得更低，運(yùn)行模式更加穩(wěn)定。業(yè)務(wù)監(jiān)控當(dāng)有了強(qiáng)大的應(yīng)用監(jiān)控框架支撐后，運(yùn)維人員也開始更往上地關(guān)注更上層的業(yè)務(wù)監(jiān)控，業(yè)務(wù)的特征也是整套架構(gòu)運(yùn)行穩(wěn)定的最直白表現(xiàn)。Zabbix提供了數(shù)據(jù)庫(kù)的監(jiān)控，直接在網(wǎng)頁(yè)界面直接編寫SQL語(yǔ)句，由Proxy/Server通過(guò)unixodbc加載對(duì)應(yīng)驅(qū)動(dòng)去連接目標(biāo)數(shù)據(jù)庫(kù)，最終返回執(zhí)行結(jié)果。目前我們利用這種方法，對(duì)業(yè)務(wù)的狀態(tài)信息、交易成功率、設(shè)備報(bào)活、跑批等進(jìn)行數(shù)據(jù)庫(kù)查詢，再通過(guò)Zabbix的告警渠道發(fā)送告警信息給全行訂閱了這個(gè)業(yè)務(wù)系統(tǒng)的技術(shù)人員。直接在網(wǎng)頁(yè)界面編寫SQL能夠適應(yīng)業(yè)務(wù)查詢的多變性，當(dāng)受監(jiān)控業(yè)務(wù)新增一個(gè)子系統(tǒng)時(shí)，僅需要在其監(jiān)控項(xiàng)里連接一個(gè)新表，不需要修改自定義腳本。另外，這種方法可以降低自定義腳本的維護(hù)成本，ODBC提供了多種數(shù)據(jù)庫(kù)的驅(qū)動(dòng)，在網(wǎng)頁(yè)端開來(lái)底層一切都是封裝好的，沒(méi)有必要去考慮連接如何初始化、怎么建立游標(biāo)、合適釋放會(huì)話等。當(dāng)獲取到各個(gè)業(yè)務(wù)的監(jiān)控?cái)?shù)據(jù)后，能夠平滑地對(duì)接到Zabbix的dashboard，為各個(gè)業(yè)務(wù)創(chuàng)建一個(gè)監(jiān)控面板，實(shí)現(xiàn)大屏展示的效果。在實(shí)踐過(guò)程中，對(duì)于這種便捷的監(jiān)控方式，要特別注意幾點(diǎn)：在文件系統(tǒng)上縮小odbc連接配置文件odbc.ini的權(quán)限，僅保證zabbix用戶可訪問(wèn)，修改由特殊用戶修改。規(guī)范SQL編寫規(guī)則，不允許出現(xiàn)執(zhí)行成本較大的語(yǔ)句，這也需要跟DBA溝通好。盡可能地讓結(jié)果集返回一行甚至一行一列。把數(shù)據(jù)計(jì)算操作分?jǐn)偨oZabbix預(yù)處理，不能把太多的計(jì)算操作下推至數(shù)據(jù)庫(kù)層面。頁(yè)面監(jiān)控從上面討論的各個(gè)監(jiān)控維度上看，在一個(gè)運(yùn)維的縱向坐標(biāo)上，從硬件監(jiān)控到業(yè)務(wù)監(jiān)控，實(shí)現(xiàn)了最底層到最頂層的全方面的監(jiān)控覆蓋，多個(gè)層面保證了監(jiān)控系統(tǒng)能夠快速發(fā)現(xiàn)問(wèn)題故障，進(jìn)行準(zhǔn)確的告警報(bào)送。但運(yùn)維人員對(duì)監(jiān)控的思考還沒(méi)有結(jié)束，進(jìn)而思考一個(gè)問(wèn)題，監(jiān)控的點(diǎn)位夠否不單單在縱坐標(biāo)上移動(dòng)，而是可以前移至“未來(lái)”的時(shí)間點(diǎn)。例如不僅僅是用戶登錄系統(tǒng)進(jìn)行交易后才觸發(fā)一次失敗才產(chǎn)生數(shù)據(jù)被監(jiān)控，而是周期性地去探測(cè)一次交易前置條件，即便在沒(méi)有客戶進(jìn)行交易時(shí)，也會(huì)有Zabbix在交易頁(yè)面上探測(cè)需要資源是否具備。這樣能夠保證比真實(shí)客戶更早的發(fā)現(xiàn)一些交易平臺(tái)的頁(yè)面異常，在邏輯上實(shí)現(xiàn)了”預(yù)知“的效果。另外，可以通過(guò)多個(gè)運(yùn)營(yíng)商線路去做頁(yè)面監(jiān)控，更加全面地覆蓋客戶案例，在發(fā)現(xiàn)異常時(shí)，也能夠?qū)Ρ绕渌€路是否存在運(yùn)行商的網(wǎng)絡(luò)問(wèn)題，例如CDN、黑名單等。我們使用ZabbixWeb的監(jiān)控方式，通過(guò)防火墻和NAT的網(wǎng)絡(luò)隔離，使用Squid實(shí)現(xiàn)線路選擇，以及運(yùn)用selenium等自動(dòng)化工具進(jìn)行頁(yè)面動(dòng)作模擬，實(shí)現(xiàn)了網(wǎng)銀系統(tǒng)的內(nèi)外網(wǎng)、運(yùn)營(yíng)商線路層面的監(jiān)控。平臺(tái)監(jiān)控除了上面提到的監(jiān)控以外，有一個(gè)特殊場(chǎng)景，是運(yùn)維人員難以回避的，那就是某一些系統(tǒng)自帶了一套監(jiān)控平臺(tái)，但目前使用的主流監(jiān)控卻無(wú)法兼容或替換掉它，當(dāng)引入組件、產(chǎn)品逐漸增多時(shí)，這種問(wèn)題就越發(fā)明顯。例如移動(dòng)開發(fā)平臺(tái)mPaaS中自帶了例如monitorkernel、corewatch、monitorguard等監(jiān)控組件，對(duì)整個(gè)mPaaS平臺(tái)運(yùn)行具有非常重要的作用，如果考慮使用其他監(jiān)控系統(tǒng)將其替換，技術(shù)磨合的成本也會(huì)非常巨大，而且也丟失了平臺(tái)自身的穩(wěn)定性。對(duì)此，我們決定使用自建外部渠道加ZabbixSender實(shí)現(xiàn)外部平臺(tái)以監(jiān)控流的方式對(duì)接至Zabbix，這樣既能既能避免對(duì)原有第三方監(jiān)控系統(tǒng)的侵入，也能讓其監(jiān)控?cái)?shù)據(jù)匯聚到Zabbix。首先，這里介紹一下ZabbixSender的原理。當(dāng)受監(jiān)控的主機(jī)在Zabbix中是處于主動(dòng)模式的話（大部分主機(jī)是被動(dòng)模式），該主機(jī)可以自行構(gòu)建一個(gè)已存在的監(jiān)控項(xiàng)數(shù)據(jù)發(fā)送給Zabbix，而Zabbix收到數(shù)據(jù)進(jìn)行驗(yàn)證后，也會(huì)作為該主機(jī)的監(jiān)控項(xiàng)數(shù)據(jù)，這樣也可以實(shí)現(xiàn)監(jiān)控的實(shí)時(shí)性。當(dāng)對(duì)接主機(jī)的上游是第三方監(jiān)控平臺(tái)時(shí)，整個(gè)流程看起來(lái)就像動(dòng)態(tài)的數(shù)據(jù)流一樣，從上游不斷流入至Zabbix。對(duì)接上游第三方平臺(tái)的實(shí)現(xiàn)，我們目前有如下方案：當(dāng)外部平臺(tái)支持HTTPRESTful的監(jiān)控對(duì)接時(shí)，將其對(duì)接至一個(gè)專門負(fù)責(zé)接受此類告警的HTTP服務(wù)器，并為其設(shè)置一個(gè)獨(dú)立的資源路徑的handler。當(dāng)外部平臺(tái)不支持監(jiān)控對(duì)接，但支持告警推送，可以將接受的告警級(jí)別調(diào)至最低或全量，將其發(fā)送給HTTP服務(wù)器、TCP/UDP服務(wù)器或郵件服務(wù)器。當(dāng)外部平臺(tái)沒(méi)有任何渠道外送信息時(shí)，會(huì)選擇網(wǎng)頁(yè)爬蟲、數(shù)據(jù)庫(kù)監(jiān)控等方式，當(dāng)這樣也會(huì)丟失監(jiān)控流式的特性。以目前遇到的情況，幾乎沒(méi)有第三種情況，一般都是提供HTTP外推監(jiān)控或告警的，所以這類都會(huì)接入到我們一個(gè)使用Golang編寫的專用HTTP服務(wù)器，在每次新增對(duì)接平臺(tái)時(shí)，增加對(duì)應(yīng)的handler中的OtherReader和ZBXSender接口實(shí)現(xiàn)即可。但需要注意對(duì)于這種方式的觸發(fā)器，需要著重關(guān)心change()/diff()函數(shù)的依賴，因?yàn)橛袝r(shí)候同一個(gè)監(jiān)控項(xiàng)推送頻率會(huì)非常高。還是以上面提到的mPaaS為例，通過(guò)這種方式對(duì)接其核心監(jiān)控平臺(tái)corewathc，能夠獲取到此平臺(tái)的所有告警監(jiān)控。告警通知監(jiān)控覆蓋的話題，到此也算是結(jié)束了，下面進(jìn)而討論下一個(gè)環(huán)節(jié)，那就是監(jiān)控觸發(fā)的告警需要如何才能推送到需要接收的技術(shù)人員。其實(shí)，Zabbix自身也提供了非常多樣的告警推送渠道，也可以自定義腳本來(lái)處理告警內(nèi)容再推送給至渠道。但我們選擇將這個(gè)推送的渠道稍微拉長(zhǎng)，讓告警發(fā)揮出更多的作用。如果告警無(wú)法推送，那么監(jiān)控的意義就少了一大半，但推送的太多，告警也就沒(méi)有價(jià)值可言。Zabbix的告警消息結(jié)構(gòu)體只是一個(gè)字符串，有些特殊符號(hào)混雜會(huì)對(duì)后面的序列化動(dòng)作觸發(fā)異常，抑或發(fā)送告警的Proxy宕機(jī)了，而大量告警卻發(fā)不出來(lái)。由此種種產(chǎn)生的困擾，想必每一個(gè)接觸過(guò)告警的技術(shù)人員，都會(huì)深有感觸。為了解決這些最后一百米的問(wèn)題，我們也不斷地嘗試各種方法，目前也依舊在努力尋求突破。我們編寫了一個(gè)內(nèi)部命名為ZabbxiRobot的工具，可以按照預(yù)定的Zabbix告警字符串進(jìn)行JSON解析，并在預(yù)處理完后，會(huì)判斷此告警是否需要抑制，是否屬于一次需要收斂的抖動(dòng)，然后才把告警推送至下游。另外，在Zabbix的架構(gòu)設(shè)計(jì)上，將一個(gè)負(fù)責(zé)主要告警推送的Proxy與Server配置為互相監(jiān)控，而Server會(huì)有兩個(gè)推送渠道在主渠道失效后進(jìn)行通知，進(jìn)而避免告警空白。這里的短息貓通過(guò)gnokii調(diào)用串行接口實(shí)現(xiàn)的短信發(fā)送，發(fā)送效率非常低，僅當(dāng)探測(cè)發(fā)現(xiàn)Zabbix架構(gòu)出現(xiàn)重大故障時(shí)，會(huì)應(yīng)急發(fā)送給幾位負(fù)責(zé)監(jiān)控系統(tǒng)的運(yùn)維人員。而備用渠道與主要驅(qū)動(dòng)實(shí)現(xiàn)方法都是把告警信息以curlPOST的方式傳送給ZabbixRobot，不同點(diǎn)在于兩者使用了不同的Header，從而在ZabbixRobot中區(qū)分出具體的渠道，也會(huì)對(duì)此過(guò)濾。ZabbixRobot是我們使用Golang開發(fā)的HTTP服務(wù)器，目前具備兩個(gè)模塊，先觸發(fā)抑制模塊，后觸發(fā)收斂模塊。這里的抑制操作是以LimitUnitGroup來(lái)生效的，當(dāng)期觸發(fā)條件滿足每一個(gè)gorup的三元組（{flag,number,second}，當(dāng)判斷為flag的告警，在second秒內(nèi)收到了超過(guò)number數(shù)量）時(shí)，則會(huì)使用flag派生出一個(gè)InhibitionUnit的goroutine，而這個(gè)flag如果存在InhibitionUnit，那么就可以判斷處于抑制狀態(tài)，不會(huì)發(fā)送出去。InhibitionUnit也是一個(gè)三元組（{flag,number,second}），當(dāng)判斷為flag的告警，在收到number數(shù)量后或超過(guò)second秒后退出此次抑制。而在Zabbix-Robot的配置文件里，細(xì)分了每個(gè)flag和其屬性。一般而言，目前常用的flag就是Zabbix的TRIGGER.SEVERITY，即告警級(jí)別。收斂模塊是目前在測(cè)試階段的一個(gè)功能，優(yōu)先實(shí)現(xiàn)了Weights的方法，即判斷收到告警與過(guò)去三十分鐘（可調(diào)）樣本中的hostidX_+_itemidY+triggerid*Z總分，如果超過(guò)預(yù)定值K，則會(huì)被判定為抖動(dòng)進(jìn)而收斂。這里的X/Y/Z是可自定義的權(quán)重，比如可以通過(guò)提高X來(lái)把收斂權(quán)重傾向于主機(jī)，那么同一臺(tái)主機(jī)發(fā)送的告警數(shù)則會(huì)被優(yōu)先收斂。另外還有其他收斂的方法，比如字符串特征和機(jī)器學(xué)習(xí)，這兩個(gè)也是我們嘗試的方向。當(dāng)走完抑制和收斂，告警會(huì)流向我們的自動(dòng)化平臺(tái)，并由平臺(tái)判斷是否派生工單，然后再經(jīng)訂閱系統(tǒng)把告警發(fā)送給指定負(fù)責(zé)人后，負(fù)責(zé)人將在工單系統(tǒng)反饋處理情況。這里的訂閱系統(tǒng)也對(duì)接了Zabbix的一些元數(shù)據(jù)，Zabbix在4.0后推出的標(biāo)簽功能（tags）非常便利與做告警篩選，如果使用過(guò)K8S，那么可以將這種篩選過(guò)程理解為L(zhǎng)abels和Selectors。目前這套告警推送流程，解決了原先的大部分問(wèn)題，也能讓Zabbix為工單系統(tǒng)、訂閱系統(tǒng)提供有力支持，Golang天生強(qiáng)大的并發(fā)能力也能非常有效的抵抗告警泛洪，而且其也是無(wú)狀態(tài)的，在未來(lái)甚至可以部署雙節(jié)點(diǎn)來(lái)實(shí)現(xiàn)高可用。報(bào)表生成為了讓Zabbix具備更多的報(bào)表展示能力，我們也對(duì)其前端進(jìn)行了一定的定制開發(fā)，將常用的一些報(bào)表對(duì)接至Zabbix。同時(shí)，Zabbix也提供了資產(chǎn)清單、自定義拓?fù)?、dashboard等功能，具備了一定的報(bào)表生成能力。像上面提到的頁(yè)面監(jiān)控，其實(shí)也是一個(gè)內(nèi)外網(wǎng)的流向拓?fù)?，可以將各個(gè)層面的頁(yè)面分別前后對(duì)接，那么就可以提供非常優(yōu)秀的問(wèn)題定位能力。除此，還有每日一更的容量清單、硬件信息、巡檢報(bào)告等。就如其中一個(gè)VMware虛擬機(jī)互斥檢查為例，其通過(guò)樹形圖的形式，展示出每個(gè)業(yè)務(wù)系統(tǒng)的應(yīng)用模塊中，判斷冗余節(jié)點(diǎn)是否部署在相錯(cuò)的資源（ESXi或LUN或Cluster）上的，這樣方便虛擬機(jī)管理員分離關(guān)聯(lián)虛擬機(jī)，降低發(fā)生HA時(shí)受影響的系統(tǒng)模塊，也能夠保應(yīng)用證同城災(zāi)備的建設(shè)是否符合預(yù)期。

高可用在5.0之前，并沒(méi)有官方的Zabbix高可用方案，我們采用的是數(shù)據(jù)庫(kù)級(jí)別的恢復(fù)方案。通過(guò)定時(shí)腳本，每日凌晨（注意，這里要盡可能錯(cuò)開Housekeeping）將Zabbix中排除history*的表和zabbixweb前端文件備份到災(zāi)備機(jī)房。如果發(fā)生不可恢復(fù)的故障，可以重新部署ZabbixServer，并恢復(fù)數(shù)據(jù)庫(kù)，這樣的代價(jià)僅會(huì)丟失歷史數(shù)據(jù)和趨勢(shì)，但能夠快速恢復(fù)監(jiān)控運(yùn)行的狀態(tài)。此外，建議ZabbixAgent的被動(dòng)模式Server的地址配置為Proxy的網(wǎng)段，這樣當(dāng)Proxy出現(xiàn)故障時(shí)，也能夠快速平移至其他Proxy。未來(lái)規(guī)劃在我們使用Zabbix的兩年里，運(yùn)維也開始了全面的自動(dòng)化，在這個(gè)背景下，我們?cè)絹?lái)越多地認(rèn)識(shí)到監(jiān)控的價(jià)值，監(jiān)控也不單純是告警廣播，需要有更多智能的方式去挖掘監(jiān)控的潛能。在這兩年多的時(shí)間里，我們對(duì)Zabbix系統(tǒng)進(jìn)行了各方面的功能擴(kuò)展，也期待未來(lái)會(huì)有更多的發(fā)展可能?，F(xiàn)在，對(duì)未來(lái)的規(guī)劃，細(xì)數(shù)下來(lái)，有如下幾點(diǎn)。Zabbix數(shù)據(jù)庫(kù)選型目前生產(chǎn)使用的Zabbix數(shù)據(jù)庫(kù)架構(gòu)是Zabbix4.4+Percona8.0+TokuDB，TokuDB主要是用于history表，并且對(duì)history表都進(jìn)行了分區(qū)，而其他的配置表仍是使用Innodb，TokuDB使用QUICKLZ的壓縮算法。另外，對(duì)數(shù)據(jù)庫(kù)的配置進(jìn)行了優(yōu)化，例如雙1這類需要性能成本的設(shè)置也統(tǒng)統(tǒng)改為性能為主。在剛遷移到這個(gè)架構(gòu)時(shí)，壓縮率和歷史數(shù)據(jù)QPS都有非常顯著的提升，但是隨著監(jiān)控項(xiàng)數(shù)量的增加，也開始慢慢感受到了瓶頸與壓力。歷史數(shù)據(jù)即便開了壓縮也不能抑制上漲的趨勢(shì)，而開啟管家后每次刪除過(guò)期數(shù)據(jù)帶來(lái)的CPUiowait也令人煩惱，當(dāng)查詢大量冷的歷史數(shù)據(jù)時(shí)，漫長(zhǎng)的加載時(shí)間也讓人崩潰。我們?cè)跍y(cè)試環(huán)境的Zabbix平臺(tái)，納管了幾倍于生產(chǎn)環(huán)境的主機(jī)數(shù)量，可以當(dāng)成是一個(gè)實(shí)打?qū)嵉膲簻y(cè)場(chǎng)景。為了尋求最佳實(shí)踐，我們?cè)跍y(cè)試環(huán)境先后測(cè)試了TokuDB、RocksDB、TiDB、Elasticsearch、TimescaleDB等數(shù)據(jù)庫(kù)產(chǎn)品，其中我們基于4.8版本的Z