Zabbix的發現主要包括三種類型:前端
Zabbix提供很是有利和靈活的自動網絡發現功能。經過網絡發現,能夠實現加速Zabbix部署、簡化管理、在不斷變化的環境中使用Zabbix而不須要過多的管理;linux
zabbix網絡發現基於如下信息:
1)IP段自動發現;
2)可用的外部服務(FTP、SSH、WEB、TCP等);
3)從Zabbix客戶端接收到信息;
4)從SNMP客戶端接收到信息;web
網絡發現主要由兩個步驟組成:發現和動做;vim
Zabbix會週期性地掃描在網絡發現規則中定義的IP地址段。根據每個規則配置自身的檢查頻率。每個規則都定義了一個對指定IP段的服務檢查集合。服務器
動做是對發現的主機進行相關的設置。經常使用的動做有添加主機、刪除主機、啓用主機、停用主機、添加主機到某個主機組中、發現通知等;網絡
如圖:
綜上所述,這個字段發現規則的意思:zabbix會自動掃描192.168.1.1到192.168.1.254這個IP地址段的全部IP地址,以此鏈接這些IP的10050端口,接着經過"system.uname"鍵值查看是否能獲取數據,若是能夠獲取到數據,那麼就把這個主機加入到自動發現規則中。app
自動發現規則添加完成後,接着,就能夠添加自動發現動做了,如圖:
通過以上的操做,zabbix的自動發現配置已經完成,稍等片刻,就會有符合條件的主機自動添加到zabbix web中。分佈式
自動註冊功能主要用於Agent主動且自動向Server註冊。與前面的網絡自動發現有一樣的功能,可是這個功能更適用於特定的環境,當存在一個條件未知(如agent端的IP地址段、agent端的操做系統版本等信息)時,Agent去請求Server仍可實現主機自動添加到zabbix web中的功能。好比雲環境下的監控。雲環境中,IP分配就是隨機的,這個功能就能夠很好的解決相似的問題。ide
配置主動客戶端自動註冊有兩個步驟,以下:工具
打開客戶端配置文件,修改以下配置:
[root@agent ~]# vim /etc/zabbix/zabbix_agentd.conf Server=192.168.1.10 //設置被動模式下的zabbix服務器的IP地址 ServerActive=192.168.1.10 //設置主動模式下的zabbix服務器的IP地址 Hostname=192.168.1.8 HostMetadata= linux zabbix,lzj //設置兩個元數據,一個聲明爲linux服務器,一個寫一個通用的字符串
自動註冊請求發生在每次客戶端發送一個刷新主動檢查請求到服務器時。請求的延時在客戶端中配置文件中的「RefreshActiveChecks」參數中指定。第一次請求將在客戶端重啓以後當即發送。
如圖:
通過以上的操做,zabbix的自動發現註冊已經完成,稍等片刻,就會有符合條件的主機自動添加到zabbix web中。
在Zabbix中,支持三種現成類型的數據項發現,分別是:
1)文件系統發現;
2)網絡接口發現;
3)SNMP OID發現;
4)CPU核和狀態;
zabbix自帶的LLD key,以下:
1)vfs.fs.discovery //適用於zabbix agent監控方式
2)snmp.discovery //適用於SNMP agent監控方式
3)net.if.discovery //適用於zabbix agent監控方式
4)system.cpu.discovery //適用於zabbix agent監控方式
可使用zabbix_get工具來獲取key獲取的數據,對於snmp,不能經過zabbix_get工具進行驗證,只能在web頁面中進行配置使用。
好比:
[root@zabbix ~]# zabbix_get -s 192.168.1.8 -k net.if.discovery {"data":[{"{#IFNAME}":"lo"},{"{#IFNAME}":"virbr0-nic"},{"{#IFNAME}":"virbr0"},{"{#IFNAME}":"ens33"}]}
其中,{#IFNAME}就是一個宏變量,會返回系統中全部網卡的名稱。宏變量能夠定義在主機、模板以及全局,宏變量都是大寫的。使用宏變量,可使zabbix功能更增強大。
在LLD中,經常使用的內置宏變量以下:
1){#FSNAME}表示文件系統名稱;
2){#FSTYPE}表示文件系統類型;
3){#IFNAME}表示網卡名稱;
4){#SNMPINDEX}會獲取OID中最後一個值;
宏級別有不少種,其優先級由高到低順序以下:
主機級別的宏優先級最高;
第一級模板中的宏;
第二級模板中的宏;
全局級別的宏;
所以,zabbix查找宏的順序爲:首先查找主機級別的宏,若是在主機級別不存在宏設置,那麼zabbix就會去模板中查看是否設置有宏。若是模板中也沒有,將會查找使用全局的宏。如果在各級別中都沒有找到宏,將不使用宏。
有時當咱們監控的項目在zabbix預約義的key中沒有定義時,這時咱們能夠經過編寫zabbix用戶參數的方法來監控咱們要求的項目item。形象一點說zabbix代理端配置文件中UserParameters就至關於腳本獲取要監控的值,而後將相關的腳本或命令寫入UserParameters中,而後zabbix server讀取配置文件中的返回值經過處理前端的方式返回給用戶。
[root@agent ~]# vim /etc/zabbix/zabbix_agentd.conf UnsafeUserParameters=1 //啓用agent端自定義item功能,設置此參數爲1後,就可使用UserParameters指令了
UserParameters用於自定義itme。語法格式爲:
UserParameters=<key>,<command> //UserParameters:爲關鍵字; //key:爲用戶自定義key名稱; //command:需運行的命令或腳本;
簡單的例子,以下:
UserParameters=ping, echo 1 //代理程序將會永遠返回1當咱們在服務器端添加item的key爲ping時
讓key也接受參數的方法使item添加時更具有了靈活性。例如:系統於定義key:
vm.memory.size[<mode>] //其中mode模式就是用戶要接受的參數,當咱們填寫爲free時則返回的爲內存的剩餘大小,若是咱們填入的爲userd時返回的內存是已經使用的大小。
語法以下:
UserParameters=key[*],command //其中,key的值在主機系統中必須是惟一的,其中*表明命令中接受的參數,command表示命令,也就是客戶端系統中可執行的命令
舉例:
UserParameters=ping[*],echo $1 //若是執行ping[0],那麼將一致返回’0‘,若是執行ping[aaa],將一直返回’aaa‘
默認狀況下,zabbix server會直接去每一個agent上抓取數據,這對於zabbix agent來講,是被動模式,也是默認的一種獲取數據的方式。可是,當zabbix server監控主機數量過多時,由zabbix server端去抓取agent上的數據,zabbix server會出現嚴重的性能問題。主要表現以下:
1)web界面操做卡頓,容易出現502錯誤; 2)監控圖形中圖層斷裂; 3)監控告警不及時;
因此優化主要從兩個方面進行優化,分別是:
1)經過部署多個zabbix proxy模式作分佈式監控; 2)調整zabbix agentd爲主動模式;
zabbix agentd主動模式的含義是agentd端主動彙報本身收集到的數據給zabbix server,這樣,zabbix server就會空閒不少,下面介紹如何開啓agent的主動模式。
zabbix agent端的配置:
[root@agent ~]# vim /etc/zabbix/zabbix_agentd.conf ServerActive=192.168.1.10 //定義agent端收集的數據送往那個主機 Hostname=192.168.1.8 //名稱需與web頁面添加主機名時對應 StartAgents=1 //StartAgents的默認值爲3,若是須要關閉被動模式,可設置值爲0便可,關閉被動模式後,agent端的10050端口也關閉了,爲了兼容被動模式,沒有將值設爲0,若是一開始就使用主動模式,建議將值設置爲0,關閉被動模式
zabbix server端的配置
agent若是開啓了主動發送數據模式,還需如下操做:
[root@zabbix ~]# vim /usr/local/zabbix/etc/zabbix_server.conf StartPollers=10 //把zabbix server主動收集數據進程減小一些 StartTrappers=200 //將負責處理agent推送來的數據進程開大些
調整模板
由於收集數據的模式發生了變化,所以須要將全部的監控項的監控類型由原來的「zabbix客戶端」改成「zabbix客戶端(主動式)」。
通過以上操做,就完成了主動模式的切換,調整以後,能夠發現zabbix server端的負載,應該會下降很多,操做上卡頓的問題、圖形圖層斷裂的問題也就解決了!
——————————本文到此結束,感謝閱讀——————————