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

1. 簡介

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

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

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

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

2. 優化現有模板

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

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

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

下面以自帶的Template OS Linux為例進行舉例.同時為了避免修改原始模板,復制為新模板Template OS Linux Custom進行優化.

2.1 優化監控項

為了降低zabbix server的壓力,通常建議把原有監控項統一修改為客戶端主動式(Active).這里可以用到模板的批量更新功能：

然后是具體監控項的優化.比如自帶模板通過LLD(Low-level discovery)實現了所有網卡的流量監控,可以在此基礎上增加網卡速率的監控.直接在模板里新增一個監控項原型：

新監控項可以對應配置下觸發器,比如這里實現了網卡速率降到1000M以下的報警

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

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

2.2 優化觸發器

對于已有觸發器,建議結合自己的實際場景修改報警閾值,此外可以根據需求增加新的觸發器.zabbix的觸發器支持大量功能函數,因此可以靈活設計自己的觸發器表達式.

比如自帶模板已經有系統時間的監控項(Host local time),但并沒有對時間出現偏差的故障進行報警.這時我們只需要在模板上增加一個觸發器,讓被監控機器的系統時間與zabbix server的系統時間偏差超過2分鐘時發生報警：

zabbix 3.0起增加了預測性的觸發器函數,可以充分利用該特性優化監控.如根據過去1小時的趨勢來預測未來1小時是否會觸發內存不足的報警：

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

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

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

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

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

 

3. 改造模板支持自動發現

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

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

3.1 定義自動發現規則

所有自動發現的模板都至少要定義一個自動發現規則,這里定義一個每小時更新的規則,用于發現需要監控的所有MySQL端口

定義自動發現中具體的宏.宏可以定義多個,但這里只需要一個即MySQL端口

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

3.2 修改模板XML

將模板導出為XML,將普通監控改為自動發現的格式：

首先修改監控項為監控項原型

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

修改觸發器為觸發器原型

<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的自動發現

配置自動發現的key,需要結合自己實際來編寫腳本實現端口發現的邏輯.我們是讀取統一管理后臺的接口,并格式化成zabbix需要的json.
mysql_discovery_agentd.conf

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

腳本執行效果如下

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

修改Percona Monitoring Plugins的zabbix配置文件,使得能接收端口參數,實現自動發現.

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的監控項,增加一個用ping來檢測具體MySQL實例是否存活的監控項.

該監控項原型還關聯了一個自定義的值映射,增加監控值的可讀性

修改Percona Monitoring Plugins的相應腳本,以便支持不同端口.而ss_get_mysql_stats.php原本就支持端口參數,所以不需要修改.

/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
……

最新數據的效果如下圖:

4. 模板的自動關聯

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

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

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

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

轉載請注明本頁網址：
http://www.fzlkiss.com/jiaocheng/4284.html