案例|銀行 | Zabbix 監(jiān)控架構(gòu)分享

一 zabbix 平臺(tái)概述

zabbix 是一個(gè)基于 Web 界面提供分布式系統(tǒng)監(jiān)視及網(wǎng)絡(luò)監(jiān)視功能的企業(yè)級(jí)開(kāi)源解決方案。它能監(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)表定制等渠道，在前端開(kāi)放了豐富的 RESTful API 供第三方平臺(tái)調(diào)用，整體架構(gòu)在當(dāng)下的 DevOps 的趨勢(shì)下顯得非常亮眼。

我們于 2017 年開(kāi)始接觸 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。

2017 年底在基礎(chǔ)架構(gòu)范圍內(nèi)試行的 Zabbix 系統(tǒng)，從 3.2 版本開(kāi)始逐步演進(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)也開(kāi)始對(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)維的工作模式。

在編寫(xiě)此文前不久，我們也順利完成應(yīng)用系統(tǒng)監(jiān)控遷移到 Zabbix 平臺(tái)，作為一名全程參與 Zabbix 系統(tǒng)推廣實(shí)施和自動(dòng)化開(kāi)發(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)控

數(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)控。

目前我們使用 SNMP Agent 的被動(dòng)方式定期巡檢硬件設(shè)備的基礎(chǔ)指標(biāo)，例如故障燈信號(hào)、電源功率、內(nèi)存信息、磁盤(pán)陣列等，代替人工巡檢的方式來(lái)實(shí)現(xiàn)異常捕獲，并對(duì)數(shù)據(jù)中心內(nèi)的所有設(shè)備做到硬件信息采集，定時(shí)更新至 CMDB。例如以下為部分華為 RH2288 V3 IBMC 監(jiān)控模板中自動(dòng)發(fā)現(xiàn)的配置：

Zabbix 配置硬件監(jiān)控的操作過(guò)程也非常便捷，大部分都是在網(wǎng)頁(yè)界面配置，只需要定義好 SNMP Agent/Trap 的接口或 IPMI 傳感器目標(biāo)端口后即可靈活定義監(jiān)控項(xiàng)。對(duì)于 IPMI 監(jiān)控的配置，主要是將傳感器的名稱(chēng)填入即可，目前我們對(duì) IPMI 的帶外監(jiān)控使用的相對(duì)較少，主要是部分浪潮 PC 服務(wù)器在使用，對(duì) IPMI 更多地考慮應(yīng)用于在如 VMware vSphere 的 DPM 等帶外管理上。

在硬件監(jiān)控選擇監(jiān)控協(xié)議時(shí)，保持的一項(xiàng)原則是：能用 SNMP 就不用其他，能用 SNMPv3 就不用 SNMPv2。因?yàn)?SNMP 在 Zabbix 中可以非常靈活的實(shí)現(xiàn)自動(dòng)發(fā)現(xiàn)，而 SNMPv3 可以提供更健壯的認(rèn)證機(jī)制，因?yàn)樵陂_(kāi)放硬件監(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)的靈活性，這也是依賴(lài)于 SNMP 設(shè)計(jì)的原理，借助樹(shù)結(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)維開(kāi)始，加上 Zabbix 對(duì) SNMP/IPMI 協(xié)議配置的操作非常方便，所以經(jīng)常可以根據(jù)廠家提供的 mib 文件及 mib 文檔說(shuō)明即可篩選出需要自定義的監(jiān)控，這樣既可以通過(guò)減少采集來(lái)降低管理系統(tǒng)的繁忙度，又能優(yōu)化監(jiān)控質(zhì)量。例如以下為根據(jù) Lenovo XCC 帶外管理系統(tǒng)的 mib 說(shuō)明（http://www.circitor.fr/Mibs/Html/L/LENOVO-XCC-MIB.php）來(lái)自定義配置的 ThinkSystem SR650 的 SNMPv3 監(jiān)控使用效果：

