摘要：和就構(gòu)成了監(jiān)控系統(tǒng)的核心服務(wù)。其中，一臺物理機器中，包含了多個，每個中運行這一個。性能對第一個版本進行了性能測試，得到了以下性能指標(biāo)臺服務(wù)器，臺部署，臺部署。

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

團隊所開發(fā)的持續(xù)監(jiān)測網(wǎng)站/APP的產(chǎn)品，需要有一項監(jiān)控功能，具體來說就是，對URL/域名進行周期性（小于1分鐘）監(jiān)測，并且能對異常事件進行實時告警。在最近這幾個月，我一直將大部分時間和精力花在了設(shè)計開發(fā)這套系統(tǒng)上面，一共經(jīng)歷了兩個大版本。下文就對這套監(jiān)控系統(tǒng)進行介紹，分享給大家。

自己之前沒有這類系統(tǒng)的開發(fā)設(shè)計經(jīng)驗，于是問了下周圍同事。和同事討論的結(jié)果是：既然現(xiàn)在人手不夠（就我一個人），我之前也沒開發(fā)過這類系統(tǒng)，時間又比較緊迫（領(lǐng)導(dǎo)給的排期是“越快越好”……），那么找一個已有的開源監(jiān)控系統(tǒng)進行二次開發(fā)，應(yīng)該是一個不錯的選擇。那么，選擇哪種開源監(jiān)控系統(tǒng)呢？根據(jù)同事以往的經(jīng)驗，可以考慮zabbix，自己也調(diào)研過一段時間zabbix，它的優(yōu)點有如下幾條：

架構(gòu)簡單、清晰

文檔豐富，代碼注釋十分詳細

agent/server部署方便

包含整套監(jiān)控流程：包括采集、觸發(fā)、告警

agent支持用戶自定義監(jiān)控項

觸發(fā)器表達式豐富

暴露了一套HTTP + JSON的接口

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

至于使用docker，是考慮到監(jiān)控的對象，會因為用戶的增長、以及用戶的操作，有動態(tài)的變化。作為設(shè)計者，自然希望有一種機制，能夠可編程地、動態(tài)地控制zabbix agent的數(shù)量。我們既不讓某一個agent（具體應(yīng)該是agent的端口）有過多的監(jiān)控項，導(dǎo)致監(jiān)控項無法在一個周期內(nèi)完成數(shù)據(jù)采集；又不想有生成過多的agent，造成系統(tǒng)資源的浪費。目前勢頭正勁的docker，怎能不進入我的視野？社區(qū)活躍、文檔完善、相對其他虛擬化技術(shù)又很輕，都成為了我選擇docker的原因。

這個監(jiān)控系統(tǒng)的設(shè)計目標(biāo)是：希望能夠提供秒級時間粒度的監(jiān)控服務(wù)，實時監(jiān)控用戶網(wǎng)頁的可用性指標(biāo)，做到快速反饋。
具體的需求為：當(dāng)用戶在我們的產(chǎn)品中創(chuàng)建持續(xù)監(jiān)測任務(wù)，對于用戶輸入的URL進行兩種類型的監(jiān)控，即HTTP返回碼以及PING返回時間。當(dāng)某一類監(jiān)控的采樣數(shù)據(jù)異常時——例如HTTP返回500、PING超時——就會在用戶界面上返回告警事件，用以提醒用戶；采樣數(shù)據(jù)正常時，再返回告警事件的狀態(tài)。

第一個版本中，系統(tǒng)的設(shè)計特點為：

一臺物理服務(wù)器對應(yīng)一個zabbix的host

監(jiān)控項使用被動采集方式

每個zabbix agent處于一個docker container內(nèi)，每生成一個container，就在物理機上面開放一個端口，并生成一個對應(yīng)的zabbix agent interface

對于上游的每個監(jiān)控任務(wù)，會在每個IDC節(jié)點各生成了一組zabbix采集監(jiān)控任務(wù)，具體對應(yīng)關(guān)系為：(groupid, hostid, interfaceid, itemid, triggerid)

告警事件的生成，采用了輪詢trigger狀態(tài)的方式，當(dāng)上游監(jiān)控任務(wù)對應(yīng)的處于PROBLEM狀態(tài)的節(jié)點數(shù)大于總節(jié)點數(shù)時，產(chǎn)生告警事件；當(dāng)所有節(jié)點均為OK狀態(tài)時，產(chǎn)生告警恢復(fù)事件

第一個版本的架構(gòu)，如下圖所示：

