1. 程式人生 > >Zabbix監控流程詳解(自己的心得)

Zabbix監控流程詳解(自己的心得)

本篇主要是我最近使用zabbix3.2的一些理解,參考官方文件https://www.zabbix.com/documentation/3.2/manual

先拋開zabbix監控的其他架構不談,從最簡單的server-agent模式說起,即監控主機-被監控主機(主動模式、被動模式主要是影響資料的採集方式和服務端的負載壓力),首先是zabbix最重要的五個組成部分:Item、Trigger、Action、Media、User(其實應該還有個Event,不過這個表現的不直觀),翻譯一下就是監控元素、觸發器、動作、報警介質、使用者,接下來一個一個的詳談,最後在梳理他們之間的關係。

Item,官方說明為Items are the ones that gather data from a host. 意思就是監控採集的專案,舉個栗子就是agent端的cpu、記憶體等,但是更加具體的來說,比如說cpu使用率,或者是cpu某個核的使用率或者是cpu的空閒率,item應該是這樣一個十分具體的項,而item是由key+引數組成,在定製化的監控項中,key比較好理解,舉個實際的例子比較直觀,在server端建立item,name填test,type選擇zabbix agent,key填寫echo,返回資料型別選int,然後在agent.conf檔案中,找到UserParameter行,按如下格式   

UserParameter=<key>,<command>,具體我們寫為UserParameter=echo,echo 1    然後重啟zabbix服務,在“最近資料”選項卡中可以看到test值為1,可以看到我們新設定的item “test”是根據key值來執行響應命令並返回值,那我們就可以在“command”那裡使用一些命令來拿到我們需要監控的值(比如用top命令再grep一下再awk處理一下得到cpu、記憶體的值之類的),甚至可以在這裡寫一個指令碼執行語句,然後在對應位置寫好指令碼,值得注意的一點是key後面可以接引數,比如UserParameter=echo[a],echo $1 這個跟shell的引數傳遞一樣的,講到這裡是不是比較理解key和item的關係了呢,但是這裡item是由key+引數組成的還不明顯,我們再用官方給的item舉個例項。

https://www.zabbix.com/documentation/3.2/manual/config/items/itemtypes/zabbix_agent 這是官方給出的監控item項,由windows、linux、AIX等等的監控項,注意要對應上,使用官方item的時候就不用在conf檔案裡增加UserParameter了,因為都內建好了,只要在建立item時注意填寫引數即可,以監控日誌為例,

選擇建立item,名字隨便填,只是key這裡需要注意,[]中有7個引數,沒有<>的是必填的,其餘選填,引數意義官方文件中都有說明,引數可以為空,表示使用預設值,比如log[/var/log/syslog,error],官方說明若output項為空,則輸出匹配文字的整行,即包含“error”的行。

可見引數對我們監控項的重要性,對於item暫時就說這麼多,有問題的多看官方文件。

Trigger

顧名思義觸發器,也就是將採集來的item值進行一定的判斷,需要注意的點有兩個,一個是serverity,即報警等級,還有一個是判斷的邏輯,判斷邏輯分單機判斷和觸發依賴,,在此設定觸發依賴,官方文件有個很典型的例子,


就是說假如有這樣一個網路關係:

Zabbix  -  Router1  -  Router2  - 主機
主機關機觸發的條件為router2觸發,而router2觸發的條件為router1觸發,因為route1出問題的時候,明顯router2和主機網路都不可達,但是此時並不想收到三份告警,就可以設定這樣一個依賴關係。

普通的觸發器設定就比較簡單了,大概是這樣一個表示式

{<server>:<key>.<function>(<parameter>)}<operator><constant>

花括號中間的內容是item採集回來的引數,而右邊是一個做邏輯判斷的式子,比如

{www.zabbix.com:system.cpu.load[all,avg1].last()}>5

主機部分比較容易明白,而key呢最好是參考官方文件裡給出key,裡面有引數很豐富,'.'後面接的是一個函式及函式的引數,last函式就是最新的一次資料,還有很多函式像sum()、min()、count()等等,後面的判斷也比較常見,‘>’‘=’‘<>’等等,需要詳細瞭解的還是看我最上面發的官方文件連線,然後這一個邏輯判斷就完成了,有時候還需要多個判斷,這時候就只需要用'or''and'等連線幾個這樣相同格式的判斷語句即可。

Action

action就是server對事件響應(Event)需要做相應的措施了,關鍵點是四個,一是如何觸發action,而是action具體使用什麼方式,三是傳送的內容,四是動作的物件。action支援的Event有四種:用大白話講就是Trigger觸發時、discover rule檔案生效時、自動發現新伺服器時以及server本身出問題時。最主要的就是Trigger觸發來產生action,在建立action時會有"condition"這個選項來設定觸發器,而action的方式是由media來決定,media有五種,常見的是mail、sms、script這三種,郵件的方式只需要在建立一個media方式選郵件,然後填寫smtp伺服器地址即可,郵件的內容是在action選項卡里面設定,支援普通的字串以及表示式比如{TRIGGER.NAME}這種,這個值就是對應觸發的Trigger的名字,同時這些資訊也會存入資料庫,在alerts表單裡面,sms我沒用過應該和郵件差不多,重點講下執行指令碼,在zabbix_server.conf檔案裡會配置執行指令碼的路徑,一般預設為zabbix目錄/share/alertscripts,當然這個路徑你可以隨便改,只要在這個路徑下建立指令碼即可,條件滿足後就會執行這個指令碼,action這塊的整個配置流程是:1.選擇觸發器的條件  2.填寫傳送的內容  3.選擇事件傳送的使用者以及方式(media) 4.到使用者選項卡,在media裡配置資訊    

Action、Media、User這幾者的關係我梳理一下,是action將產生的資訊傳送給user,然後user選擇相應的media進行處理,而產生的資訊呢不進行呼叫只會存在資料庫裡,或者在報表選項卡里的action log裡可以看到,傳送給使用者的資訊在使用mail報警時就直接吧action裡設定的內容傳送過去,但指令碼方式就沒太大聯絡了,比如在指令碼呼叫時你需要把這次的告警資訊存到一個檔案裡, .sh檔案裡寫 mysql -u使用者 -p密碼 -e "use zabbix; select * from alerts\G;" >> /var/test.log 這個是把資料庫裡的資訊給匯出來,並不是action的內容直接用,不過本身action裡面設定的內容也是存在資料庫裡,當然呼叫資料庫的資訊還可以更完整,alerts裡面還有存放event id、時間、傳送ip等等其他資訊,看你的指令碼怎麼寫了。  

其實action裡面還可以執行遠端命令,用於服務重啟之類的,比如httpd報警了,就直接遠端命令執行servicce restart之類的,有興趣的可以自行研究

這裡附一張圖(一本書裡的),報警流程感覺說的比較清楚了,我也是才學zabbix沒多久,感覺很多東西還是得自己配置做做小實驗對報警的流程印象會比較深,還有就是個人感覺看官方文件是真的很有用,很多東西都寫得很清楚,希望我沒說明白的地方能看官方文件在理解理解,共勉。