上圖中的電源、陣列、磁盤(pá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，然后在 Zabbix Proxy 上使用 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ù)值類(lèi)型。需要特別注意，snmpwalk 是遍歷，并不需要 OID 的完整值，而 snmpget 則是根據(jù)一個(gè)完整的 OID 來(lái)檢索，對(duì)應(yīng)于 Zabbix 則是 snmpwalk 類(lèi)似自動(dòng)發(fā)現(xiàn)，snmpget 類(lèi)似常規(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)那樣可以安裝 Zabbix Agent 來(lái)做數(shù)據(jù)采集。對(duì)于這種問(wèn)題的處理，我們積累的經(jīng)驗(yàn)是，首選使用 RESTful 等外部接口來(lái)獲取監(jiān)控?cái)?shù)據(jù)，在不支持此條件的情況下，在 Zabbix Proxy 服務(wù)器上通過(guò)自定義監(jiān)控封裝廠家推薦工具或方法來(lái)監(jiān)控。

Zabbix Agent 支持運(yùn)維人員自定義監(jiān)控，將執(zhí)行命令封裝成一個(gè) Zabbix Item Key 來(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)控類(lèi)為一份 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)。這類(lèi)被封裝的方法主要是 CLI、RESTful 和 SSH，例如以下我們目前對(duì)各產(chǎn)品使用的監(jiān)控方式：

除了跟廠家溝通對(duì)接 Zabbix 外，其實(shí)也可以借助開(kāi)源生態(tài)和 Zabbix 的合作推廣，也有很多企業(yè)與我們一樣會(huì)分享 Zabbix 的經(jīng)驗(yàn)、模板、工具到 Zabbix Share，可以斟酌篩選后使用。同時(shí)，Zabbix 也一直努力與其他廠家共同合作，共同推出每個(gè)廠家在 Zabbix 上的官方監(jiān)控模板，例如 DELL EMC 在 Zabbix 中推出的各個(gè)產(chǎn)品的監(jiān)控模板（https://www.zabbix.com/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，這類(lèi)對(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)控流程主要是依賴(lài) 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)名稱(chēng)、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)種類(lèi)多，每個(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ā)器的依賴(lài)關(guān)系。

操作系統(tǒng)的監(jiān)控都是使用 Zabbix Agent 方案來(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)容：

#?...

#?眾多?Zabbix?Proxy?中的兩個(gè)

ServerActive?=?10.10.32.1,10.10.32.2

#?其中?10.10.32.0/24?為當(dāng)前機(jī)房的?Zabbix?Proxy?節(jié)點(diǎn)網(wǎng)段

Server?=?127.0.0.1,10.10.32.0/24

#?Hostname?是這臺(tái)服務(wù)器的管理?IP

Hostname?=?10.10.33.1

這種配置主要是方便于 agent 在多個(gè) Proxy 中平移，在故障恢復(fù)、Zabbix 升級(jí)等場(chǎng)景下，可以非常便利的保證 agent 的持續(xù)有效。另外將本地回環(huán)地址也寫(xiě)入 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è) Install Zabbix Agent And Report 的 task，這樣通過(guò)實(shí)現(xiàn)配置的好的 vars 即可將此主機(jī)以標(biāo)準(zhǔn)命名添加到 Zabbix 中。而對(duì)于數(shù)量龐大的虛擬機(jī)，我們編寫(xiě)了一套 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)化如下：

首先，將模板細(xì)分為各個(gè)類(lèi)別作為基類(lèi)的 template，然后根據(jù)應(yīng)用場(chǎng)景來(lái)指定上層的模板由哪些基類(lèi)組合，避免太多的定制模板中近似功能的監(jiān)控帶來(lái)重復(fù)監(jiān)控。然后，對(duì)每個(gè)模板中的觸發(fā)器指定嚴(yán)格的依賴(lài)關(guān)系，避免告警的連帶觸發(fā)導(dǎo)致風(fēng)暴。例如 Linux 系統(tǒng)的分區(qū)容量監(jiān)控觸發(fā)器，我們制定了幾個(gè)水位線之間的依賴(lài)：

