《從模板開始打造自己的Zabbix監(jiān)控》要點：
本文介紹了從模板開始打造自己的Zabbix監(jiān)控，希望對您有用。如果有疑問，可以聯(lián)系我們。

1. 簡介

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

• 網(wǎng)絡層監(jiān)控,及時發(fā)現(xiàn)網(wǎng)絡間的訪問質量(如我們之前介紹的全國maps網(wǎng)絡監(jiān)控)；
• 服務器監(jiān)控,了解服務器各項性能參數(shù)(如常見的zabbix、cacti、nagios、ganglia等)；
• 應用性能監(jiān)控,深入監(jiān)測具體業(yè)務的性能情況(如我們之前提到的APM監(jiān)控系統(tǒng))

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

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

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

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

• 更多的系統(tǒng)類型,如各類網(wǎng)絡設備/VMware
• 硬件狀態(tài),如磁盤IO/磁盤健康狀態(tài)/陣列狀態(tài)
• 各類軟件服務,如Nginx/PHP/Memcached/Redis/Hadoop/Elasticsearch

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

下面以自帶的Template OS Linux為例進行舉例.同時為了避免修改原始模板,復制為新模板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)控,可以在此基礎上增加網(wǎng)卡速率的監(jiān)控.直接在模板里新增一個監(jiān)控項原型：

新監(jiān)控項可以對應配置下觸發(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ā)器,建議結合自己的實際場景修改報警閾值,此外可以根據(jù)需求增加新的觸發(fā)器.zabbix的觸發(fā)器支持大量功能函數(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起增加了預測性的觸發(fā)器函數(shù),可以充分利用該特性優(yōu)化監(jiān)控.如根據(jù)過去1小時的趨勢來預測未來1小時是否會觸發(fā)內存不足的報警：

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

然后在模板定義一個宏,設置默認值50,那么默認情況下仍然是小于50%才報警.

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

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

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

 

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

zabbix模板支持自動發(fā)現(xiàn),這大大方便了同類監(jiān)控的批量添加,非常便于運維自動化.相比之下,盡管cacit的模板可以通過參數(shù)實現(xiàn)多個同類監(jiān)控,但如果要實現(xiàn)批量添加就復雜不少.但并不是所有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

將模板導出為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>

修改應用類型為應用類型原型(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>

修改完畢后,導入到zabbix覆蓋原來的模板.

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

配置自動發(fā)現(xiàn)的key,需要結合自己實際來編寫腳本實現(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
……

這里我們去掉了Total number of mysqld processes的監(jiān)控項,增加一個用ping來檢測具體MySQL實例是否存活的監(jiān)控項.

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

修改Percona Monitoring Plugins的相應腳本,以便支持不同端口.而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. 模板的自動關聯(lián)

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

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

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

原文來自微信公眾號：運維軍團

轉載請注明本頁網(wǎng)址：
http://www.snjht.com/jiaocheng/4284.html