【51CTO.com原創稿件】 IT 運維離不開系統監控，就好像魚兒離不開水一樣。一款強大的監控系統可以有力保證設備和業務的穩定。
圖片來自 Pexels
在監控系統層出不窮的今天，作為老牌監控系統的 Zabbix 依然屹立在監控系統之林。今天，我們來看看 Zabbix 的系統架構以及運作方式。
Zabbix 系統架構
眾所周知，Zabbix 是一款優秀的監控系統，可以針對互聯網中的設備和應用進行監控。
在詳細介紹其實現方式之前，先來看看它的結構圖：
Zabbix 架構圖
從上圖可以看出，綠色的部分就是被監控的設備，這個設備的類型可以是服務器，交換機或者是網絡打印機。
這些被監控的設備被稱作為 Host，設備的分組稱作 Host Group，分組可以根據地域，機房，應用來劃分。
從橙色部分-監控方式可以看出，針對每個 Host，Zabbix 會安裝 Zabbix Agent。
它是 Zabbix 在 Host 上的客戶端，負責將 Zabbix 需要監控的信息上傳到 Zabbix Server 進行分析和處理。
但並不是所有的網絡設備都可以安裝 Zabbix Agent，針對無法安裝的設備，只要支持 SNMP(Simple Network Management Protocol，簡單網絡管理協議)或者 IPMI(Intelligent Platform Management Interface，智能平臺管理接口)也是可以被監控到的。
另外，如果需要監控 Java 應用程序，也可以通過 JMX 來實現。
同樣從橙色部分監控內容可以看出，Zabbix 通過 JMX 支持 Java 應用程序監控;通過 IPMI 支持硬件設備監控;通過 SNMP 支持網絡設備。
綠色區域與藍色的 Zabbix Server 之間有一個雙向的箭頭，由 Zabbix Agent 直接到 Zabbix Server 的方式被稱為通用結構，類似常說的 C/S 架構。
但在實際應用中更多的使用分佈式架構，也就是通過綠色區域先連接到黃色的 Zabbix Proxy，然後再連接到藍色 Zabbix Server 的這條路徑。
在圖右邊橙色的區域，是Zabbix的監控服務器，其中 Zabbix Server 主要負責配置和接受/發送監控信息(更多詳細功能後面介紹)。
處理完畢的信息會存儲到 Database 中，這裡的 Database 可以指定 MySQL 或者 Oracle 以及其他數據庫源。
另外，還會提供 Zabbix UI 展示配置和監控信息。不僅如此，還為第三方應用提供了 Zabbix API，通過它來客製化 Zabbix 規則。
當然從穩定性考慮，可以通過 Keepalive 之類的軟件建立 Master，Slave 的 HA 機制。
Zabbix 構建監控系統過程
前面通過一張大圖介紹了 Zabbix 的體系結構，詳細對 Zabbix 的基本工作原理有了瞭解。
順著這個思路再來看看，Zabbix 架構安裝和配置步驟：
Zabbix 架構部署和配置示意圖
PS：下面會介紹 Zabbix 的整個部署和配置過程，涉及到安裝和配置的部分，都沒有標註具體的命令。
如果有需要安裝和配置過程的同學，可以下載 Zabbix 用戶手冊，這裡因為篇幅的原因不展開描述。
Zabbix Server/Agent/UI 安裝配置
在 Zabbix 監控服務器上，安裝 Zabbix Server 和 Zabbix UI(Web)。
Zabbix Server 用來接受和發送監控詳細，Zabbix UI(Web)用來對 Zabbix Server 的各項功能進行配置。
同時在被監控設備上，安裝 Zabbix Agent。在其安裝完畢以後，需要通過 zabbix_agenttd.conf 文件，對 Server 和 ServerActive 兩個參數進行配置。
由於 Zabbix Agent 有被動模式和主動模式。被動模式，是 Zabbix Server 從 Zabbix Agent 上獲取數據。
而主動模式，是 Zabbix Agent 主動將信息上傳到 Zabbix Server。因此，這兩個參數的內容都指的是 Zabbix Server 的 IP 地址。
Server 配置的是被動模式 Zabbix Server 的 IP，ServerActive 配置的是主動模式 Zabbix Server 的 IP。
當然，除此之外還需要更新防火牆配置，並打開 Zabbix 的訪問端口(10050 和 10051)。
最後，給這個被監控的設備(Host)，起一個 Hostname，這個名字會在 Zabbix Server 端配置的時候用到。
Server 和 ServerActive 配置項
Host Groups/Hosts 配置
搞定 Zabbix Agent 以後，回到 Zabbix Server 上進行配置。前提是 Zabbix Server 和 Zabbix UI(Web)已經安裝完畢，可以通過 Zabbix UI(Web)訪問配置界面。
上文提到，每個被監控的設備，都是一個 Host，那麼將多個 Host 按照某種方式分組，這個分組就是 Host Groups。這裡的分組方式有地理位置，業務單位，機器用途，系統版本等等。
建立一個 Host Groups，然後在其中建立一個 Host，這個 Host 就是剛才安裝 Zabbix Agent 的設備在 Zabbix Server 上的概念設備。
在配置 Host 的時候，需要注意這裡的 HostName 和被監控設備中定義的 HostName 保持一致，方便辨識。配置的 IP 就是被監控設備的 IP，端口號是 10050。
在 Zabbix Server 創建 Host 配置
Items 配置
配置完 Host 之後，就需要告訴 Zabbix 監控 Host 中的什麼數據。這個要監控的數據就是監控項，也叫 Items。
Items 配置包括監控數據的方式，取值的數據類型，獲取數值的間隔，歷史數據保存時間，趨勢數據保存時間，監控 Key 的分組等信息。
首選，需要選擇 Type，它是要監聽的 Zabbix 客戶端的類型。一般來說，在安裝 Zabbix Agent 以後，這個類型就是 Zabbix Agent。也可以選擇 SNMP，IMPI 或者其他類型。
其次，需要注意 Key 的選擇，Key 是來確定具體監控項的，對於同一個 Host 來說它是唯一的。
Zabbix 默認就帶有一些 Key 可供選擇，例如：vm.memory.size[total]，就是獲取內存大小的 Key。
由於是針對 Host 進行配置的，所以也會指定對應的 Host IP 和 Port。另外，還有一些其他的數據需要配置。
例如：數據更新間隔，更新週期，歷史數據保存天數，趨勢數據保存天數等等。
Items 配置示例圖
細心的同學會發現上圖中還有一個 Applications 的選項。它實際上是對 Items 的一個集合，例如：要監控 MySQL，可以定義一個 MySQL 的 Application。
把相關的 Items 包括 availability of MySQL，disk space，processor load，transactions per second，number of slow queries 全部放到這個 Application 中方便選擇和管理。
Trigger 配置
前面提到，Items 是用來配置監控什麼數據的，而不判斷數據是否正常。那麼，Trigger 的作用就是對採集的數據進行判斷。
通常會設置判斷規則或者閥值，一旦滿足某種規則或者超過對應的閥值就會產生一個事件。
同時，Action 會對滿足條件的 Trigger 執行操作。這些規則通過正則表達式來定義。
從接收消息到觸發動作示意圖
信息經過表達式判斷，會產生兩類 Trigger 狀態，OK(正常)和 PROBLEM(異常)。
每個 Trigger 會對應一個 Items，每個 Items 會對應多個 Trigger。同時，Trigger 又可以設置不同的事件級別，可以根據這些級別設置多重告警。
Trigger 事件級別示意圖
在配置 Trigger 的時候主要是添加正則表達式。Zabbix 會根據對應 Item 的 Function 生成對應的正則表達式。
Trigger 會根據監控的內容(Item)來配置，例如：Item 是檢測 Linux 的登陸人數。選擇 Item 為“Template OS linux：Number of logged in users”。
對應的 Function 是 Last(most recent) T value is = N。意思是獲取最近登陸的人數 T，當 T 等於 N 的時候觸發 Trigger。
這個 N 就是需要我們配置的值，比如填寫 2。也就是登陸人數等於 2 的時候觸發 Trigger。
當你配置完畢以後就會生成類似如下圖正則表達式了，{Template OS Linux:system.users.num.last()}>2。
整個過程不需要你輸入表達式，只要通過選擇和配置就可以完成。
Trigger 配置示例圖，內容和文中描述有差異，表達的意思相同
上圖有一個 Tab 項叫做 Dependencies，這個是 Trigger 的告警依賴，在實際場景中非常有用。
它會針對特殊場景使用，例如：整個 IDC 機房的路由出現故障，那麼機房所有的機器的網絡狀態都會出現異常，此時 Zabbix Server 會收到大量異常報警。運維人員會被報警信息淹沒，不知道故障的真正原因。
此時，就可以在 Dependencies 中選擇對應規則，並且勾選 Multiple PROBLEM events generation 選項。
之後，就會收到一條報警信息，“某某 IDC 機房路由器 X 發生故障”，對其他的報警信息做了聚合操作。
Action 配置
如果說 Trigger 定義觸發事件的規則，那麼 Action 就是事件觸發後的動作。即當 Trigger 條件被滿足以後，Action 會執行一些操作。
比如：發送事件通知(短信，釘釘，郵件)，遠程執行命令(重啟服務)。
Action 的配置需要遵從下圖幾個步驟：
Zabbix 中有多種事件類型，Trigger 只是其中一種，例如：自動發現監控設備，自動註冊監控設備等等。因此，先要選擇事件的來源，當然這裡我們選擇 Trigger 作為來源。
Action 選擇事件來源
然後，填寫 Action 的基本信息。例如：名字，主題，默認發送的信息內容，異常恢復主題，以及對應的信息內容。這裡的填寫可以是字符串，但是更多的會使用宏。
其實就是替換字符，比如{TRIGGER.STATUS} 表示觸發器的狀態，{ITEM.NAME} 表示監控項的名字。通過這些宏和字符串的拼接形成最終的信息。
如下圖顯示：
Action 基本信息
接下來，就是對條件的配置(Condition)。由於 Action 可以面對一個或者多個 Trigger，每日每個 Trigger 又有一個或者多個條件。
為了保證其靈活性，可以針對 AND，OR，AND/OR，對條件進行組合。
例如：可以用“AND”條件，將 Maintenance status not in maintenance (機器不在維護狀態)和 Trigger value = PROBLEM(觸發器異常)兩個條件(Condition)組合起來，意思是當兩個條件同時滿足時觸發後續操作。
Conditions 是配置示例圖
最後，就是操作(Operation)的配置。包括執行操作的時間間隔，執行次數，每次執行的間隔，操作類型(發送消息，執行命令)，發送給哪些用戶/用戶組等等。
Operation 配置示例圖
Template 配置
如果有很多監控設備需要配置，是有工作量的。於是，Zabbix 會將有相同 Item，Trigger，Application 等規則項放到一起，於是就有了模版(Template)。
當對同類型的設備需要配置監控項時，就可以選擇現成的模版。從而，減少運維工程師的工作量。在創建模版的時候，需要輸入模版名字，以及對應的分組。
模版基本信息
如果需要繼承模版，可以在 Linked template 中進行配置。模版繼承可以理解為模板嵌套。
例如，事先定義了一個基礎模板，Item 配置好了 CPU、內存、硬盤、網卡等信息。
如果需要在這個基礎模版上擴展其他模版，比如：MySQL 監控模版或者 Web 監控模板。那麼在配置模板的時候，就可以繼承於基礎模板，而不需要重新定義模版。
模版創建完畢後，就可以添加 Item，Trigger，Application 等信息，具體的方式類似 Item，Trigger 配置。
上面大段的文字講述了 Zabbix 構建監控系統的過程。為了方便記憶，這裡做個總結。
Zabbix 構建監控系統，先安裝 Zabbix Agent 到 Host 收集信息，Zabbix Server 用來獲取信息，Zabbix UI(Web)用來展示和配置信息。
Zabbix Agent 在 Host 中配置好監控服務器的 IP 和 Port 之後，回到 Zabbix Server 上，通過 Zabbix UI(Web)對要監控的 Host(被監控設備)進行配置。
依次配置：Item(監控什麼數據)，Trigger(故障觸發條件)，Action(故障觸發動作)。
Zabbix 監控方式
瞭解完了 Zabbix 的架構和 Zabbix 構建的過程，再來看看 Zabbix 的監控方式。前面談到的 Zabbix Agent 監控，只是 Zabbix 監控方式的一種。
針對不同情況，Zabbix 還提供了 SNMP，IPMI，JMX 等多種方式。即使是 Zabbix Agent 的方式，也分為主動和被動兩種。
下圖描述了 Zabbix 的幾種監控方式與 Zabbix Server 之間的關係：
Zabbix 監控方式邏輯圖
Zabbix Agent 監控方式
該方式有 Active(主動模式)和 Passive(被動模式)。Zabbix Server 和 Zabbix Agent 之間的通信是通過 Zabbix 專用協議完成的，數據格式為 JSON。
①Zabbix Agent 被動模式
默認情況下，Zabbix Agent 工作在被動模式下，是由 Zabbix Server 向 Zabbix Agent 獲取信息。
在安裝完 Zabbix Agent 以後，通過 zabbix_agentd.conf 文件中的 Server 參數，設置被動數據採集的 IP。
被動模式流程圖
Zabbix Agent 與 Zabbix Server 通訊流程如上圖：
- Zabbix Server 打開一個 TCP 連接。
- Server 發送一個 Key(agent.ping\\n)給 Zabbix Agent。
- Zabbix Agent 接收到請求，並且響應請求，發送內容為
- 的信息給 Zabbix Server。
- Server 接收返回的數據，並且進行處理。
- Server 關閉 TCP 連接。
②Zabbix Agent 主動模式
這種模式 Zabbix Agent 會主動上報監控信息到 Zabbix Server。可以通過 zabbix_agentd.conf 文件中的 ActiveServer 參數配置 Zabbix Server 的 IP。
同時需要配置 Zabbix Server 上 Items 的 Type，設置為 Zabbix agent(active)即可。
主動模式流程圖
依舊來看看主動流程圖：
- Zabbix Agent 向 Zabbix Server 建立一個 TCP 連接。
- Agent 請求需要檢測的數據列表。
- Server 響應 Agent，發送一個 Items 列表，包括 Item key 和 delay。
- Agent 響應請求。
- Server 接收請求數據，關閉 TCP。
SNMP 監控方式
它是一個標準的用於管理基於 IP 網絡設備的協議，包括：路由器，交換機，UPS，打印機。特別是當被監控設備無法安裝 Zabbix Agent 的時候。
先一起來看看 SNMP 的架構，如下圖：
SNMP 架構圖
NMS 是 Network Management System(網絡管理系統，又名網絡管理站)，這部分被集成到了 Zabbix Server 中了。
Agent 是 SNMP 訪問的代理，為設備提供 SNMP 的能力，負責設備與 NMS 進行通訊。
MIB(Management Information Base)是一個數據庫，包含了被管理設備維護的變量。例如：內存空間，磁盤大小。
它通常是以一個樹形結構存在的，每個葉子結點都保存一條數據，通過 OID(Object Identifier)唯一標識一條記錄。
MIB 樹形結構圖
例如上圖，想表示通用中的 System 參數，就通過 1.3.6.1.2.1.1。如果是私人企業的記錄，就是在 1.3.6.1.4.1 下面。
NMS 通過 SNMP 與設備上的 Agent 進行通信，獲取/修改 MIB 上面的信息。目前 SNMP 有三個版本，每個版本都在之前版本的基礎上逐步升級。
SNMP 版本示例圖
以第三個版本為例，在原來請求和響應的基礎上，加入 PDU 算法對報文進行了加密和解密操作。
SNMPv3 版本傳輸示意圖
IPMI 監控方式
IPMI(Intelligent Platform Management Interface)即智能平臺管理接口，原本是 Intel 架構中企業系統的周邊設備採用的一種工業標準，後來成為業界的通用標準。
用戶可以通過 IPMI 監視服務器的物理特徵，例如：溫度，電壓，電風扇工作狀態，電源供應等。
IPMI 獨立於 CPU BIOS 和操作系統，也就是在缺少操作系統和管理軟件的情況下，依舊可以對硬件信息進行監控。在 Zabbix 中的具體配置，這裡不展開描述。
JMX 監控方式
JMX(Java Management Extensions)是為 Java 應用程序植入管理功能的框架。也是一套標準的代理和服務，用戶可以在任何 Java 應用程序中使用它。
在 Zabbix 中，JMX 監控數據的獲取由專門的代理程序來實現，即 Zabbix Java Gateway 負責採集數據，它和 JMX 的 Java 程序之間通信獲取數據。
Zabbix-Server 和 Zabbix Java Gateway 如下圖所示：
JMX 示意圖
這裡需要幾個步驟部署 JMX，如下：
- 選擇單獨的 Server 安裝 Zabbix Java Gateway，最好和 Zabbix Server 在不同的服務器上。
- 在安裝 Zabbix Java Gateway 的服務器上，針對 zabbix_java_gateway.conf 文件進行參數配置。主要是 Gateway 的監聽服務器的 IP 和 Port。目的是讓 Gateway 找到要監聽的設備。
- 在 Zabbix Server 配置 zabbix_server.conf 的參數。主要是配置 Gateway 的 IP 和 Port，以及 Java 監控的進程數。目的是讓 Server 找到 Gateway。
- 在被監控設備上，針對 Java 應用開啟 JMX 協議。
- 回到 Zabbix UI(Web)配置 JMX 監控的 Java 應用。
總結
作為老牌的監控系統，Zabbix 的架構包括了被監控設備和 Zabbix 監控服務器兩大部分。
Zabbix Agent 運行在被監控設備上，負責和 Zabbix Server 通信獲取和控制被監控設備，它有主動和被動兩種工作模式。
Zabbix Server 作為監控核心，可以直接與 Zabbix Agent 連接也可以通過 Zabbix Proxy 進行連接，再由 Zabbix Proxy 連接 Zabbix Agent。後面這種方式用在分佈式監控的場景。
Zabbix Server 獲取的數據存放到 Zabbix Server 的數據庫中，Zabbix UI(Web)可以讀取服務器中的數據，通過圖表的方式展示出來。
Zabbix 構建過程，分為安裝 Zabbix Agent/Server/UI，Host 配置，Item 配置，Trigger 配置，Action 配置。
這個配置過程完美地回答了，“監控誰?監控什麼?出現異常以後如何處理?”的問題。
最後，針對不同應用場景，Zabbix 還支持多種監控方式，有 Zabbix Agent，SNMP，IPMI 以及 JMX。
簡介：十六年開發和架構經驗，曾擔任過惠普武漢交付中心技術專家，需求分析師，項目經理，後在創業公司擔任技術/產品經理。善於學習，樂於分享。目前專注於技術架構與研發管理。
閱讀更多 51CTO 的文章