六 數(shù)據(jù)庫(kù)監(jiān)控

數(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)的模板，覆蓋了大部分 Oracle DBA 關(guān)心的監(jiān)控項(xiàng)。在 Zabbix 中專(zhuān)門(mén)使用一臺(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)題，這也依賴(lài)于 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ù)開(kāi)啟了哪些需要監(jiān)控的細(xì)節(jié)。目前我們編寫(xiě)了 OceanBase、巨杉數(shù)據(jù)庫(kù)、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 用戶(hù)讀取的。當(dāng)作為 MySQL RootService 的主機(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ī)則，例如 Discovery MySQL Replication Enable 會(huì)對(duì)發(fā)現(xiàn)的實(shí)例執(zhí)行 show slave status 命令，這里仍會(huì)調(diào)用 MySQL RootService 的腳本，如果發(fā)現(xiàn)目標(biāo)實(shí)例開(kāi)啟了主從，則會(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)控還需要將連接的用戶(hù)與密碼寫(xiě)入到 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)控為例，以下從 OB RootService 自動(dòng)發(fā)散出 OB Zone、OB Tenant、OB Server、OB Partition 等監(jiān)控細(xì)節(jié)。

七 應(yīng)用監(jiān)控

當(dāng)監(jiān)控的考慮維度上升至應(yīng)用組件時(shí)，我們依舊堅(jiān)持使用自動(dòng)化的方式去面對(duì)眼花繚亂的監(jiān)控需求，思考如何讓?xiě)?yīng)用的監(jiān)控更加富有生命力，同時(shí)也分析了在過(guò)去使用 Nagios 進(jìn)行應(yīng)用監(jiān)控時(shí)遇到的痛點(diǎn)，最終，編寫(xiě)一個(gè)框架級(jí)別的工具，接管應(yīng)用的監(jiān)控生命周期。這個(gè)框架在我們內(nèi)部稱(chēng)為 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)維人員僅需要編寫(xiě)一份應(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)部稱(chēng)之為基類(lèi)，所有的模塊監(jiān)控會(huì)有一個(gè)自動(dòng)發(fā)現(xiàn)規(guī)則與基類(lèi)交互，如果基類(lèi)聲明文件里包含了請(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)用的階段，也是與基類(lèi)交互的，只不過(guò)基類(lèi)會(huì)根據(jù)其模塊名來(lái)調(diào)用同步過(guò)來(lái)的模塊方法的固定接口，這些接口是編寫(xiě)這類(lèi)模塊的開(kāi)發(fā)準(zhǔn)則，目的是為了保證基類(lèi)能夠順利調(diào)用并解析。

把考慮對(duì)象限制在一臺(tái)主機(jī)上，簡(jiǎn)化這個(gè)流程，可以有如下的時(shí)間線，由上至下是時(shí)間前進(jìn)的方向。

Zabbix Proxy 會(huì)調(diào)用 Discovery APP 自動(dòng)發(fā)現(xiàn)，觸發(fā)主機(jī)初始化一次當(dāng)前的 zbx_app 基類(lèi)，基類(lèi)收到信號(hào)后也會(huì)掃描環(huán)境，主要是收集各目錄下的聲明文件（lps.cfg），并根據(jù)聲明文件做一次基礎(chǔ)環(huán)境配置拉取，然后返回 Zabbix Proxy 相關(guān)信息。

Zabbix Proxy 收到了基類(lèi)生效，其他模塊的自動(dòng)發(fā)現(xiàn)也會(huì)緊隨著對(duì)主機(jī)做一次探測(cè)，發(fā)送各自的自動(dòng)發(fā)現(xiàn)信號(hào)。

