背景

團隊所開發的持續監測網站/APP的產品，需要有一項監控功能，具體來說就是，對URL/域名進行週期性（小於1分鐘）監測，並且能對異常事件進行實時告警。在最近這幾個月，我一直將大部分時間和精力花在了設計開發這套系統上面，一共經歷了兩個大版本。下文就對這套監控系統進行介紹，分享給大家。

自己之前沒有這類系統的開發設計經驗，於是問了下週圍同事。和同事討論的結果是：既然現在人手不夠（就我一個人），我之前也沒開發過這類系統，時間又比較緊迫（領導給的排期是“越快越好”……），那麼找一個已有的開源監控系統進行二次開發，應該是一個不錯的選擇。那麼，選擇哪種開源監控系統呢？根據同事以往的經驗，可以考慮zabbix，自己也調研過一段時間zabbix，它的優點有如下幾條：

• 架構簡單、清晰

• 文件豐富，程式碼註釋十分詳細

• agent/server部署方便

• 包含整套監控流程：包括採集、觸發、告警

• agent支援使用者自定義監控項

• 觸發器表示式豐富

• 暴露了一套HTTP + JSON的介面

另外，除了以上這樣，還有一個比較重要的一個原因：團隊中的同事之前也調研過zabbix。在人手不足、時間又緊的情況下，這一個因素的權重就顯得相對較高。所以，最終選擇了在zabbix基礎上進行二次開發。

至於使用docker，是考慮到監控的物件，會因為使用者的增長、以及使用者的操作，有動態的變化。作為設計者，自然希望有一種機制，能夠可程式設計地、動態地控制zabbix agent的數量。我們既不讓某一個agent（具體應該是agent的埠）有過多的監控項，導致監控項無法在一個週期內完成資料採集；又不想有生成過多的agent，造成系統資源的浪費。目前勢頭正勁的docker，怎能不進入我的視野？社群活躍、文件完善、相對其他虛擬化技術又很輕，都成為了我選擇docker的原因。

需求

這個監控系統的設計目標是：希望能夠提供秒級時間粒度的監控服務，實時監控使用者網頁的可用性指標，做到快速反饋。
具體的需求為：當用戶在我們的產品中建立持續監測任務，對於使用者輸入的URL進行兩種型別的監控，即HTTP返回碼以及PING返回時間。當某一類監控的取樣資料異常時——例如HTTP返回500、PING超時——就會在使用者介面上返回告警事件，用以提醒使用者；取樣資料正常時，再返回告警事件的狀態。

第一個版本

架構

第一個版本中，系統的設計特點為：

• 一臺物理伺服器對應一個zabbix的host

• 監控項使用被動採集方式

• 每個zabbix agent處於一個docker container內，每生成一個container，就在物理機上面開放一個埠，並生成一個對應的zabbix agent interface

• 對於上游的每個監控任務，會在每個IDC節點各生成了一組zabbix採集監控任務，具體對應關係為：(groupid, hostid, interfaceid, itemid, triggerid)

• 告警事件的生成，採用了輪詢trigger狀態的方式，當上遊監控任務對應的處於PROBLEM狀態的節點數大於總節點數時，產生告警事件；當所有節點均為OK狀態時，產生告警恢復事件

第一個版本的架構，如下圖所示：

Monitor Web模組，作為後端的介面供前端來呼叫，主要提供監測任務新增、修改、刪除，告警事件列表返回、告警事件刪除等功能。
Monitor Syncer模組，用於定期檢查每個監測任務對應的zabbix trigger的狀態，根據trigger的狀態，來生成告警事件以及告警恢復事件。
Zabbix Server和Zabbix Agent就構成了監控系統的核心服務。其中，一臺物理機器中，包含了多個Docker container，每個container中執行這一個zabbix agent。

流程

以建立監控任務為例，當前端發出建立監測任務時，Monitor Web模組接收到該請求，進行如下操作：

1. 在每一個IDC（對於zabbix中的group）中，各建立一個container，在container中啟動zabbix agent，記錄其對外開放的埠

2. 根據得到的埠，在zabbix host中，建立zabbix interface（和agent的埠一一對應）