Monitor Web模塊，作為后端的接口供前端來調(diào)用，主要提供監(jiān)測任務(wù)添加、修改、刪除，告警事件列表返回、告警事件刪除等功能。
Monitor Syncer模塊，用于定期檢查每個監(jiān)測任務(wù)對應(yīng)的zabbix trigger的狀態(tài)，根據(jù)trigger的狀態(tài)，來生成告警事件以及告警恢復(fù)事件。
Zabbix Server和Zabbix Agent就構(gòu)成了監(jiān)控系統(tǒng)的核心服務(wù)。其中，一臺物理機器中，包含了多個Docker container，每個container中運行這一個zabbix agent。

以創(chuàng)建監(jiān)控任務(wù)為例，當(dāng)前端發(fā)出創(chuàng)建監(jiān)測任務(wù)時，Monitor Web模塊接收到該請求，進行如下操作：

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

根據(jù)得到的端口，在zabbix host中，創(chuàng)建zabbix interface（和agent的端口一一對應(yīng)）

根據(jù)得到的interface，創(chuàng)建HTTP和PING兩種類型的zabbix item和trigger，分別監(jiān)控URL的HTTP返回碼，以及host的PING返回值。zabbix server開始進行數(shù)據(jù)采集和監(jiān)控

在業(yè)務(wù)數(shù)據(jù)庫表中添加該條監(jiān)測任務(wù)記錄

Monitor Syncer每隔一個周期（30s），掃描一遍目前所有監(jiān)測任務(wù)，再從zabbix數(shù)據(jù)庫中查找到對應(yīng)trigger的狀態(tài)。如果trigger狀態(tài)為PROBLEM的超過了半數(shù)，那么該監(jiān)控任務(wù)就處于了告警狀態(tài)，最后再根據(jù)該任務(wù)目前是否處于告警狀態(tài)，來決定是否需要添加告警事件；那么對應(yīng)的，如果trigger狀態(tài)均為OK，并且目前任務(wù)處于告警狀態(tài)，那么則需要為告警事件添加對應(yīng)的恢復(fù)狀態(tài)。

這樣，就完成了添加任務(wù) -> 告警 -> 恢復(fù)的整個監(jiān)控系統(tǒng)的典型流程。

對第一個版本進行了性能測試，得到了以下性能指標(biāo)：

（3臺服務(wù)器，1臺部署Zabbix Server，2臺部署Docker + Zabbix Agent。服務(wù)器配置：Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz X 24，128G 內(nèi)存，千兆網(wǎng)卡）

樣本采集項：1111 item

樣本采集頻率：60s

最大入口流量: 68 kbps

最大出口流量: 270 kbps

每秒下發(fā)采集請求： ~19 qps

因為開發(fā)時間所限，以及對于新技術(shù)的調(diào)研不夠深入，第一個版本有不少不足，主要體現(xiàn)如下：

zabbix agent采用的是被動模式，每次采集數(shù)據(jù)zabbix server都需要向zabbix agent查詢監(jiān)控項，網(wǎng)絡(luò)出口數(shù)據(jù)量較大

由于數(shù)據(jù)采集都是進行需要發(fā)起網(wǎng)絡(luò)操作，而每個采集數(shù)據(jù)的頻率又較高，因此會出現(xiàn)數(shù)據(jù)采集不完整、無法連續(xù)采集的現(xiàn)象

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

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

針對第一版本發(fā)現(xiàn)的問題，在設(shè)計上做了一些升級，具體升級點和設(shè)計上面的特點如下：

不再采用物理機器和Zabbix Host一一對應(yīng)的關(guān)系，而是采用Docker container和Zabbix Host一一對應(yīng)（這里的Zabbix Host就是一個虛擬Host的概念）

采用etcd進行分布式狀態(tài)管理，動態(tài)自主注冊Zabbix Host

采集項使用Agent自主上傳方式

Zabbix Host和監(jiān)控項之間的比例可配置，即配置每個Zabbix Host上最多進行的監(jiān)控項數(shù)量

監(jiān)控項自動轉(zhuǎn)移，如果一個Zabbix Host出現(xiàn)異常，系統(tǒng)可以將上面的監(jiān)控項遷移至其他健康的Zabbix Host

借助Zabbix Action，將異常狀態(tài)的改變實時傳遞給系統(tǒng)，而不是由系統(tǒng)進行輪詢

任何請求將進行持久化，方便查看以及請求的回滾

第二版的架構(gòu)變成了這樣：

上圖中，Monitor Web一方面接收前端的請求，它收到請求做的唯一的事情就是將請求數(shù)據(jù)寫入數(shù)據(jù)庫進行持久化；另一方面，它還會接收來自Zabbix Server的事件請求，這里的事件表示trigger狀態(tài)的改變。