基類(lèi)發(fā)現(xiàn)聲明文件里存在 redis 的模塊聲明，那么會(huì)把內(nèi)部信息整合為自動(dòng)發(fā)現(xiàn)返回結(jié)構(gòu)體，Zabbix Proxy 感知后會(huì)生成對(duì)應(yīng)的監(jiān)控項(xiàng)。

Redis 模塊持續(xù)發(fā)送監(jiān)控快照請(qǐng)求至基類(lèi)，基類(lèi)收到后會(huì)調(diào)用已經(jīng)從 HTTPFileServer 上拉取下來(lái)的 redis 模塊來(lái)執(zhí)行監(jiān)控請(qǐng)求，并返回結(jié)果集。

如果過(guò)程中應(yīng)用維護(hù)人員將 url 模塊的監(jiān)控需求寫(xiě)入聲明文件，下一次接收到 Discovery APP 信號(hào)時(shí)，基類(lèi)會(huì)發(fā)現(xiàn)新增聲明，迅速前往 HTTPFileServer 拉取指定版本的 url 監(jiān)控模塊。后續(xù) URL 的監(jiān)控也會(huì)與 Redis 一樣持續(xù)生效，直至聲明文件刪除或注釋了此模塊。

如果過(guò)程中自動(dòng)化開(kāi)發(fā)人員對(duì)版本庫(kù)里的 redis 模塊更新了代碼，基類(lèi)也會(huì)在下一次接收到 Discovery APP 信號(hào)后對(duì)比 MD5 列別發(fā)現(xiàn)版本更新，從而拉取替換為最新版本。

使用自管理的基類(lèi)實(shí)現(xiàn)了應(yīng)用監(jiān)控的閉環(huán)納管，監(jiān)控的操作上，細(xì)分了自動(dòng)化開(kāi)發(fā)人員開(kāi)發(fā)模塊職能，也給應(yīng)用維護(hù)人員更多的自由度去聲明自己需要的應(yīng)用監(jiān)控。而且，對(duì)基類(lèi)的動(dòng)作也納入一個(gè)監(jiān)控項(xiàng)，能保證基類(lèi)自己的穩(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)維人員也開(kāi)始更往上地關(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è)界面直接編寫(xiě) 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ù)查詢(xún)，再通過(guò) Zabbix 的告警渠道發(fā)送告警信息給全行訂閱了這個(gè)業(yè)務(wù)系統(tǒng)的技術(shù)人員。直接在網(wǎng)頁(yè)界面編寫(xiě) SQL 能夠適應(yīng)業(yè)務(wù)查詢(xún)的多變性，當(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è)端開(kāi)來(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 用戶(hù)可訪問(wèn)，修改由特殊用戶(hù)修改。

規(guī)范 SQL 編寫(xiě)規(guī)則，不允許出現(xiàn)執(zhí)行成本較大的語(yǔ)句，這也需要跟 DBA 溝通好。

盡可能地讓結(jié)果集返回一行甚至一行一列。

把數(shù)據(jù)計(jì)算操作分?jǐn)偨o Zabbix 預(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)。例如不僅僅是用戶(hù)登錄系統(tǒng)進(jìn)行交易后才觸發(fā)一次失敗才產(chǎn)生數(shù)據(jù)被監(jiān)控，而是周期性地去探測(cè)一次交易前置條件，即便在沒(méi)有客戶(hù)進(jìn)行交易時(shí)，也會(huì)有 Zabbix 在交易頁(yè)面上探測(cè)需要資源是否具備。這樣能夠保證比真實(shí)客戶(hù)更早的發(fā)現(xiàn)一些交易平臺(tái)的頁(yè)面異常，在邏輯上實(shí)現(xiàn)了”預(yù)知“的效果。另外，可以通過(guò)多個(gè)運(yùn)營(yíng)商線路去做頁(yè)面監(jiān)控，更加全面地覆蓋客戶(hù)案例，在發(fā)現(xiàn)異常時(shí)，也能夠?qū)Ρ绕渌€路是否存在運(yùn)行商的網(wǎng)絡(luò)問(wèn)題，例如 CDN、黑名單等。

