由淺入深在實踐中玩轉Zabbix,解決剩下20%的監控需求!

本文整理自Zabbix中級認證專家李銘栓(滿分學員)在Zabbix Meetup廣州站的演講。

掌握這幾種監控方式解決80%的監控問題,剩下的20%如何實現?這裏有答案!


幾點經驗分享:


1.先使用Zabbix默認模板,再逐步瞭解指標和觸發器含義、模板規範等,最後優化模板;


2.儘量多使用依賴監控項和預處理;


3.合理使用LLD,減少不必要的手動配置;  


4.多看Zabbix官方文檔,不懂可以參加Zabbix官方認證培訓。

大家下午好,我是李銘栓。今天要與大家分享的是系統化的學習經驗。對於剛接觸Zabbix的新手,應該如何快速地學習和了解,以便在短時間內有目標地逐步深入學習Zabbix呢?讓我們來看一下本次演講的大綱。我將分爲三個部分進行講解,從初識到學習瞭解,最後到重複實踐,依次向大家介紹。

1. 自底向上認識Zabbix


在學習Zabbix的不同階段,應該重點了解哪些方面的知識呢?首先是第一部分,自底向上地瞭解Zabbix。在深入學習Zabbix之前,應該從基礎開始瞭解Zabbix。通常來說,一個系統背後有多個組件相互協作,就像這個圖中顯示的,Zabbix背後也有多個組件,它們分別是Zabbix Server、Zabbix Database和Zabbix Web,它們各自承擔着不同的功能。可以將其類比爲網上購物的過程,其中除了商家和購物者外,還涉及到倉儲、物流等多個單位的協作。
所以我認爲,對於Zabbix用戶,特別是那些希望深入學習的用戶來說,不應該停留在僅僅瞭解監控的層次上。學習和了解Zabbix的系統架構是非常必要的。相對於其他系統,Zabbix的架構並不複雜。從這張圖中可以看出,首先是Zabbix Server,它用於獲取監控數據,然後是Zabbix Database,用於持久化存儲數據,最後是Zabbix Web,用於向用戶展示數據。
因爲我接觸到的Zabbix用戶具有多種技術背景,有些用戶對監控的概念可能不太瞭解,因此我會舉一些形象的例子來幫助他們理解。比如,假設有人的工作是統計某條路上的車流量,這實際上就是一個監控的場景。爲了記錄車流量,需要有一個存儲介質,比如可以記錄在筆記本上,按天或按小時分類記錄。最後,需要查看這些數據,就可以翻閱筆記本,在某一天查看這些數據。整個過程實際上就是監控的過程。

如果身邊有人剛接觸Zabbix,甚至對每個組件的功能都不是很理解,我們可以通過一個形象的例子來介紹,這樣會更容易理解。對於剛接觸Zabbix的用戶來說,可能首先會看到Zabbix Web頁面,因爲他們會從這裏開始使用。但是,Zabbix Web頁面的菜單項很多,頁面也很多,可能會讓人感到一頭霧水,不知道應該從哪個頁面開始學習。在這裏,我提供一個新穎的思路,就是讓他們想象自己是Zabbix Web頁面的開發人員,然後思考他們會如何設計這個頁面的模塊。

爲什麼我會這麼想呢?因爲我有一些網站和系統開發的經驗。所以,開發這些頁面時,我會首先考慮功能性。比如,對於一個Web系統,首先會有用戶管理模塊,因此會有一個用戶列表頁面,用來查看所有的用戶。如果用戶很多,可能需要對他們進行分組,所以可能會有一個用戶組頁面。由於Web頁面可能很複雜,不同的用戶可能需要看到不同的內容,因此就會有用戶角色的功能。

回到Zabbix Web頁面的設計,由於它是一個監控工具,因此頁面上肯定會有配置和查看的功能。這自然而然地引出了監控配置和監控查看可能會有哪些頁面。因此,在初次瞭解Zabbix Web頁面時,應該首先關注這三大功能的相關頁面,如用戶管理、監控配置和監控查看,這樣就可以找到對應的頁面,瞭解它們的功能。

總之,我認爲對於新手用戶來說,應該採用一種快速瞭解Zabbix的方法論。我們不應該停留在表面上的認識和理解,而是應該從它的基礎本質出發,變被動爲主動。因此,要主動地理解Zabbix作爲監控工具的本質是怎樣的。

2.由淺入深學習Zabbix



接下來要深入學習Zabbix,進入第二部分,由淺入深學習Zabbix。作爲監控工具,學習如何添加監控是首要任務。在這裏我不會詳細講解具體的配置步驟,因爲Zabbix的官方文檔已經提供了很好的幫助。我將分享一條基本的學習和配置路徑,就像PPT所示的那樣,這裏的配置從左到右的難度是逐步遞增的。