Monitor Admin有兩個職責(zé)：1）定期檢測未完成的請求（添加/刪除監(jiān)控任務(wù)），拿到請求之后通過Zabbix API在對應(yīng)的Zabbix Agent中添加/刪除監(jiān)控項（item + trigger）；2）偵聽ETCD中的key狀態(tài)變化，進行相應(yīng)地Zabbix Host創(chuàng)建/刪除，以及監(jiān)控項的遷移。

每當(dāng)啟動一個Docker container，就會將物理機的IDC、ETCD Server地址、Zabbix Server地址等參數(shù)傳遞至container，然后在內(nèi)部啟動zabbix_agentd，并且定期檢查zabbix_agentd是否存活，如果存活的話，則生成一個唯一的key，向ETCD發(fā)起key創(chuàng)建/更新請求；如果不存活，則key會自然的過期。這樣，Monitor Admin就通過ETCD得知了各個zabbix_agentd的健康狀況，并且在內(nèi)存中存儲一份agent的拓撲結(jié)構(gòu)。

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

除了整體架構(gòu)的升級，還在了許多方面（主要是Zabbix）進行了調(diào)優(yōu)，比如：

盡量增加agent的超時時間

因為我們的監(jiān)控采集項，都是需要對URL或者域名進行網(wǎng)絡(luò)操作，這些操作往往都會比較耗時，而且這是正常的現(xiàn)象。因此，我們需要增加在Zabbix agent的采集超時，避免正常的網(wǎng)絡(luò)操作還沒完成，就被判斷為超時，影響Server的數(shù)據(jù)獲取。

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

不要在采集腳本中加上超時

既然Zabbix agent中已經(jīng)配置了采集超時時間，就不需要在采集腳本中添加超時了。一方面增加了維護成本，另一方面如果配置不當(dāng)，還會造成Zabbix agent中的超時配置失效。（之前在腳本中使用了timeout命令，由于設(shè)置不正確，導(dǎo)致采集項總是不連續(xù)，調(diào)試了好久才查明原因。）

增加Zabbix Server的Poller實例

默認情況，用于接收Zabbix agent采集數(shù)據(jù)的Poller實例只有5個。對于周期在1分鐘內(nèi)、數(shù)量會達到千級別的采集項來說，Poller實例顯然是不夠的，需要增大實例數(shù)，充分利用好服務(wù)器資源。例如：

### 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了，它其實可以支持很多復(fù)雜的邏輯。比如，為了防止網(wǎng)絡(luò)抖動，需要當(dāng)最近的連續(xù)兩個采集項異常時，才改變trigger的狀態(tài)，表達式可以寫成：（假設(shè)item_key<0為異常）

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

再舉個例子，同樣是為了防止采集的服務(wù)不穩(wěn)定，我們可以規(guī)定，當(dāng)目前trigger的狀態(tài)為PROBLEM，并且最近5分鐘的采集數(shù)據(jù)均正常的時候，才可以將trigger狀態(tài)改為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

測試環(huán)境：

3臺服務(wù)器，硬件參數(shù)與之前保持一致

Zabbix Server * 1

監(jiān)控服務(wù)器 * 1

ETCD Server * 1

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

性能指標(biāo)：

樣本采集項：7100

樣本采集頻率：60s

Zabbix Server每秒處理監(jiān)控項: 130 個監(jiān)控項 / 秒 （第一版為~19 qps）

平均入口流量：454.25 kbps

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

平均出口流量：366.65 kbps

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

部分性能指標(biāo)的監(jiān)測圖如下：

Zabbix Server每秒處理監(jiān)控項數(shù)目

Zabbix Server網(wǎng)卡入口流量

Zabbix Server網(wǎng)卡出口流量

可以看出，跟第一版相比，最大可采集的數(shù)據(jù)量是原來的近7倍，Zabbix Server的進出口流量有明顯的提升，監(jiān)控項的處理吞吐率也和采集項數(shù)量有了一致的提高，是原來的6.8倍，并且沒有出現(xiàn)監(jiān)控項在一個周期內(nèi)無法采集到的情況（如果再增加監(jiān)控項，則會不定期出現(xiàn)采樣不連續(xù)的情況），性能提升還是比較明顯的。

本文從架構(gòu)上介紹了如果基于Zabbix以及Docker，構(gòu)建一個監(jiān)控系統(tǒng)。

（廣告時間，感興趣的朋友可以登錄我們的官網(wǎng)進行注冊，使用我們的評測/監(jiān)測/加速等服務(wù)，并且通過添加PC持續(xù)監(jiān)測任務(wù)來對網(wǎng)站進行實時監(jiān)控。）

當(dāng)然，目前的版本仍然不夠完美，目前“抗住”了，然后需要考慮“優(yōu)化”，年后預(yù)計會有較大改動，架構(gòu)上以及技術(shù)上，自己已經(jīng)在考量中。

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

-- EOF --