我們使用 Zabbix Web 的監(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)開(kāi)發(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ì)此，我們決定使用自建外部渠道加 Zabbix Sender 實(shí)現(xiàn)外部平臺(tái)以監(jiān)控流的方式對(duì)接至 Zabbix，這樣既能既能避免對(duì)原有第三方監(jiān)控系統(tǒng)的侵入，也能讓其監(jiān)控?cái)?shù)據(jù)匯聚到 Zabbix。

首先，這里介紹一下 Zabbix Sender 的原理。當(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)支持 HTTP RESTful 的監(jiān)控對(duì)接時(shí)，將其對(duì)接至一個(gè)專(zhuān)門(mén)負(fù)責(zé)接受此類(lèi)告警的 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è)爬蟲(chóng)、數(shù)據(jù)庫(kù)監(jiān)控等方式，當(dāng)這樣也會(huì)丟失監(jiān)控流式的特性。

以目前遇到的情況，幾乎沒(méi)有第三種情況，一般都是提供 HTTP 外推監(jiān)控或告警的，所以這類(lèi)都會(huì)接入到我們一個(gè)使用 Golang 編寫(xiě)的專(zhuān)用 HTTP 服務(wù)器，在每次新增對(duì)接平臺(tái)時(shí)，增加對(duì)應(yīng)的 handler 中的 OtherReader 和 ZBXSender 接口實(shí)現(xiàn)即可。但需要注意對(duì)于這種方式的觸發(fā)器，需要著重關(guān)心 change()/diff() 函數(shù)的依賴(lài)，因?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)題，我們也不斷地嘗試各種方法，目前也依舊在努力尋求突破。

我們編寫(xiě)了一個(gè)內(nèi)部命名為 Zabbxi Robot 的工具，可以按照預(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)方法都是把告警信息以 curl POST 的方式傳送給 Zabbix Robot，不同點(diǎn)在于兩者使用了不同的 Header，從而在 Zabbix Robot 中區(qū)分出具體的渠道，也會(huì)對(duì)此過(guò)濾。Zabbix Robot 是我們使用 Golang 開(kāi)發(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)）樣本中的 hostid*X+itemid*Y+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ò)程理解為 Labels 和 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)行了一定的定制開(kāi)發(fā)，將常用的一些報(bào)表對(duì)接至 Zabbix。同時(shí)，Zabbix 也提供了資產(chǎn)清單、自定義拓?fù)洹ashboard 等功能，具備了一定的報(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ò)樹(shù)形圖的形式，展示出每個(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ò)開(kāi) Housekeeping）將 Zabbix 中排除 history* 的表和 zabbix web 前端文件備份到災(zāi)備機(jī)房。如果發(fā)生不可恢復(fù)的故障，可以重新部署 Zabbix Server，并恢復(fù)數(shù)據(jù)庫(kù)，這樣的代價(jià)僅會(huì)丟失歷史數(shù)據(jù)和趨勢(shì)，但能夠快速恢復(fù)監(jiān)控運(yùn)行的狀態(tài)。

此外，建議 Zabbix Agent 的被動(dòng)模式 Server 的地址配置為 Proxy 的網(wǎng)段，這樣當(dāng) Proxy 出現(xiàn)故障時(shí)，也能夠快速平移至其他 Proxy。

十四 未來(lái)規(guī)劃

在我們使用 Zabbix 的兩年里，運(yùn)維也開(kāi)始了全面的自動(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)。