我認爲最簡單的監控是ping監控。只需要輸入一個IP地址或者DNS地址,將其添加爲主機,然後連接ping模板,就可以實現監控了。其次是ICMP監控,通過ICMP可以監控大部分網絡設備,比如路由器和交換機。剛開始可以選擇Zabbix上已經提供現成模板的一些設備進行監控,比如思科設備、華爲設備等等。

隨後,難度會逐步增加,可能就是Web監控。通過Web監控,可以監測一些網站的狀態碼和下載速度。關於這方面的配置,Zabbix官方文檔中有詳細的指引和示例,我也強烈建議跟着文檔一步步實踐。



最後就是Agent監控了,這是最常見的場景之一。在服務器上安裝Zabbix Agent,並配置好,可以監控服務器的性能指標。我認爲,在實現了以上幾種類型的監控之後,應該已經能夠滿足80%的監控需求了。當然,雖然這一頁看起來很簡單,但實際上,對於剛接觸Zabbix的用戶來說,去實踐這幾類監控可能會花費不少時間。但只要掌握了這些內容,就表明在Zabbix監控配置方面已經沒有太多的問題。即使遇到問題,也可以通過官方文檔進行查詢解決。

從這一頁開始,就是我認爲的分水嶺,也就是說,Zabbix能否更好地發揮作用?能否滿足剩餘20%的監控需求?這就是我接下來要分享的內容了。

首先,要爲客戶提供監控解決方案,我認爲自己也需要理解監控的本質原理以及數據的含義等。以剛纔提到的ICMP監控爲例,如果客戶問及ping監控的原理,以及Zabbix進行ping監控時默認發送幾個包,大家能回答上來嗎?如果客戶希望通過Zabbix實現每隔10秒進行ping請求,每次請求間隔0.5秒發送包,總共發送10個包的場景,你該如何實現呢?實際上,這些答案都可以在官方文檔中找到。如表所示,Zabbix的內置ping監控鍵值提供了許多參數可以調整,比如包的數量、間隔時間等。通過修改這些參數,可以定製化客戶的監控模板。

對於剛纔的示例場景中,Zabbix的ping監控默認發送幾個包呢?這個問題也可以在官方文檔中找到答案。通常情況下,Zabbix是依賴於PING命令來實現監控的,與通常使用的PING命令略有不同。在Zabbix中,默認發送3個包,每隔一秒發送一次。我舉這個例子的目的是想告訴大家,學習監控時最好理解其本質。通過Zabbix監控工具實現監控,最好了解監控的原理和機制,這樣才能更好地回答客戶的監控需求。

提到Agent監控,最常見的監控場景就是針對Linux和Windows服務器的監控。如果大家對運維方面有所瞭解的話,就會知道很多服務都是運行在服務器上的。比如在自己的電腦上安裝微信、瀏覽器等應用程序,這些應用程序都是依賴操作系統的。因此,對服務器的操作系統(OS)進行監控是非常常見的。最常見的OS監控指標包括CPU、內存和磁盤等。對這些系統指標進行監控,並進行可視化展示是非常重要的。除了在Zabbix的儀表板模塊展示數據外,我推薦使用專門的可視化平臺,比如Grafana,來與Zabbix對接,實現監控數據的可視化。通過儀表板,可以清晰地看到主機和服務器當前的性能狀況。

除了配置監控之外,可視化方面的建議也很重要,因爲監控最終呈現給用戶的應該是靈活、生動的數據化大屏。不應該只是展示一些數據。接下來,我認爲Zabbix用戶,特別是那些已經熟悉監控配置的用戶,能否進階,取決於他們是否能獨立進行模板開發。


在模板開發方面,我認爲最好的學習實踐方式就是從Zabbix的默認模板中去借鑑學習。Zabbix自帶的監控模板中,我列舉了一些值得學習參考的模板,例如Linux和Windows的Agent監控模板,以及思科設備的SNMP模板等等。通過查看和分析這些模板,實際上可以學習到以下內容:命名規範:經常需要自己創建監控項和觸發器,因此要學習它們的命名規範,以確保監控項具有易讀性和可讀性。


其次是監控項類型預處理,以及一些常用的Agent監控和Zabbix監控項。實際上,這涉及到觸發器的表達式,也就是告警觸發器。如果掌握了這些表達式函數的各種用法,就可以實現複雜的告警邏輯表達式了。此外,底層自動發現也非常重要,它可以自動掃描、發現或刪除一批監控項對象。監控項類型方面,Zabbix提供了17種監控項類型,支持非常多的監控方式,除了Agent監控項、Ping監控之外,還有SSH檢查、Web監控等等。宏可以實現文本替換的功能。

