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

背景

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

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

• 架構(gòu)簡(jiǎn)單、清晰

• 文檔豐富，代碼注釋十分詳細(xì)

• agent/server部署方便

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

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

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

• 暴露了一套HTTP + JSON的接口

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

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

需求

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

第一個(gè)版本

架構(gòu)

第一個(gè)版本中，系統(tǒng)的設(shè)計(jì)特點(diǎn)為：

• 一臺(tái)物理服務(wù)器對(duì)應(yīng)一個(gè)zabbix的host

• 監(jiān)控項(xiàng)使用被動(dòng)采集方式

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

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

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

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

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

流程

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

1. 在每一個(gè)IDC（對(duì)于zabbix中的group）中，各創(chuàng)建一個(gè)container，在container中啟動(dòng)zabbix agent，記錄其對(duì)外開(kāi)放的端口

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

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

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

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

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

性能

對(duì)第一個(gè)版本進(jìn)行了性能測(cè)試，得到了以下性能指標(biāo)：

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

• 樣本采集項(xiàng)：1111 item

• 樣本采集頻率：60s

• 最大入口流量: 68 kbps

• 最大出口流量: 270 kbps

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

存在的不足

因?yàn)殚_(kāi)發(fā)時(shí)間所限，以及對(duì)于新技術(shù)的調(diào)研不夠深入，第一個(gè)版本有不少不足，主要體現(xiàn)如下：

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

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

• 采用輪詢方式探測(cè)故障事件，效率較低，實(shí)時(shí)性不高，同時(shí)也有單點(diǎn)問(wèn)題

• 任務(wù)請(qǐng)求沒(méi)有進(jìn)行持久化，如果因?yàn)槟K問(wèn)題而丟失或操作失敗，無(wú)法回滾

第二個(gè)版本

升級(jí)點(diǎn)

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

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

• 采用etcd進(jìn)行分布式狀態(tài)管理，動(dòng)態(tài)自主注冊(cè)Zabbix Host

• 采集項(xiàng)使用Agent自主上傳方式

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

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

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

• 任何請(qǐng)求將進(jìn)行持久化，方便查看以及請(qǐng)求的回滾

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

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

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

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

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

其他方面調(diào)優(yōu)

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

盡量增加agent的超時(shí)時(shí)間

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

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

不要在采集腳本中加上超時(shí)

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

增加Zabbix Server的Poller實(shí)例

默認(rèn)情況，用于接收Z(yǔ)abbix agent采集數(shù)據(jù)的Poller實(shí)例只有5個(gè)。對(duì)于周期在1分鐘內(nèi)、數(shù)量會(huì)達(dá)到千級(jí)別的采集項(xiàng)來(lái)說(shuō)，Poller實(shí)例顯然是不夠的，需要增大實(shí)例數(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理解為“判斷某個(gè)item value大于/小于某個(gè)閾值”，那就太低估Zabbix的trigger expression了，它其實(shí)可以支持很多復(fù)雜的邏輯。比如，為了防止網(wǎng)絡(luò)抖動(dòng)，需要當(dāng)最近的連續(xù)兩個(gè)采集項(xiàng)異常時(shí)，才改變trigger的狀態(tài)，表達(dá)式可以寫成：（假設(shè)item_key<0為異常）

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

再舉個(gè)例子，同樣是為了防止采集的服務(wù)不穩(wěn)定，我們可以規(guī)定，當(dāng)目前trigger的狀態(tài)為PROBLEM，并且最近5分鐘的采集數(shù)據(jù)均正常的時(shí)候，才可以將trigger狀態(tài)改為OK，表達(dá)式可以這樣寫：

({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

性能

測(cè)試環(huán)境：

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

• Zabbix Server * 1

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

• ETCD Server * 1

• Docker container * 500 （在1臺(tái)物理機(jī)中）

性能指標(biāo)：

• 樣本采集項(xiàng)：7100

• 樣本采集頻率：60s

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

• 平均入口流量：454.25 kbps

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

• 平均出口流量：366.65 kbps

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

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

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

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

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

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

系統(tǒng)截屏

故障事件列表

短信報(bào)警

總結(jié)

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

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

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