目前生產(chǎn)使用的 Zabbix 數(shù)據(jù)庫(kù)架構(gòu)是 Zabbix 4.4 + Percona 8.0 + TokuDB，TokuDB 主要是用于 history* 表，并且對(duì) history* 表都進(jìn)行了分區(qū)，而其他的配置表仍是使用 Innodb，TokuDB 使用 QUICKLZ 的壓縮算法。另外，對(duì)數(shù)據(jù)庫(kù)的配置進(jìn)行了優(yōu)化，例如雙 1 這類(lèi)需要性能成本的設(shè)置也統(tǒng)統(tǒng)改為性能為主。在剛遷移到這個(gè)架構(gòu)時(shí)，壓縮率和歷史數(shù)據(jù) QPS 都有非常顯著的提升，但是隨著監(jiān)控項(xiàng)數(shù)量的增加，也開(kāi)始慢慢感受到了瓶頸與壓力。歷史數(shù)據(jù)即便開(kāi)了壓縮也不能抑制上漲的趨勢(shì)，而開(kāi)啟管家后每次刪除過(guò)期數(shù)據(jù)帶來(lái)的 CPU iowait 也令人煩惱，當(dāng)查詢(xún)大量冷的歷史數(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 版本的 Zabbix 稍微改造了一個(gè)兼容 TiDB 3.0 的版本（https://github.com/AcidGo/zabbix_tidb），但無(wú)奈于 TiDB 對(duì)外鍵的支持并沒(méi)有符合使用的預(yù)期，不過(guò)對(duì)于歸檔歷史庫(kù)也許是不錯(cuò)的選擇。在測(cè)試后，發(fā)現(xiàn) Zabbix 5.0 + PostgreSQL TimescaleDB 12 的效果較為理想，作為時(shí)序數(shù)據(jù)庫(kù)解決方案，對(duì)于 history* 表的追加與范圍查找都非常適合應(yīng)用場(chǎng)景，而且也支持指定天數(shù)外的壓縮，整體對(duì)比起來(lái)優(yōu)于目前使用的 TokuDB 方案。此外，我們也會(huì)考慮使用一個(gè)數(shù)據(jù)庫(kù)作為歸檔歷史數(shù)據(jù)，開(kāi)啟更高的壓縮率，然后單獨(dú)部署一個(gè)只讀的 Zabbix Server 來(lái)進(jìn)行訪問(wèn)，從而把溫?zé)釘?shù)據(jù)分離開(kāi)來(lái)。

不同于 MySQL 或其他輕量一些的數(shù)據(jù)庫(kù)，Oracle 的連接需要耗費(fèi)巨大的成本，不單單是龐大的外部驅(qū)動(dòng)，還有 F5 架構(gòu)下的擇路，加上龐大的監(jiān)控項(xiàng)，經(jīng)常會(huì)出現(xiàn)部分監(jiān)控?cái)D在任務(wù)隊(duì)列里。目前已經(jīng)實(shí)現(xiàn)了應(yīng)用監(jiān)控的改造，對(duì) MySQL、OceanBase、巨杉數(shù)據(jù)庫(kù)等的監(jiān)控也更換為更輕便、更自動(dòng)化的方案，因此也計(jì)劃著對(duì) Oracle 數(shù)據(jù)庫(kù)監(jiān)控方法的改造。首先是編寫(xiě)一個(gè)連接池中間件，管理每個(gè)庫(kù)的連接會(huì)話，Zabbix Agent 對(duì)數(shù)據(jù)庫(kù)的檢測(cè)將通過(guò) RPC 來(lái)調(diào)用中間件并返回結(jié)果，減少會(huì)話創(chuàng)建與銷(xiāo)毀的開(kāi)銷(xiāo)。然后，規(guī)劃一次查詢(xún)盡可能多地獲取批量數(shù)據(jù)，例如可一次獲取所有表的當(dāng)前表空間使用率，依靠 Zabbix 的監(jiān)控項(xiàng)相關(guān)項(xiàng)和預(yù)處理，獲取一個(gè)時(shí)間點(diǎn)上的多項(xiàng)監(jiān)控，從而減少 RPC 調(diào)用頻率。