我想分享一下監控項預處理這方面的功能。我認爲在模板開發中,這是比較實用、方便的功能。我列舉了一些常見的預處理方法,比如正則表達式,用於從文本中提取數據。除此之外,還有一些簡單的數值處理,比如自定義乘數、簡單更改、每秒更改等等。我在右邊列舉了一些常見的適用場景,當然,這些示例也可以從默認模板中找到。我最喜歡的是使用JavaScript進行預處理,因爲通過JavaScript可以對數據進行更靈活的處理,這取決於你是否擅長編寫腳本,但它的靈活性是非常高的。

接下來是一些使用示例,我覺得可以從一些模板中摘取出來。首先是CPU使用率的計算,在Linux中,CPU使用率實際上是根據每個CPU的空閒時間計算得出的。在只能獲取空閒時間的情況下,就需要通過預處理來計算CPU使用率的數值了。在這個例子中,使用了JavaScript進行數值計算。還有一種場景叫做重複值丟棄,比如獲取系統名稱的監控場景。系統名稱肯定是不會改變的,因此不可能每分鐘都獲取一次,甚至每小時獲取一次都可能顯得多餘,但又想監測這個名稱是否發生變化。這時可以使用重複值丟棄這種預處理方式。雖然默認情況下是每小時收集一次,但只要與上一次的值沒有變化,就不存入數據庫,這樣可以節省存儲空間。當然,如果一直沒有變化,歷史數據中就一直沒有數據,那我如何得知它是否正常工作呢?這時可以使用“discard change with heartbeat ”這種預處理功能。比如,設置每隔12個小時即使沒有變化也要存儲一次監控項,這樣既能檢查其是否正常工作,又能節省存儲空間。

還有兩個例子,一個是接口速率的計算,比如對網絡設備的接口速率進行監控。通常情況下,我們獲取到的原始值是接口的總字節數,因此需要進行計算。首先可以使用“每秒變化量”來計算新增的字節數,然後再通過自定義乘數進行單位轉換,乘以8就可以將單位轉換成比特bps。

接着從主監控項中提取一些數值,比如有些監控項返回的是一串JSON數據,需要從JSON數據中提取某個數值,這時就可以使用JSON Path進行提取。我認爲在模板開發中,這四個例子應該是會比較常用的。

接下來是底層自動發現(Low Level Discovery,LLD),LLD的用法是可以自動創建監控項、觸發器等。通常情況下,LLD適用於掃描一些被監控主機上的不定數量的實體。比如在Windows服務器中,可能有網絡接口、進程、磁盤等,但每臺服務器的數量可能都不同。在這種情況下,無法預先手動配置,因此需要通過LLD來解決這個問題,它可以自動掃描這些實例,並自動創建相應的監控項。

接着就是宏是預先定義好的一串特殊文本,我會更喜歡稱它爲變量或常量。在Zabbix中它是有固定的幾類格式的,比如說在 Zabbix裏面分了三類,有內置宏、用戶宏,還有LLD宏,就是剛纔提到的底層自動發現。

接着就是宏,它是預先定義好的一串特殊文本,我更喜歡稱其爲變量或常量。在Zabbix中,宏有固定的幾類格式,分別是內置宏、用戶宏和LLD宏,也就是底層自動發現。宏的設計使得Zabbix在做觸發器配置、告警配置和監控配置等方面具有了極大的靈活性。

接下來我會舉幾個宏的使用例子。首先,對於一批要監控的Linux服務器,可能大家都直接套用模板,設置了高CPU使用率的告警。但是根據應用業務的不同,每個服務器的告警閾值可能是不同的,比如有些服務器的告警閾值是90%,而其他的是85%。在監控內容一致的情況下,可以通過宏來實現這樣的配置,而不需要修改模板配置。舉個例子,可以看到觸發器的函數中使用了宏,在模板上定義了默認值爲90,如果要將某個主機的告警閾值改成85,只需直接修改該主機上的宏即可,因爲宏會從模板上繼承下來,這樣就實現了監控場景的定製化。

第二個示例是關於告警模板,我認爲這也是非常實用的。假設有自定義的告警模板場景,就會了解到宏的便捷性。在告警模板中可以調用內置宏,比如被監控主機的名稱、IP,以及告警事件的一些信息等。因爲通用的告警模板無法事先知道這些信息,所以肯定是通過宏來調用展示這些信息。