3. 根據得到的interface，建立HTTP和PING兩種型別的zabbix item和trigger，分別監控URL的HTTP返回碼，以及host的PING返回值。zabbix server開始進行資料採集和監控

4. 在業務資料庫表中新增該條監測任務記錄

Monitor Syncer每隔一個週期（30s），掃描一遍目前所有監測任務，再從zabbix資料庫中查詢到對應trigger的狀態。如果trigger狀態為PROBLEM的超過了半數，那麼該監控任務就處於了告警狀態，最後再根據該任務目前是否處於告警狀態，來決定是否需要新增告警事件；那麼對應的，如果trigger狀態均為OK，並且目前任務處於告警狀態，那麼則需要為告警事件新增對應的恢復狀態。

這樣，就完成了新增任務 -> 告警 -> 恢復的整個監控系統的典型流程。

效能

對第一個版本進行了效能測試，得到了以下效能指標：

（3臺伺服器，1臺部署Zabbix Server，2臺部署Docker + Zabbix Agent。伺服器配置：Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz X 24，128G 記憶體，千兆網絡卡）

• 樣本採集項：1111 item

• 樣本採集頻率：60s

• 最大入口流量: 68 kbps

• 最大出口流量: 270 kbps

• 每秒下發採集請求： ~19 qps

存在的不足

因為開發時間所限，以及對於新技術的調研不夠深入，第一個版本有不少不足，主要體現如下：

• zabbix agent採用的是被動模式，每次採集資料zabbix server都需要向zabbix agent查詢監控項，網路出口資料量較大

• 由於資料採集都是進行需要發起網路操作，而每個採集資料的頻率又較高，因此會出現資料採集不完整、無法連續採集的現象

• 採用輪詢方式探測故障事件，效率較低，實時性不高，同時也有單點問題

• 任務請求沒有進行持久化，如果因為模組問題而丟失或操作失敗，無法回滾

第二個版本

升級點

針對第一版本發現的問題，在設計上做了一些升級，具體升級點和設計上面的特點如下：

• 不再採用物理機器和Zabbix Host一一對應的關係，而是採用Docker container和Zabbix Host一一對應（這裡的Zabbix Host就是一個虛擬Host的概念）

• 採用etcd進行分散式狀態管理，動態自主註冊Zabbix Host

• 採集項使用Agent自主上傳方式

• Zabbix Host和監控項之間的比例可配置，即配置每個Zabbix Host上最多進行的監控項數量

• 監控項自動轉移，如果一個Zabbix Host出現異常，系統可以將上面的監控項遷移至其他健康的Zabbix Host

• 藉助Zabbix Action，將異常狀態的改變實時傳遞給系統，而不是由系統進行輪詢

• 任何請求將進行持久化，方便檢視以及請求的回滾

第二版的架構變成了這樣：

上圖中，Monitor Web一方面接收前端的請求，它收到請求做的唯一的事情就是將請求資料寫入資料庫進行持久化；另一方面，它還會接收來自Zabbix Server的事件請求，這裡的事件表示trigger狀態的改變。

Monitor Admin有兩個職責：1）定期檢測未完成的請求（新增/刪除監控任務），拿到請求之後通過Zabbix API在對應的Zabbix Agent中新增/刪除監控項（item + trigger）；2）偵聽ETCD中的key狀態變化，進行相應地Zabbix Host建立/刪除，以及監控項的遷移。

每當啟動一個Docker container，就會將物理機的IDC、ETCD Server地址、Zabbix Server地址等引數傳遞至container，然後在內部啟動zabbix_agentd，並且定期檢查zabbix_agentd是否存活，如果存活的話，則生成一個唯一的key，向ETCD發起key建立/更新請求；如果不存活，則key會自然的過期。這樣，Monitor Admin就通過ETCD得知了各個zabbix_agentd的健康狀況，並且在記憶體中儲存一份agent的拓撲結構。

啟動了多個container，在Zabbix Server中就對應了多個Zabbix Host，如下圖所示：

其他方面調優

除了整體架構的升級，還在了許多方面（主要是Zabbix）進行了調優，比如：

儘量增加agent的超時時間

