雖然Zabbix提供了很多的模板（簡單理解為監控項的集合），在zabbix界面點擊share按鈕就可以直接跳到模板大全的官方網站，但是由於模板內的監控項數量太多不好梳理且各種模板質量參差不齊，還是建議針對自己要監控的主機或產品自定義模板（Linux服務器主機的監控使用默認模板就可以）。
之前一篇筆記描述了如何安裝和配置zabbix架構，詳見：Zabbix-3.4簡介及安裝配置 ，本文分四個小節描述如何自定義監控項：
- 文章概述
- 自定義模板的步驟
- 如何配置告警
- 監測數據的可視化
一、文章概述
什么是模板？模板就是一系列定義好了的監控項+觸發器的集合，例如zabbix定義了Linux OS的監控模板，可以監控Linux的系統狀況。官網也提供了很多常見模板的下載。
我把zabbix的模板大致分三類：
- zabbix自帶的內置模板，這類模板不但有官方定義的item key和trigger，還內置了獲取item value的命令。最典型的就是Linux OS的監控，這個模板的大多數監控項無需你自己配置監控信息的獲取命令，即插即用。
- zabbix提供的常用模板，此類模板zabbix只是為你定義好了監控項的key和key的數據類型（key只有unsigned number，float，character，log，text五種類型），並未提供內置的item value獲取功能，需要你手動為這些key編寫獲取監控信息的命令。
- 自定義的模板，此類模板是完全由用戶自己創建的模板，你可以自定義個性化的key名字和返回類型，並通過特定的命令或腳本或應用提供的接口去獲取監控信息。
個人推薦的是針對特定的產品自己創建特定的模板，這樣才能實現靈活定制。你可以選擇import網上提供的各種模板，也可以將自己搞的模板export出去供他人使用。
本文以監控mysql QPS為例，自己定義一個mysql的監控模板（zabbix有mysql的監控模板，本例只是為了示例）。
二、自定義模板步驟
1.創建模板
模板名稱自定義為MySQL_MONITOR,隸屬的主機組選擇Templates/Databases就好(或都不選擇),屬於哪個主機組不影響使用，模板是對任意主機組內的主機可用的。
而且主機組不止可以表示主機的集合，也可以用於表示模板的集合，你可以創建一個名為DATABASE_TEMPLATES的虛擬主機組，專門用於存放自己編寫的各種數據庫的模板，例如mysql,mongo,oracle等的監控模板。
2.創建模板內的監控項
下面就是建好的模板，可以看到模板主要包含items，trigger等對象，其他的暫不需要太多關注。
由於我們就是用於監控mysql的,因此這個模板內沒必要建applications(applications是用於對items分組的),直接建個item,這里只需要定義個name和key以及type就好了：
type一般選擇zabbix agent或zabbix agent(active)，現在一般后者居多因為可以進行active check減少server壓力，只需要在agent端配相關的active check項即可。
特別提示：如果你的server端版本遠高於agent端，那么建議item的類型選擇zabbix agent，主動式的item可能會有BUG（遇到過獲取的數據異常的問題），即便確認高版本服務端兼容低版本客戶端，但保險起見還是版本一致的好。
此時在看MySQL_MONITOR模板就會發現多了一個監控項（item）。
3.獲取監控值
監控項已經建好了，怎么從客戶端獲取監控信息呢？首先需要修改agent端的配置文件並重啟agentd：
vi zabbix_agentd.conf
UserParameter=mysql.qps,mysql -uleo -pleo -e "show global status like 'Queries'"|grep Queries|awk '{print $2}'
UserParameter的格式是固定的，有以下兩種：
UserParameter=key,command
UserParameter=key[*],command
其中第一種很好理解，key就是你定義的監控項key，本例中就是mysql.qps，command就是獲取監控信息的命令，本例中就是mysql -uleo -pleo -e "show global status like 'Queries'"|grep Queries|awk '{print $2}'
第二種是第一種格式的進階版，允許你為command提供輸入參數，這里都是位置傳參的可以定義從$1-$9的9個參數，這種格式的好處在於你可以使用一個接受位置傳參的腳本獲取多個監控值，而不用為每個監控項都寫一個獲取監控值的腳本。
4.為主機添加監控項
監控項設置好之后，只需要把監控項加入主機即可，這樣就可以實現對主機對應item的監控。
一般來說可以直接在主機界面create item，但是本例為了方便演示如何集成監控項到模板使用的是template，因此直接把模板應用到主機即可。注意下圖要點擊add然后update才能更新主機所用的模板們。
5.查看監控數據
如果獲取監控值的腳本或命令運行正常,且返回值與key type一致,那么現在在儀表板的latest data就可以看到監控的值了：
6.完善監控項
當前監控的mysql qps其實只是queries並沒有p(er)s(econd)，如果用queries/uptime得到的也只是一個平均QPS，而我們一般想要監測的都是類似於過去30s平均qps這種更有意義的值，如果要用腳本或者程序腳本來獲取的話工作量就大了，而用zabbix很簡單。
我們去item的界面進行修改(如果很熟悉要監控的產品的話其實創建模板時就可以為item設置preprocessing)：
只需要對獲取的監控值做預處理就可以了,我們選擇change per second,zabbix server就會自動將持續獲取的監控值們進行處理,得到一個每秒均值,由於我們的qps收集間隔是30s,最終得到的qps就是過去30s數據庫的平均qps。
現在再去看latest data看到的就是qps的30秒平均值了，更多地數據預處理步驟的解釋可以參考官網鏈接：https://www.zabbix.com/documentation/3.4/manual/config/items/item
三、告警配置
在第二步中描述的是如何設置模板及監控項，那么在監控項超過閾值之后如何進行告警呢？涉及的zabbix組件主要有3個：trigger,action,media type，此外還涉及到user實體。
1.如何設置觸發器？
我們直接在模板中添加觸發器，觸發器的觸發條件可以是一個監控項超過閾值或多個監控項超過閾值的邏輯聯合條件，本例只演示mysql.qps超過閾值的告警。
紅色箭頭標出的就是需要注意的地方，其中severity可以選擇告警的嚴重性（沒其他作用，僅僅是標示這個告警有多重要的），本例選擇當監控值超過0.2時就告警......使用expression constructor還可以實現條件的邏輯聯合，例如AND，OR等。
2.查看告警效果
默認告警信息是直接顯示在dashboard的，我們到mysql里噼里啪啦一頓操作把qps拉上來，然后去儀表板看下：
可以看到告警信息了，他會告訴你這個告警持續的時間，如果問題被解決，那么告警會變為綠色，並在儀表板顯示一段時間后消失：
3.設置郵件告警
默認告警只顯示到儀表板，如果想要實現短信或郵件告警還需要額外配置組件。
3.1創建media type並添加到user
默認zabbix自帶了email,jabber,sms媒體類型，你只需要在Administration-Media types下進入Email項，填寫好SMTP的相關信息，並根據SMTP服務器的類型選好驗證模式即可，不過我這里為了加一種media type來演示，選擇新建腳本類型的media type，使用linux自帶的sendmail或者自己編寫SendMail.sh腳本來發送郵件。
上述的3個參數是zabbix預定義的3個宏，有這3個宏足夠了，我們在使用腳本發送郵件時只需要按順序把腳本的輸入參數設置為這3個參數即可。如果你用的郵件發送腳本的參數不是此順序，那么用shell再包裝一層即可，確保腳本輸入參數是這3個。
Ps:Zabbix內置的完整宏列表參見：https://www.zabbix.com/documentation/3.4/manual/appendix/macros/supported_by_location
關於宏使用的一些提示：
- 獲取trigger被觸發時的item value可以使用宏{ITEM.LASTVALUE}，如果觸發器內有多個item的觸發條件，那么可以使用{ITEM.LASTVALUE<1-9>}定位具體是哪個item，1-9是指item在trigger中出現的順序，最多9個，例如{ITEM.LASTVALUE1}
- 內置宏並非在所有情況下可用，曾經遇到過官網支持的版本下某些內置宏獲取不到值的BUG，例如3.4版本時{TRIGGER.SEVERITY}宏在trigger name中不可用，但是在郵件中可用，后來猜測是因為SEVERITY本身是trigger的一個屬性，在trigger未實例化之前不能調用自身的屬性。如果在action中調用trigger的各種宏就不會出錯了。
- 除了正常的內置宏外，zabbix還支持用戶自定義宏和底層的發現規則宏(LLD)，分別為{$MACRO}和{#MACRO}的表示格式，其中：
關於用戶自定義宏的創建參照https://www.zabbix.com/documentation/3.4/manual/config/macros/usermacros
模板的discovery rules的本質其實是一個子模板，其中定義了一系列的item、trigger、graph等對象的prototypes。這些prototypes（即原型）都是使用發現規則宏定義的，本質上是用宏變量代替要監控的具體對象。例如常規的監控項可以將key命名為linux.fs[/root]來監控/root目錄，但是如果要監控N多目錄呢，我們要建N個item嗎？不，有了discovery rules和[low level]discovery macros(LLD)我們就可以只定義一個discovery rules，prototypes所引用的具體目錄可以用宏{#FSNAME}來代替，即linux.fs[{#FSNAME}]這樣一個item prototypes就可以滿足所有目錄的監控，我們只需要使用提前定義好的腳本獲取一系列的鍵值對，其中鍵就是我們的LLD宏，而值就是獲取的一系列要監控的目錄名，腳本輸出需要如下所示：
{
"data":[
{ "{#FSNAME}":"/", "{#FSTYPE}":"rootfs" },
{ "{#FSNAME}":"/sys", "{#FSTYPE}":"sysfs" },
{ "{#FSNAME}":"/proc", "{#FSTYPE}":"proc" },
{ "{#FSNAME}":"/dev", "{#FSTYPE}":"devtmpfs" },
{ "{#FSNAME}":"/dev/pts", "{#FSTYPE}":"devpts" },
{ "{#FSNAME}":"/lib/init/rw", "{#FSTYPE}":"tmpfs" },
{ "{#FSNAME}":"/dev/shm", "{#FSTYPE}":"tmpfs" },
{ "{#FSNAME}":"/home", "{#FSTYPE}":"ext3" },
{ "{#FSNAME}":"/tmp", "{#FSTYPE}":"ext3" },
{ "{#FSNAME}":"/usr", "{#FSTYPE}":"ext3" },
{ "{#FSNAME}":"/var", "{#FSTYPE}":"ext3" },
{ "{#FSNAME}":"/sys/fs/fuse/connections", "{#FSTYPE}":"fusectl" }
]
}
這樣discovery rules的prototypes就會遍歷{#FSNAME}，自動為所有檢測到的目錄創建item、trigger、graph等。
接下來繼續說為用戶添加media type:
在media type創建完畢后需要為user添加媒體類型，其中NIWAHD（Not classified,Information,Warning,Average,High,Disaster ）是問題嚴重程度的英文首字母,郵件告警發送的email地址也是在user實體這里配置的：
3.2創建action
建好了media type，並為用戶添加上就完事了嗎？不，那只是提供了郵件發送的功能和通道，為了實現監測值異常告警還需要添加action，所謂action就是當觸發器被觸發時，告警不止顯示在儀表板，還會通過郵件告警媒介將特定的信息發送給指定的user實體。
一個功能完整的action可以按上圖的小標題分3部分（第4個忽略）：action condition，operations和recovery operations，分表表示動作觸發的條件，觸發后的具體操作，問題恢復時的操作。
上邊的message可以自定義的更豐富些，可以用中文編寫，配置完之后需要點擊add按鈕添加，本圖只是展示如何配置。其中{}括起來的都是zabbix的宏。
拓展：關於operations中的steps(操作步驟)和step duration(操作步長)
步長是操作步驟的執行間隔，而step(操作步驟)是在operation details中定義的，step數字只是代表執行的優先度。
例如你可以建多個operations，每個都是step 1，那么當告警觸發時這些step為1的操作就會被全部即時執行，你還可以在一個operation中將steps設為1-3，那么這個operation就會每隔一個操作步長執行一次共執行3次停止。
你還可以設置了step1、step3，那么執行完step1之后就會經過兩個步長的時間繼續執行step3，每個步驟都可以自定義不同的操作和操作步長（自定義的操作步長為0表示默認使用統一的操作步長1h）。
需要注意的是action並沒有執行周期，即一個觸發器類型的action只會執行一次，如果需要在問題解決之前每隔一段時間發出一次告警只能通過將action的operation step設為1-0來解決（0表示無限次數即每隔1小時執行一次action operation）。
至此action配置完畢，只要下次觸發器被觸發，告警就不會只出現在dashboard了，郵件告警也會被發送至指定用戶。
四、數據可視化
為了更好的觀察監控數據的變化趨勢，我們需要用圖表來展示數據，zabbix提供了這方面的功能。
雖然可以在latest data中通過點擊每個監控項的graph按鈕查看數據的圖表，但是這種方式看起來很麻煩，且只能查看單一監控項的變化圖表，而定制的graph比較靈活。
為了更好地觀察數據我們要在模板中添加graph組件：
graph type的4種選項分別表示普通線型圖，柱狀圖，餅狀圖和爆炸餅狀圖，添加items可以實現在一副圖中顯示多個監控項的歷史值，本例只有一個監控項如上所示。
建好graph之后就可以在dashboard中添加graph了：
下邊第四個窗口就是我新加的展示窗口：