第三個場景是底層自動發現的LLD,也就是剛纔介紹過的。底層自動發現意味着要獲取的對象的信息都是未知的,因爲每臺主機掃描出來的對象肯定是不同的,而且經常不知道它們的信息。在這種情況下,可以使用LLD宏來代替對應的信息位置。比如掃描接口時,一開始根本不知道它的接口名稱,可以先用LLD宏"interface name"進行代替。通過自動發現監控項獲取LLD宏的信息,可以對返回的信息進行相應的創建和填充。

剛纔我們介紹了一些關於宏、自動發現等內容的使用方法和示例分享。接下來就是模板開發了。除了這些內容,還有其他一些,比如監控項類型等,大家都可以通過官方文檔進行查閱和實踐,這樣會對自己定製開發監控模板有所幫助。

另外,我認爲Zabbix中比較實用的功能之一是多種多樣的告警媒介配置和自定義集成。最常見的高級媒介包括郵件、電話、短信等。當然,還可以集成到企業微信或者一些工單平臺。Zabbix的告警媒介種類繁多,因此瞭解不同客戶的告警媒介需求是很重要的。此外,Zabbix的告警動作也非常靈活,可以根據工作流程制定不同複雜程度的升級方案。Zabbix的告警升級不僅限於發送通知,還可以執行腳本。例如,如果發現告警兩小時後仍未處理,可以執行腳本來解決問題。

另一個我比較推薦的小技巧是關於 Zabbix 中的主機羣組。在 Zabbix 中,主機羣組是支持嵌套的,你可以使用右斜槓進行嵌套。這在實際的使用場景中也非常常見。比如說,有大量的設備需要監控,這些設備可能分佈在全國各地。當然,我們需要對這些設備進行分組和歸納,通常通過主機組進行管理。通過在主機組上添加位置信息,我們可以很方便地對設備進行分類。在 Zabbix 中嵌套主機組,可以通過父羣組查找所有子羣組的組件,這是非常實用的功能。

另外,我也推薦搭配使用主機樹(host tree)。主機樹是 Zabbix 的第三方頁面模塊,可以按主機組的嵌套層級展開主機列表。這樣,你就可以一目瞭然地查看主機的分組情況。

好,講到這裏,我認爲對於 Zabbix 用戶來說,已經進階到了各種監控配置,甚至學習模板開發的階段。因爲一旦掌握到了這些技能,就可以應對絕大多數的監控需求了。最後,需要通過一些實踐逐漸深入。所以,掌握所有 Zabbix 技能的最佳實踐方式之一,就是進行agent自定義監控項的開發。

Zabbix agent除了內置的監控項外,用戶還可以自定義參數來實現非原生監控,這樣就可以提高監控的靈活性和擴展性。舉個例子,比如監控 Linux 服務器的 TCP 端口連接狀態。儘管 Zabbix 6.0 以後已經有內置的監控項可以實現這個功能,但以下示例基於 Zabbix 5.0。

首先,可以通過一條命令獲取不同狀態的連接數量,然後編輯配置文件,利用代理調用該命令,獲取這些連接狀態的統計信息。接着,可以通過剛纔提到的監控項預處理功能,實現對這些監控數據的處理。

通過主監控項獲取所有狀態的統計數據,然後利用主監控項創建依賴監控項,再通過監控項類型和預處理來提取這些數據實現監控。這個思路是很通用的,可以舉一反三,比如監控進程的不同狀態和數量。通過代理自定義監控項和預處理等技術,可以輕鬆實現這類監控需求。

對於 NAS 使用率的監控場景來說,可能需要更復雜的處理,因爲可能需要自行開發腳本來獲取數據。整個流程可能會更加細緻,需要考慮到數據的獲取、處理和存儲等方面。

這個設計思路很有意義,特別是結合了底層自動發現功能。通過自動發現,可以掃描出需要監控的實例,並返回有關這些實例的信息,如地域、支付信息等。這些信息可以用來生成相應的監控項,實現對雲上NAS實例數據的監控。

通過將這些信息寫入監控項描述中,可以幫助用戶更好地識別實例信息,提高監控的可讀性和可管理性。類似地,對於其他需要對接Zabbix、對接外部數據、通過腳本處理的監控場景,都可以採用類似的方式來實現,這種方法非常靈活和通用。

以上是我的分享,歡迎交流。

本週六5月25日,Zabbix城市行來到了重慶!精彩內容分享,現場見!

延伸閱讀

你咋不上天?上了!歐洲航天局的Zabbix應用

搶先體驗:Zabbix 7.0全新Dashboard和MFA功能,增強可視化、安全性、靈活性!

本文分享自微信公衆號 - Zabbix開源社區(china_zabbix)。
如有侵權,請聯繫 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章