摘要：和就構成了監控系統的核心服務。其中，一臺物理機器中，包含了多個，每個中運行這一個。性能對第一個版本進行了性能測試，得到了以下性能指標臺服務器，臺部署，臺部署。

（原文地址：https://blog.goquxiao.com/posts/2015/02/17/ji-yu-zabbix-dockerkai-fa-de-jian-kong-xi-tong/）

團隊所開發的持續監測網站/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模塊接收到該請求，進行如下操作：

在每一個IDC（對于zabbix中的group）中，各創建一個container，在container中啟動zabbix agent，記錄其對外開放的端口

根據得到的端口，在zabbix host中，創建zabbix interface（和agent的端口一一對應）

根據得到的interface，創建HTTP和PING兩種類型的zabbix item和trigger，分別監控URL的HTTP返回碼，以及host的PING返回值。zabbix server開始進行數據采集和監控

在業務數據庫表中添加該條監測任務記錄

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)

具體可以參考Trigger expression

測試環境：

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持續監測任務來對網站進行實時監控。）

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

（又是廣告時間，團隊急需后端小伙伴，可以通過我們的官網了解到我們的產品，也過年了，年終獎也發了，感興趣的、有想法的朋友，歡迎將簡歷發送至hr@mmtrix.com，謝謝！）

-- EOF --