因為我們的監控採集項，都是需要對URL或者域名進行網路操作，這些操作往往都會比較耗時，而且這是正常的現象。因此，我們需要增加在Zabbix agent的採集超時，避免正常的網路操作還沒完成，就被判斷為超時，影響Server的資料獲取。

### Option: Timeout
#       Spend no more than Timeout seconds on processing
#
# Mandatory: no
# Range: 1-30
# Default:
# Timeout=3
Timeout=30

不要在採集指令碼中加上超時

既然Zabbix agent中已經配置了採集超時時間，就不需要在採集指令碼中新增超時了。一方面增加了維護成本，另一方面如果配置不當，還會造成Zabbix agent中的超時配置失效。（之前在指令碼中使用了timeout命令，由於設定不正確，導致採集項總是不連續，除錯了好久才查明原因。）

增加Zabbix Server的Poller例項

預設情況，用於接收Zabbix agent採集資料的Poller例項只有5個。對於週期在1分鐘內、數量會達到千級別的採集項來說，Poller例項顯然是不夠的，需要增大例項數，充分利用好伺服器資源。例如：

### Option: StartPollers
#       Number of pre-forked instances of pollers.
#
# Mandatory: no
# Range: 0-1000
# Default:
# StartPollers=5
StartPollers=100

利用好Zabbix trigger expression

如果只把trigger expression理解為“判斷某個item value大於/小於某個閾值”，那就太低估Zabbix的trigger expression了，它其實可以支援很多複雜的邏輯。比如，為了防止網路抖動，需要當最近的連續兩個採集項異常時，才改變trigger的狀態，表示式可以寫成：（假設item_key<0為異常）

{host:item_key.last(#1)}<0&{host:item_key.last(#2)}<0

再舉個例子，同樣是為了防止採集的服務不穩定，我們可以規定，當目前trigger的狀態為PROBLEM，並且最近5分鐘的採集資料均正常的時候，才可以將trigger狀態改為OK，表示式可以這樣寫：

({TRIGGER.VALUE}=0&{host:item_key.last(#1)}<0&{host:item_key.last(#2)}<0) | ({TRIGGER.VALUE}=1&{host:item_key.min(5m)}<0)

效能

測試環境：

3臺伺服器，硬體引數與之前保持一致

• Zabbix Server * 1

• 監控伺服器 * 1

• ETCD Server * 1

• Docker container * 500 （在1臺物理機中）

效能指標：

• 樣本採集項：7100

• 樣本採集頻率：60s

• Zabbix Server每秒處理監控項: 130 個監控項 / 秒 （第一版為~19 qps）

• 平均入口流量：454.25 kbps

• 最大入口流量：916.12 kbps （第一版為68 kbps）

• 平均出口流量：366.65 kbps

• 最大出口流量：1.68 Mbps （第一版為270 kbps）

部分效能指標的監測圖如下：

Zabbix Server每秒處理監控項數目

Zabbix Server網絡卡入口流量

Zabbix Server網絡卡出口流量

可以看出，跟第一版相比，最大可採集的資料量是原來的近7倍，Zabbix Server的進出口流量有明顯的提升，監控項的處理吞吐率也和採集項數量有了一致的提高，是原來的6.8倍，並且沒有出現監控項在一個週期內無法採集到的情況（如果再增加監控項，則會不定期出現取樣不連續的情況），效能提升還是比較明顯的。

系統截圖

故障事件列表

簡訊報警

總結

本文從架構上介紹瞭如果基於Zabbix以及Docker，構建一個監控系統。

（廣告時間，感興趣的朋友可以登入我們的官網進行註冊，使用我們的評測/監測/加速等服務，並且通過新增PC持續監測任務來對網站進行實時監控。）

當然，目前的版本仍然不夠完美，目前“抗住”了，然後需要考慮“優化”，年後預計會有較大改動，架構上以及技術上，自己已經在考量中。

（又是廣告時間，團隊急需後端小夥伴，可以通過我們的官網瞭解到我們的產品，也過年了，年終獎也發了，感興趣的、有想法的朋友，歡迎將簡歷傳送至[email protected]，謝謝！）

-- EOF --