一、自動發現與自動注冊
在上面的介紹中,我們演示了手動添加一台主機的方法,雖然簡單,但是當要添加的主機非常多時,也將變得非常繁瑣,那么有沒有一種方法,可以實現主機的批量添加呢,這樣就會極大的提高運維效率,答案是有的,通過zabbix提供的自動注冊和自動發現功能,就可以實現主機的批量添加。
zabbix的發現包括三種類型,分別是:
自動網絡發現 ( Network discovery)
主動客戶端自動注冊 ( Active agent auto-registration )
低級別發現 ( low-level discovery )
下面依次分別進行介紹。
1.1、zabbix的自動網絡發現
zabbix提供非常有力和靈活的自動網絡發現功能。通過網絡發現,可以實現加速zabbix部署、簡化管理、在不斷變化的環境中使用zabbix而不需要過多的管理
zabbix網絡發現基於以下信息:
IP段自動發現
可用的外部服務(FTP,SSH,WEB,POP3,IMAP,TCP等等)
從zabbix客戶端接收到的信息
從SNMP客戶端接收到的信息
(1)、自動發現的原理
網絡發現由兩個步驟組成:發現和動作(action)。
zabbix周期性地掃描在網絡發現規則中定義的IP段。根據每一個規則配置自身的檢查頻率。每一個規則都定義了一個對指定IP段的服務檢查集合。
動作是對發現的主機進行相關設置的過程,常用的動作有添加或刪除主機、啟用或停用主機、添加主機到某個組中、發現通知等等。
(2)、配置網絡發現規則
點擊web界面的“配置”,然后選擇“自動發現”,即可創建一個發現規則。如下圖所示:
在這個界面中,主要設置的是“IP范圍”,這里設置的是172.16.213.1到254整個213段的IP,設置了范圍之后,zabbix就會自動掃描整個段的IP,那么掃描的依據是什么呢,這個需要在“檢查”選項中配置,在“檢查”選項中點擊“新的”按鈕即可出現“檢查類型”選項,這里面有很多檢查類型,我們就選擇“zabbix客戶端”即可,接着還需要輸入“端口范圍”和“鍵值”兩個選項,端口就輸入10050這個agent的默認端口即可,鍵值可以隨便輸入一個zabbix默認鍵值即可,這里輸入的是“system.uname”,然后點擊下面的“添加”按鈕即可,這樣一個自動發現規則就創建完成了。
綜上所述,這個字段發現規則的意思是:zabbix會自動掃描172.16.213.1到254這個段的所有IP,依次連接這些IP的10050端口,接着通過“system.uname”鍵值看是否能獲取數據,如果能獲取到數據,那么就把這個主機加入到自動發現規則中。
自動發現規則添加完成后,接着,就可以添加自動發現動作了,點擊web界面的“配置”,然后選擇“動作”,在右上角事件源選擇“自動發現”,接着點擊“創建動作”按鈕,即可創建一個自動發現的動作,如下圖所示:
在自動發現動作配置界面中,難點是設置自動發現的條件,“計算方式”選擇默認的“與/或(默認)”即可,要添加觸發條件,可以在“新的觸發條件”選項下選擇觸發條件,觸發條件有非常多,這里選擇紅框內的四個即可,選擇完成后,點擊“添加”就把選擇的觸發條件添加到了上面的“條件”選項中。
除了自動發現條件的設置,還需要設置自動發現后操作的方式,點擊上圖中的“操作”鏈接,進入下圖設置界面:
此界面是設置自動發現主機后,要執行哪些操作,這里重點是設置操作的細節,點擊左下角的“新的”按鈕可以設置多個操作動作,一般情況下設置四個即可,也就是發現主機后,首選自動將這個主機添加到zabbix web上來,然后將“Linux servers”主機組和“Template OS Linux”模板也自動鏈接到此主機下。最后在zabbix web中啟用這個主機。
經過三個步驟的操作,zabbix的自動發現配置就完成了,稍等片刻,就會有符合條件的主機自動添加到zabbix web中來。
1.2、主動客戶端自動注冊
自動注冊(agent auto-registration)功能主要用於Agent主動且自動向Server注冊。與前面的Network discovery具有同樣的功能,但是這個功能更適用於特定的環境,當存在一個條件未知(如agent端的IP地址段、agent端的操作系統版本等信息)時,Agent去請求Server仍然可以實現主機自動添加到zabbix web中的功能。比如雲環境下的監控,雲環境中,IP分配就是隨機的,這個功能就可以很好的解決類似的問題。
配置主動客戶端自動注冊有兩個步驟,分別是:
在客戶端配置文件中設置參數
在zabbix web中配置一個動作(action)
(1)、客戶端修改配置文件
打開客戶端配置文件zabbix_agentd.conf,修改如下配置:
Server=172.16.213.231 ServerActive=172.16.213.231 #這里是主動模式下zabbix服務器的地址 Hostname=elk_172.16.213.71 HostMetadata=linux zabbix.alibaba #這里設置了兩個元數據,一個是告訴自己是linux服務器,另一個就是寫一個通用的帶有公司標識的字符串。
自動注冊請求發生在每次客戶端發送一個刷新主動檢查請求到服務器時。請求的延時在客戶端中配置文件zabbix_agentd.conf的RefreshActiveChecks 參數中指定。第一次請求將在客戶端重啟之后立即發送。
(2)、配置網絡自動注冊規則
點擊web界面的“配置”,然后選擇“動作”,在右上角事件源選擇“自動注冊”,接着點擊“創建動作”按鈕,即可創建一個自動注冊的動作,如下圖所示:
在自動注冊動作配置界面中,難點是設置自動注冊的條件,“計算方式”選擇默認的“與/或(默認)”即可,要添加觸發條件,可以在“新的觸發條件”選項下選擇觸發條件,觸發條件有非常多,這里選擇紅框內的兩個即可,這兩個條件其實都是在zabbix agent端手工配置上去的,選擇完成后,點擊“添加”就把選擇的觸發條件添加到了上面的“條件”選項中。
除了自動注冊條件的設置,還需要設置自動注冊后操作的方式,點擊上圖中的“操作”鏈接,進入下圖設置界面:
此界面是設置自動注冊主機后,要執行哪些操作,這里重點是設置操作的細節,點擊左下角的“新的”按鈕可以設置多個操作動作,一般情況下設置四個即可,也就是發現主機后,首選自動將這個主機添加到zabbix web上來,然后將“Discovered hosts”主機組和“Template OS Linux”模板也自動鏈接到此主機下。最后在zabbix web中啟用這個主機。
經過兩個步驟的操作,zabbix的自動注冊配置就完成了,稍等片刻,就會有符合條件的主機自動添加到zabbix web中來。
1.3、低級別發現Low-level discovery(LLD)
在對主機的監控中,可能出現這樣的情況,例如對某主機網卡eth0進行監控,可以指定需要監控的網卡是eth0,而將網卡作為一個通用監控項時,根據主機操作系統的不同,網卡的名稱也不完全相同,有些操作系統的網卡名稱是eth開頭的,而有些網卡名稱是em開頭的,還有些網卡是enps0開頭的,遇到這種情況,如果分別針對不同的網卡名設置不同的監控項,那就太繁瑣了,此時使用zabbix的低級發現功能就可以解決這個問題。
在Zabbix中,支持三種現成的類型的數據項發現,分別是:
文件系統發現
網絡接口發現
SNMP OID發現
CPU核和狀態
下面是zabbix自帶的LLD key,
vfs.fs.discovery #適用於zabbix agent監控方式
snmp.discovery #SNMP agent監控方式
net.if.discovery #適用於zabbix agent監控方式
system.cpu.discovery #適用於zabbix agent監控方式
可以用zabbix-get來查看key獲取的數據,對於snmp,不能通過zabbix-get來驗證,只能在web頁面中進行配置使用。
下面是zabbix-get的一個例子:
[root@localhost ~]#/usr/local/zabbix/bin/zabbix_get -s 172.16.213.232 -k net.if.discovery {"data":[{"{#IFNAME}":"eth0"},{"{#IFNAME}":"lo"},{"{#IFNAME}":"virbr0-nic"},{"{#IFNAME}":"virbr0"}]}
其中,{#IFNAME}就是一個宏變量,會返回系統中所有網卡的名字。宏變量可以定義在主機、模板以及全局,宏變量都是大寫的。使用宏變量,可以使zabbix功能更加強大。
在自動發現中使用zabbix自帶的宏,固定的語法格式為:
{#MACRO}
zabbix還支持用戶自定義的宏,這些自定義的宏也有特定的語法:
{$MACRO}
在LLD中,常用的內置宏有{#FSNAME}, {#FSTYPE}, {#IFNAME}, {#SNMPINDEX}, {#SNMPVALUE}等。其中,{#FSNAME}表示文件系統名稱,{#FSTYPE}表示文件系統類型,{#IFNAME}表示網卡名稱,{#SNMPINDEX}會獲取OID中最后一個值;例如:
# snmpwalk -v 2c -c public 10.10.10.109 1.3.6.1.4.1.674.10892.5.5.1.20.130.4.1.2 SNMPv2-SMI::enterprises.674.10892.5.5.1.20.130.4.1.2.1 = STRING: "Physical Disk 0:1:0" SNMPv2-SMI::enterprises.674.10892.5.5.1.20.130.4.1.2.2 = STRING: "Physical Disk 0:1:1" SNMPv2-SMI::enterprises.674.10892.5.5.1.20.130.4.1.2.3 = STRING: "Physical Disk 0:1:2"
那么, {#SNMPINDEX}, {#SNMPVALUE}獲取到的值為:
{#SNMPINDEX} -> 1,{#SNMPVALUE} -> "Physical Disk 0:1:0" {#SNMPINDEX} -> 2,{#SNMPVALUE} -> "Physical Disk 0:1:1" {#SNMPINDEX} -> 3,{#SNMPVALUE} -> "Physical Disk 0:1:2"
宏的級別有多種:其優先級由高到低順序如下:
主機級別的宏優先級最高
第一級模板中的宏
第二級模板中的宏
全局級別的宏
因此,zabbix查找宏的順序為:首選查找主機級別的宏,如果在主機級別不存在宏設置,那么zabbix就會去模板中看是否設置有宏。如果模板中也沒有,將會查找使用全局的宏。若是在各級別都沒找到宏,將不使用宏。
二、zabbix自定義監控項
有時候當我們監控的項目在zabbix預定義的key中沒有定義時,這時候我們可以通過編寫zabbix的用戶參數的方法來監控我們要求的項目item。形象一點說zabbix代理端配置文件中的User parameters就相當於通過腳本獲取要監控的值,然后把相關的腳本或者命令寫入到配置文件中的User parameter中,然后zabbix server讀取配置文件中的返回值通過處理前端的方式返回給用戶。
2.1、zabbix agent端開啟Userparameter指令
在zabbix_agent.conf文件中開啟如下參數:
UnsafeUserParameters=1
啟用agent端自定義item功能,設置此參數為1后,就可以使用UserParameter指令了。
UserParameter用於自定義itme。語法格式為:
UserParameter=<key>,<command>
其中:
UserParameter為關鍵字
key為用戶自定義key名字可以隨便起
為我們要運行的命令或者腳本。
一個簡單的例子:
UserParameter=ping,echo 1
代理程序程序將會永遠的返回1當我們在服務器端添加item的key為 ping時候。
稍微復雜的例子:
UserParameter=mysql.ping, /usr/local/mysql/bin/mysqladmin ping|grep -c alive
當我們執行mysqladmin -uroot ping命令的時候如果mysq存活要返回mysqld is alive,我們通過grep–c來計算mysqld is alive的個數,如果mysql存活着,則個數為1,如果不存活很,明顯mysqld is alive的個數為0,通過這種方法我們可以來判斷mysql的存活狀態。
當我們在服務器端添加item的key為mysql.ping時候,對於zabbix代理程序,如果mysql存活,則狀態將返回1,否則,狀態將返回0。
2.2、讓key接受參數
讓key也接受參數的方法使item添加時更具備了靈活性,例如,系統預定義key :
vm.memory.size[<mode>]
其中的mode模式就是用戶要接受的參數,當我們填寫為free時則返回的為內存的剩余大小,如果我們填入的為userd時返回的是內存已經使用的大小。
相關語法如下:
UserParameter=key[*],command
其中,Key的值在主機系統中必須是唯一的,其中*代表命令中接受的參數,command表示命令,也就是客戶端系統中可執行的命令
看下面一個例子:
UserParameter=ping[*],echo $1
如果執行ping[0],那么將一直返回 ‘0’,如果執行ping[aaa],將一直返回 ‘aaa’
三、zabbix的主動模式與被動模式
默認情況下,zabbix server會直接去每個agent上抓取數據,這對於zabbix agent來說,是被動模式,也是默認的一種獲取數據的方式,但是,當zabbix server監控主機數量過多的時候,由Zabbix Server端去抓取agent上的數據,Zabbix server會出現嚴重的性能問題,主要表現如下:
Web操作很卡,容易出現502錯誤
監控圖形中圖層斷裂
監控告警不及時
所以下面主要從兩個方面進行優化,分別是:
通過部署多個zabbix Proxy模式做分布式監控
調整Zabbix Agentd為主動模式
Zabbix Agentd主動模式的含義是Agentd端主動匯報自己收集到的數據給Zabbix Server,這樣,Zabbix Server就會空閑很多,下面介紹下如何開啟agent的主動模式。
3.1、zabbix Agentd配置調整
修改zabbix_agentd.conf配置文件,主要是如下三個參數:
ServerActive=172.16.213.231 Hostname=172.16.213.232 StartAgents=1
ServerActive是指定Agentd收集的數據往哪里發送,Hostname必須要和zabbix web端添加主機時的主機名對應起來,這樣zabbix Server端接收到數據才能找到對應關系,StartAgents默認為3,要關閉被動模式,可設置StartAgents為0即可,關閉被動模式后,agent端的10050端口也關閉了,這里為了兼容被動模式,沒有把StartAgents設為0,如果一開始就是使用主動模式的話,建議把StartAgents設為0,關閉被動模式。
3.2、Zabbix Server端配置調整
如果開啟了agent端的主動發送數據模式,還需要在zabbix Server端修改如下兩個參數,保證性能。
StartPollers=10 #把這個zabbix Server主動收集數據進程減少一些。 StartTrappers=200 #把這個負責處理Agentd推送過來數據的進程開大一些。
3.3、調整模板
因為收集數據的模式發生了變化,因此還需要把所有的監控項的監控類型由原來的“zabbix客戶端”改成“zabbix客戶端(主動式)”。
這樣經過三個步驟的操作,就完成了主動模式的切換,調整之后,可以觀察zabbix server的負載,應該會降低不少,在操作上,服務器也不卡了,圖層也不裂了,zabbix的性能問題解決了。