1. 簡介

監(jiān)控一直在不同的層面為我們的運維工作發(fā)揮著重要的作用：

• 網(wǎng)絡(luò)層監(jiān)控，及時發(fā)現(xiàn)網(wǎng)絡(luò)間的訪問質(zhì)量（如我們之前介紹的全國maps網(wǎng)絡(luò)監(jiān)控）；

• 服務(wù)器監(jiān)控，了解服務(wù)器各項性能參數(shù)（如常見的zabbix、cacti、nagios、ganglia等）；

• 應(yīng)用性能監(jiān)控，深入監(jiān)測具體業(yè)務(wù)的性能情況（如我們之前提到的APM監(jiān)控系統(tǒng)）

其中，服務(wù)器監(jiān)控作為一種傳統(tǒng)的監(jiān)控類型，我們結(jié)合不同場景中也用到了多種方案。而在眾多方案中，zabbix由于其強大的功能和靈活的自動化特性，尤其得到我們的廣泛使用。

為了打造出適合自己的zabbix監(jiān)控體系，如何去配置和優(yōu)化是一個比較復(fù)雜的課題。下文從監(jiān)控模板的角度去簡單介紹下我們的一些思路，以便拋磚引玉。

2. 優(yōu)化現(xiàn)有模板

zabbix自帶了各類操作系統(tǒng)的監(jiān)控模板，一般可以直接拿來用，但如果要求更精細的監(jiān)控，就要對自帶模板進行修改了。
此外zabbix在網(wǎng)上還有大量的第三方模板可以使用：
https:///wiki/Zabbix_Templates
https://share./
利用這些第三方模板可以很好地實現(xiàn)官方模板所沒有的各類監(jiān)控：

• 更多的系統(tǒng)類型，如各類網(wǎng)絡(luò)設(shè)備/VMware

• 硬件狀態(tài)，如磁盤IO/磁盤健康狀態(tài)/陣列狀態(tài)

• 各類軟件服務(wù)，如Nginx/PHP/Memcached/Redis/Hadoop/Elasticsearch

充分利用第三方模板能避免重復(fù)造輪子，但往往第三方模板的監(jiān)控并不完全符合自己的需求，這時也要自行修改。

下面以自帶的Template OS Linux為例進行舉例。同時為了避免修改原始模板，復(fù)制為新模板Template OS Linux Custom進行優(yōu)化。

2.1 優(yōu)化監(jiān)控項

為了降低zabbix server的壓力，通常建議把原有監(jiān)控項統(tǒng)一修改為客戶端主動式（Active）。這里可以用到模板的批量更新功能：

然后是具體監(jiān)控項的優(yōu)化。比如自帶模板通過LLD（Low-level discovery）實現(xiàn)了所有網(wǎng)卡的流量監(jiān)控，可以在此基礎(chǔ)上增加網(wǎng)卡速率的監(jiān)控。直接在模板里新增一個監(jiān)控項原型：

新監(jiān)控項可以對應(yīng)配置下觸發(fā)器，比如這里實現(xiàn)了網(wǎng)卡速率降到1000M以下的報警

注意新增監(jiān)控的同時需要定義客戶端的監(jiān)控項：
network_agentd.conf

UserParameter=net.if.speed[*],sudo /sbin/ethtool $1 |grep Speed|awk ‘{print $$2}’|sed ‘s@Mb/s@@’

2.2 優(yōu)化觸發(fā)器

對于已有觸發(fā)器，建議結(jié)合自己的實際場景修改報警閾值，此外可以根據(jù)需求增加新的觸發(fā)器。zabbix的觸發(fā)器支持大量功能函數(shù)，因此可以靈活設(shè)計自己的觸發(fā)器表達式。

比如自帶模板已經(jīng)有系統(tǒng)時間的監(jiān)控項（Host local time），但并沒有對時間出現(xiàn)偏差的故障進行報警。這時我們只需要在模板上增加一個觸發(fā)器，讓被監(jiān)控機器的系統(tǒng)時間與zabbix server的系統(tǒng)時間偏差超過2分鐘時發(fā)生報警：