目前我們的自動(dòng)化成效顯著，自動(dòng)化工具庫(kù)里提供了多種解決方案的處理操作，我們預(yù)計(jì)未來(lái)低級(jí)別的告警，可以借助這種強(qiáng)大的自動(dòng)化能力，來(lái)實(shí)現(xiàn)自動(dòng)痊愈的機(jī)制。

在一些鏈?zhǔn)郊軜?gòu)的場(chǎng)景，我們非常希望可以借助 Zabbix 的自動(dòng)發(fā)現(xiàn)主機(jī)的功能不斷沿著架構(gòu)分層往下分岔衍生新的主機(jī)或主機(jī)群組，例如巨杉數(shù)據(jù)庫(kù)中 Domain -> Database -> CollectionSpace -> Collection 的鏈?zhǔn)桨l(fā)現(xiàn)機(jī)制。但是在實(shí)際測(cè)試中，自動(dòng)發(fā)現(xiàn)主機(jī)的功能僅能觸發(fā)一次，下一層的自動(dòng)發(fā)現(xiàn)會(huì)丟失已經(jīng)選中的模板。相關(guān)問(wèn)題也反饋在了 Zabbix Forum（https://www.zabbix.com/forum/zabbix-help/404802-how-to-nesting-automatically-discovers-hosts-did-i-encounter-a-bug）。期待以后有類(lèi)似的靈活方案可以實(shí)現(xiàn)這種順延架構(gòu)脈絡(luò)的方式創(chuàng)建各個(gè)層面的主機(jī)監(jiān)控。

容器的發(fā)展在近幾年突飛猛進(jìn)，各種編排平臺(tái)也層出不窮，從 Swarm 到 Kubernetes，容器監(jiān)控的演進(jìn)也循循漸進(jìn)。Zabbix 在 4.0 之后支持了 Prometheus 數(shù)據(jù)采集，對(duì)容器監(jiān)控踏出了堅(jiān)定的一步，加上結(jié)合 LDD macros 可以更靈活地對(duì)接 JSON 格式，未來(lái)可以將兩者結(jié)合起來(lái)，實(shí)現(xiàn)自動(dòng)化的、容器級(jí)別的智能監(jiān)控。

從我們?cè)诰帉?xiě)其他運(yùn)維工具的經(jīng)驗(yàn)來(lái)看，Golang 非常適合運(yùn)維管理的二進(jìn)制工具開(kāi)發(fā)，強(qiáng)大的并發(fā)能力、靜態(tài)語(yǔ)言的穩(wěn)定可靠和較低的學(xué)習(xí)成本，都讓工具的質(zhì)量得到顯著提升。Zabbix 近期推出的 agent2 也由 Golang 開(kāi)發(fā)，并且提供了接口規(guī)范，讓運(yùn)維人員可以定制最合適的 Zabbix Agent。這一點(diǎn)，我們也在測(cè)試環(huán)境中探索，逐漸了解開(kāi)發(fā)流程，相信不久后會(huì)隨著生產(chǎn)環(huán)境 Zabbix 升級(jí)至 5.0 時(shí)同時(shí)推廣強(qiáng)大的 agent2。

Zabbix 系統(tǒng)的推廣、配套工具的開(kāi)發(fā)、監(jiān)控依賴(lài)的細(xì)分、從舊監(jiān)控系統(tǒng)進(jìn)行遷移的推進(jìn)，都是我們眾多運(yùn)維人員在這兩年多的時(shí)間里，不斷積累和創(chuàng)新出來(lái)的成果，在此由衷地感謝我們每一位運(yùn)維人員的努力，也寄予堅(jiān)定的自信去實(shí)現(xiàn)未來(lái)規(guī)劃的監(jiān)控系統(tǒng)愿景。

Zabbix 運(yùn)維

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。