zabbix 3.0起增加了預(yù)測性的觸發(fā)器函數(shù)，可以充分利用該特性優(yōu)化監(jiān)控。如根據(jù)過去1小時的趨勢來預(yù)測未來1小時是否會觸發(fā)內(nèi)存不足的報警：

有時候不同項目的報警閾值要求并不一樣，除了分成不同的模板或者單獨調(diào)整具體主機的觸發(fā)器，其實還可以結(jié)合宏實現(xiàn)報警閾值的動態(tài)調(diào)整。如默認的可用swap是小于50%才報警，我們改為用宏{$SWAPWARN}定義報警閾值

然后在模板定義一個宏，設(shè)置默認值50，那么默認情況下仍然是小于50%才報警。

但如果對于具體某個主機，設(shè)置了其他的宏值如10，那么這個主機則會在可用swap小于10%才報警。

觸發(fā)器還有一個選項是嚴重性，用于設(shè)置該觸發(fā)器的嚴重程度，這在需要針對不同閾值設(shè)置不同報警程度的場景下就特別有用。此時為了收斂報警可以設(shè)置觸發(fā)器的依賴關(guān)系，即低嚴重性觸發(fā)器依賴于高嚴重性觸發(fā)器。這樣，當出現(xiàn)高嚴重性報警時，相關(guān)聯(lián)的低嚴重性報警就不會重復(fù)觸發(fā)，從而減少報警消息量。

zabbix 3.0之后，觸發(fā)器原型也支持依賴關(guān)系。比如我們可以對警告級別和嚴重級別的磁盤空間報警觸發(fā)器設(shè)置依賴：

3. 改造模板支持自動發(fā)現(xiàn)

zabbix模板支持自動發(fā)現(xiàn)，這大大方便了同類監(jiān)控的批量添加，非常便于運維自動化。相比之下，盡管cacit的模板可以通過參數(shù)實現(xiàn)多個同類監(jiān)控，但如果要實現(xiàn)批量添加就復(fù)雜不少。但并不是所有zabbix模板都支持自動發(fā)現(xiàn)，這時該怎么辦呢，其實我們可以手動改造模板。

比如常用的Percona Monitoring Plugins，它很全面地實現(xiàn)了MySQL監(jiān)控，比官方自帶的強大得多。但默認模板只能監(jiān)控單一的3306實例。如果線上實例不是3306端口，或者有多個實例就無法監(jiān)控了。下面介紹如何將它改造為LLD（Low-level discovery）的自動發(fā)現(xiàn)模板。

3.1 定義自動發(fā)現(xiàn)規(guī)則

所有自動發(fā)現(xiàn)的模板都至少要定義一個自動發(fā)現(xiàn)規(guī)則，這里定義一個每小時更新的規(guī)則，用于發(fā)現(xiàn)需要監(jiān)控的所有MySQL端口

定義自動發(fā)現(xiàn)中具體的宏。宏可以定義多個，但這里只需要一個即MySQL端口

定義匹配宏用的正則表達式規(guī)則，也可以不配置。這里類似33**的值都被認為是合法端口值

3.2 修改模板XML

將模板導(dǎo)出為XML，將普通監(jiān)控改為自動發(fā)現(xiàn)的格式：

首先修改監(jiān)控項為監(jiān)控項原型

<items>
<item>
……
</item>
</items>

替換為下面格式

<discovery_rules>
<discovery_rule>
<item_prototypes>
<item_prototype>
……
</item_prototype>
</item_prototypes>
</discovery_rule>
</discovery_rules>

修改圖形為圖形原型

<graphs>
<graph>
……
</graph>
</graphs>

替換為下面格式

<discovery_rules>
<discovery_rule>
<graph_prototypes>
<graph_prototype>
……
</graph_prototype>
</graph_prototypes>
</discovery_rule>
</discovery_rules>

修改觸發(fā)器為觸發(fā)器原型

<triggers>
<trigger>

</trigger>
</triggers>

替換為下面格式

<discovery_rules>
<discovery_rule>
<trigger_prototypes>
<trigger_prototype>

</trigger_prototype>
</trigger_prototypes>
</discovery_rule>
</discovery_rules>

修改應(yīng)用類型為應(yīng)用類型原型（zabbix 3.0起支持）

<applications>
<application>
<name>Percona MySQL</name>
</application>
</applications>

替換為下面格式

<applications/>
<application_prototypes>
<application_prototype>
<name>Percona MySQL {#MYSQLPORT}</name>
</application_prototype>
</application_prototypes>

修改完畢后，導(dǎo)入到zabbix覆蓋原來的模板。

3.3 配置agent的自動發(fā)現(xiàn)

配置自動發(fā)現(xiàn)的key，需要結(jié)合自己實際來編寫腳本實現(xiàn)端口發(fā)現(xiàn)的邏輯。我們是讀取統(tǒng)一管理后臺的接口，并格式化成zabbix需要的json。
mysql_discovery_agentd.conf

UserParameter=MySQL.port.discovery,/bin/bash /var/lib/zabbix/percona/scripts/zbx_discovery_mysql.sh port_discovery

腳本執(zhí)行效果如下

{
“data”:[
{
“{#MYSQLPORT}”:”3306″
},
{
“{#MYSQLPORT}”:”3307″
}]
}

修改Percona Monitoring Plugins的zabbix配置文件，使得能接收端口參數(shù)，實現(xiàn)自動發(fā)現(xiàn)。

userparameter_percona_mysql.conf

UserParameter=MySQL.Alive[*],/usr/bin/mysqladmin -uzabbix -pzabbix -h127.0.0.1 -P$1 ping 2>&1|grep alive |wc -l
UserParameter=MySQL.Sort-scan[*],/var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh kt $1
UserParameter=MySQL.slave-stopped[*],/var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh jh $1
UserParameter=MySQL.Com-replace[*],/var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh jz $1
……

這里我們?nèi)サ袅薚otal number of mysqld processes的監(jiān)控項，增加一個用ping來檢測具體MySQL實例是否存活的監(jiān)控項。

該監(jiān)控項原型還關(guān)聯(lián)了一個自定義的值映射，增加監(jiān)控值的可讀性

修改Percona Monitoring Plugins的相應(yīng)腳本，以便支持不同端口。而ss_get_mysql_stats.php原本就支持端口參數(shù)，所以不需要修改。

/var/lib/zabbix/percona/scripts/get_mysql_stats_wrapper.sh

……
ITEM=$1
HOST=127.0.0.1
PORT=$2
DIR=`dirname $0`
CMD=”/usr/bin/php -q $DIR/ss_get_mysql_stats.php –host $HOST –port $PORT –items gg”
if [ “$PORT” = “3306” ];then
CACHEFILE=”/tmp/$HOST-mysql_cacti_stats.txt”
else
CACHEFILE=”/tmp/$HOST-mysql_cacti_stats.txt:$PORT”
fi
……

最新數(shù)據(jù)的效果如下圖:

4. 模板的自動關(guān)聯(lián)

當把模板都定制好之后，就可以進一步定義動作，實現(xiàn)新主機的自動注冊并關(guān)聯(lián)模板、主機組。

在模板自動關(guān)聯(lián)的基礎(chǔ)上，通過自研運維后臺與zabbix API接口相結(jié)合，我們很好地實現(xiàn)了服務(wù)器上架并添加監(jiān)控、下架并撤銷監(jiān)控的自動化運維工作。

但也需要強調(diào)一下，沒有最好的監(jiān)控系統(tǒng)，只有最合適自己的監(jiān)控系統(tǒng)。怎么結(jié)合開源工具和自研工具，更好地實現(xiàn)運維自動化需求才是我們的核心目標