通過前面章節(jié)的學習，你會發(fā)現(xiàn)Zabbix是一個非常靈活、功能強大的監(jiān)控系統(tǒng)，但是在實際環(huán)境中配置好Zabbix是一個非常繁重的工作。所幸的是Zabbix提供了一些工具，能夠讓Zabbix自動化的完成任務，讓運維工作變的輕松。
克井網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)建站！從網(wǎng)頁設計、網(wǎng)站建設、微信開發(fā)、APP開發(fā)、自適應網(wǎng)站建設等網(wǎng)站項目制作，到程序開發(fā)，運營維護。創(chuàng)新互聯(lián)建站于2013年開始到現(xiàn)在10年的時間，我們擁有了豐富的建站經(jīng)驗和運維經(jīng)驗，來保證我們的工作的順利進行。專注于網(wǎng)站建設就選創(chuàng)新互聯(lián)建站。
Zabbix的自動化工具主要有networkdiscovery（網(wǎng)絡發(fā)現(xiàn)）、active agentauto-registration（主動式代理自動注冊）和 Low-leveldiscovery（低級發(fā)現(xiàn)）。
Zabbix中網(wǎng)絡發(fā)現(xiàn)由兩部分組成：discovery（發(fā)現(xiàn)）和actions（動作），首先通過定期掃描網(wǎng)絡，按照預先定義的規(guī)則搜索網(wǎng)絡中的服務器或設備。當發(fā)現(xiàn)符合條件的服務器或設備時生成發(fā)現(xiàn)事件，然后結合我們定義的基于發(fā)現(xiàn)事件的動作，發(fā)現(xiàn)并添加/刪除主機和其他一些簡單的管理，依照網(wǎng)絡環(huán)境快速的搭建監(jiān)控系統(tǒng)。這些動作包括：
創(chuàng)建或刪除主機。
啟用或禁用主機。
添加主機到主機組。
從主機組中刪除。
鏈接模板到主機或取消鏈接的模板。
發(fā)送通知。
執(zhí)行遠程命令。
在指定的IP地址范圍中，Zabbix使用下列三種方法檢測網(wǎng)絡中的服務器或設備：
從Zabbix agent接收的信息（不支持加密模式）。
從SNMP agent接收的信息。
基于服務（FTP、SSH、WEB、POP3、IMAP、TCP等）的可用性。
?
每一次完成一個主機（IP）和服務的檢測時，網(wǎng)絡發(fā)現(xiàn)會生成一個發(fā)現(xiàn)事件?？缮墒录牧斜砣缦拢?/p>
Service Discovered：第一次發(fā)現(xiàn)或者服務的狀態(tài)以前是down，現(xiàn)在的狀態(tài)是up。
Service Up：服務的狀態(tài)一直是up。
Service Lost：服務的狀態(tài)以前是up，現(xiàn)在的狀態(tài)是down。
Service Down：服務的狀態(tài)一直是down。
Host Discovered：主機上所有服務以前的狀態(tài)是down，現(xiàn)在至少有一個服務的狀態(tài)是up。
Host Up：主機上至少有一個服務的狀態(tài)一直是up。
Host Lost：主機以前至少有一個服務的狀態(tài)是up，現(xiàn)在所有服務的狀態(tài)是down。
Host Down：主機上所有服務的狀態(tài)一直是down。
如果在動作中選擇了Add host操作，新發(fā)現(xiàn)的主機會自動創(chuàng)建，同時還可以在動作中定義下列操作：
允許主機
禁用主機
添加主機到主機組
鏈接模板到主機
創(chuàng)建主機時，主機名稱以Zabbix server或proxy server進行DNS反向查詢的結果命名，如果反向查詢失敗則用IP地址命名。反向查詢失敗后是否重試取決于discovery在哪里執(zhí)行，在proxyserver上查詢失敗后不再重試。
新創(chuàng)建的主機名稱在Zabbix server中已經(jīng)存在時，新創(chuàng)建主機的名稱會在名稱后面添加_2表示第二個重名的主機，_3表示第三個重名的主機，以此類推。
新創(chuàng)建的主機默認添加到Discovered hosts group主機組中，這個默認值是在Administration--> General --> Other頁面中的Group fordiscovered hosts參數(shù)中配置的。如果你希望主機添加到其他主機組中，需要在動作的操作中添加 Remove from host groups（指定Discovered hosts），同時添加Add tohost groups（指定其他的主機組）。
如果在網(wǎng)絡發(fā)現(xiàn)規(guī)則運行中在指定的IP范圍中沒有發(fā)現(xiàn)已經(jīng)創(chuàng)建的主機時，這個由網(wǎng)絡發(fā)現(xiàn)規(guī)則創(chuàng)建的主機會自動刪除。
?
通過網(wǎng)絡發(fā)現(xiàn)創(chuàng)建新的主機后，還需要在主機中創(chuàng)建相應的接口，創(chuàng)建接口時依照下列原則：
檢測服務。例如，如果SNMP檢測成功，將創(chuàng)建一個SNMP接口。
如果主機同時響應了Zabbixagent和SNMP的請求，兩種接口都會創(chuàng)建。
如果以Zabbix agent 或SNMP返回的數(shù)據(jù)作為唯一條件，發(fā)現(xiàn)主機的第一個接口將會成為默認接口，其他的IP地址將添加為附加接口。
如果一個主機只響應agent checks，創(chuàng)建的接口只有agent 接口。如果以后響應SNMP，將添加額外的SNMP接口。
?
近日完成《深入淺出?zabbix 4.0》視頻教程的錄制并正式發(fā)布，該教程基于 zabbix 4.2 ，對Zabbix進行全面講解。歡迎大家圍觀。課程鏈接：https://edu.51cto.com/sd/ce000?
網(wǎng)絡發(fā)現(xiàn)的配置分兩部分，即配置rule（規(guī)則）和action（動作）。
在Configuration --> Discovery頁面的右上角點擊Create rule按鈕創(chuàng)建網(wǎng)絡發(fā)現(xiàn)規(guī)則，或者在頁面列表中點擊規(guī)則的名稱修改配置。配置頁面如下圖12-1所示。
??
圖 12-1
Rules配置頁面中各參數(shù)的含義如下：
Name：唯一的規(guī)則名稱。例如 Local network。
Discovery by proxy：選擇no proxy是在Zabbix server上執(zhí)行discovery，選擇proxy server的名稱是在相應的proxy server上執(zhí)行。
IP range：發(fā)現(xiàn)的IP地址范圍，支持多種格式：
單IP地址：192.168.10.10。
IP地址范圍：192.168.1-10.1-255。包含的地址總數(shù)不能超過64000個。
IP 掩碼：192.168.10.0/24。支持的IPv4掩碼為 /16 - /30，IPv6的掩碼為 /112 - /128。
IP地址列表：192.168.1.1-255, 192.168.2.1-100, 192.168.4.0/24
此外還支持spaces（空格）、tab，可以定義多行。
Delay (in sec)：自上一次執(zhí)行規(guī)則之后再次執(zhí)行規(guī)則的時間間隔，默認值為3600秒。
Checks：用于發(fā)現(xiàn)主機或服務的檢測方法。支持的檢測方法有：SSH、LDAP、SMTP、FTP、HTTP、HTTPS、POP、NNTP、IMAP、TCP、Telnet、Zabbix agent、SNMPv1 agent、SNMPv2 agent、SNMPv3 agent、ICMP ping?；趨f(xié)議的發(fā)現(xiàn)只有net.tcp.service[]函數(shù)檢測主機，SNMP通過查詢SNMP OID檢測主機，Zabbixagent在沒有加密的傳輸模式下查詢item檢測主機。定義協(xié)議相關的Ports參數(shù)時，可以定義單端口（如22）、端口范圍（如22-45）、端口列表（如22-45,55,60-70）。
Device uniqueness criteria：設備唯一性的標準。有兩種：
IP address：不會對多個單IP地址的設備進行處理。如果相同IP地址的設備已經(jīng)存在，將視為已經(jīng)發(fā)現(xiàn)，不會創(chuàng)建新的主機。
Zabbix agent 或SNMP的檢測方法：使用Checks自動中定義的agent或SNMP的方法。
Enabled：勾選為啟用規(guī)則，Zabbix server將執(zhí)行該規(guī)則。
配置好規(guī)則后，接下來繼續(xù)配置動作。在Configuration --> Actions頁面的右上角的Event source下拉框中選擇Discovery，點擊Create action按鈕創(chuàng)建基于Discovery事件的動作，或者在頁面列表中點擊動作的名稱修改配置。
配置動作最主要的就是配置Conditions（條件）和Operations（操作）。在Conditions中我們可以定義一系列的條件，如Discoverystatus、Service type、Host IP、Uptime/Downtime等，其中Received value條件是特別有用的，通過它可以區(qū)分不同的操作系統(tǒng)、應用程序的版本等。如下圖12-2所示。
?
圖 12-2
通過Conditions中配置的各種條件過濾出需要的主機之后，就需要采取一些操作，這些操作的配置在Operations標簽中進行。如下圖12-3所示。
圖 12-3
從Operation type中我們可以看到可選的操作，通過這些操作可以自動的將符合發(fā)現(xiàn)規(guī)則的服務器或設備進行創(chuàng)建（或刪除）主機、添加到主機組、鏈接模板等，從而實現(xiàn)自動化的監(jiān)控。尤其是在經(jīng)常有大量的新增設備或移除的環(huán)境中，更能體現(xiàn)出Zabbix 網(wǎng)絡發(fā)現(xiàn)的優(yōu)勢。
?
在例子中假設網(wǎng)路的IP地址范圍是192.168.1.1-192.168.1.254。需要實現(xiàn)的目標如下：
發(fā)現(xiàn)運行Zabbix agent的主機。
每10分鐘運行一次discovery。
上線時間大于1小時的設備添加主機。
下線時間大于24小時的設備刪除主機。
添加Linux主機到Linux servers主機組中。
鏈接Template OSLinux 到Linux 主機。
鏈接Template OSWindows到Windows主機。
第一步，定義網(wǎng)路發(fā)現(xiàn)規(guī)則。如下圖12-4所示。
圖 12-4
Zabbix將在IP地址范圍192.168.1.1 – 192.168.1.1254中通過Zabbix agent嘗試發(fā)現(xiàn)主機，并使用system.uname收集系統(tǒng)信息，在動作中可以利用收集的系統(tǒng)信息區(qū)分不同的操作系統(tǒng)，采取不同的操作，例如鏈接Template OS Windows模板到Windows服務器，鏈接Template OS Linux模板到Linux服務器。
這個規(guī)則創(chuàng)建后，Zabbix每10分鐘執(zhí)行一次（600秒），并生成基于發(fā)現(xiàn)規(guī)則的事件進行下一步處理。
第二步，定義一個動作將發(fā)現(xiàn)的Linux服務器添加指定的主機組和模板，如下圖12-5所示。
圖 12-5
從上圖中我們可以看到，當Zabbix agent服務的狀態(tài)是Up，system.uname的值中包含Linux，上線時間大于等于1小時（3600秒）的條件滿足時，動作將被激活，執(zhí)行相應的操作，如下圖12-6所示。
圖 12-6
從上圖12-6中我們可以看到動作將執(zhí)行下面的操作：
添加發(fā)現(xiàn)的主機到Linuxservers主機組中（如果主機還沒有添加時也會添加主機）。
鏈接Template OSLinux 到發(fā)現(xiàn)的主機。Zabbix將使用模板中定義的監(jiān)控項和觸發(fā)器自動對主機進行監(jiān)控。
第三步，定義一個動作將發(fā)現(xiàn)的Linux服務器添加指定的主機組和模板，如下圖12-7所示。
圖 12-7
?
第四步，定義一個刪除主機的動作，如下圖12-8所示。
圖 12-8
如果發(fā)現(xiàn)的主機Zabbix agent 服務的狀態(tài)是down，并超過24小時（86400秒）時服務器將被刪除。
Active agent auto-registration（主動式代理自動注冊）提供了另一種自動化的方法，不同與網(wǎng)絡發(fā)現(xiàn)。網(wǎng)絡發(fā)現(xiàn)時從server 端掃描網(wǎng)絡，發(fā)現(xiàn)并完成一些自動化操作，而主動式代理自動注冊是active agent 向Zabbix server發(fā)送查詢監(jiān)控項檢測清單的請求時，主動將hostname、host metadata等信息提供給Zabbix server，由Zabbix server完成一些自動化操作。
使用主動式代理自動注冊，可以自動添加active agent主機為監(jiān)控主機并且不需要在Zabbixserver上做任何手工配置。同時也支持對監(jiān)控主機使用Passivechecks進行監(jiān)控，當active agent向Zabbix server發(fā)送查詢監(jiān)控項檢測清單的請求時，也會把配置文件zabbix_agentd.conf中設置的 ListenIP（agent監(jiān)聽的IP地址）和ListenPort（agent監(jiān)聽的端口）提供給Zabbix server，在ListenIP中指定了多個IP地址時只有第一個IP地址會發(fā)送給Zabbix server。
當添加一個新的自動注冊的主機時，會使用 agent配置文件中設置的IP地址和端口，如果在配置文件中沒有設置IP地址，那在添加主機時會使用當前網(wǎng)路連接使用的IP地址。如果在配置文件中沒有設置端口就使用默認的10050端口。
這種方式特別適合在云基礎架構中實現(xiàn)新的云計算節(jié)點的自動化監(jiān)控，當一個新節(jié)點開始運行時，Zabbix將自動監(jiān)控節(jié)點，收集性能指標，監(jiān)控節(jié)點的可用性。
?
首先需要在配置文件zabbix_agentd.conf中配置一些參數(shù)。
# vi /etc/zabbix/zabbix_agentd.conf
ServerActive=192.168.10.102
Hostname=test-server
其中ServerActive參數(shù)時必須配置的，格式為IP:port（或 hostname:port），可以指定單個或多個Zabbix server的IP地址和端口（用逗號分隔），如果沒有指定端口則使用系統(tǒng)默認的端口。例如ServerActive=127.0.0.1:20051,zabbix.mydomain.com。也支持IPv6地址。
Hostname是唯一的大小寫敏感的主機名稱，在active（主動模式）中需要設置，自動注冊主機時使用這個名稱。如果沒有設置這個參數(shù)，注冊主機時會使用HostnameItem參數(shù)的值。配置文件中HostnameItem設置為system.hostname，即使用system.hostname這個Key收集主機名稱，在Linux系統(tǒng)中實際上就是執(zhí)行hostname命令收集主機名稱。
當完成上述配置后，重啟Zabbix agent服務。接下來創(chuàng)建一個基于auto-registration事件的動作。在Zabbix 前端頁面中，點擊Configuration--> Actions進入Actions列表頁面，在頁面右上角Event source下拉框中選擇 Autoregistration，點擊旁邊的Create action按鈕。在Action配置頁面中的Conditions標簽中添加條件Host name like test-server，如下圖12-9所示。
圖 12-9
在Operations標簽中添加需要執(zhí)行的操作，如下圖12-10所示。
圖 12-10
在鏈接模板時需要注意，如果自動注冊的主機只支持active（主動式）監(jiān)控方式，例如主機和Zabbixserver之間有防火墻，Zabbix server不能直接訪問到自動注冊的主機，在這種情況下需要指定一個監(jiān)控項都使用Zabbix agent（active）監(jiān)控方式的模板。例如Template_Linux-active。
如果自動注冊的主機中監(jiān)控項的監(jiān)控方式使用Zabbix agent（被動式），需要在agent配置文件中下面的幾個參數(shù)。
# vi /etc/zabbix/zabbix_agentd.conf
Server=192.168.10.102
ListenIP=
ListenPort-
其中Server參數(shù)需要設置為Zabbix server的IP地址或主機名，否則在agent的日志中出現(xiàn)failed to accept an incoming connection: connection from"192.168.10.102" rejected, allowed hosts: ""的信息，不能收集監(jiān)控項的值。
ListenIP（agent監(jiān)聽的IP地址）和 ListenPort（agent監(jiān)聽的端口）可以設置也可以不設置，如果在配置文件中沒有設置ListenIP，那在添加主機時會使用當前網(wǎng)路連接使用的IP地址。如果在配置文件中沒有設置ListenPort就使用默認的10050端口。
動作配置完成后，稍等一會在主機列表中你就能看到自動注冊的主機。在Monitoring --> Latest data頁面中可以查詢自動注冊主機的監(jiān)控項的值。
當active agent發(fā)送自動注冊的請求到Zabbixserver的同時，會把agent配置文件中的Hostname也發(fā)送給Zabbixserver，但是在實際環(huán)境中，僅僅通過Hostname是不夠的，在Hostname無法區(qū)分主機的情況下，以Hostname作為條件會出現(xiàn)很多問題。因此Zabbix中引入新的方法Host metadata來解決這個問題。
在zabbix_agentd.conf配置文件中，有兩種方法可以配置Hostmetadata。Host metadata僅在active agent自動注冊過程中使用
HostMetadata，可設置長度不超過255個字符的字符串。如果沒有設置該參數(shù)，將從HostMetadataItem參數(shù)收集。如果設置的值長度超過255或字符串中使用了非UTF-8的字符串時，agent會啟動失敗并在日志中生成錯誤信息。
HostMetadataItem，該參數(shù)僅在沒有設置HostMetadata參數(shù)時使用。支持UserParameters和aliases，支持system.run[]（無論EnableRemoteCommands參數(shù)是否設置）。如果指定的監(jiān)控項返回值超過255個字符時會在日志中生成錯誤信息。另外監(jiān)控項的返回值必須是一個UTF-8字符串，否則它將被忽略。
?
實例一：使用host metadata區(qū)分Linux和Windows主機。
1、?在agent配置文件中設置：HostMetadataItem=system.uname。重啟Zabbix agent服務。
2、?在Zabbix前端頁面配置2個動作。
動作 1：
??????????????????? Name：Linux host autoregistration
??????????????????? Conditions：Host metadata like Linux
??????????????????? Operations：Link to Templates: Template os Linux
動作 2：
??????????????????? Name：Windows host autoregistration
??????????????????? Conditions：Host metadata like Windows
??????????????????? Operations：Link to templates: Template OS Windows
你可能注意到在Operations中只加入了一個鏈接到模板操作，沒有添加主機的操做。實際上這是沒有問題的，因為鏈接到模板的操作首先需要添加一個主機，在這里Zabbix server會自動添加主機。
?
實例二：使用host metadata添加特定的主機。
1、?在agent配置文件中設置：HostMetadata=Linux onlydemo。重啟Zabbix agent服務。
2、?在Zabbix前端頁面配置動作。
Name：Linux host autoregistration
Type of calculation：AND
Conditions (A)：Host metadata like Linux
Conditions (B)：Host metadata like onlydemo
Operations：Link to Templates: Template os Linux
??????????????????? ?? Add to host groups: Linux servers
?
12.3 Low-level discovery
Low-level discovery是Zabbix中提供的一種非常有用的功能，通過在模板中配置low-level discovery，可以自動創(chuàng)建監(jiān)控項、觸發(fā)器、圖形和主機。尤其是在監(jiān)控對象動態(tài)變換的環(huán)境中，可以定期的執(zhí)行發(fā)現(xiàn)規(guī)則，自動添加或刪除監(jiān)控對象，例如網(wǎng)絡接口的數(shù)量和類型、文件系統(tǒng)的類型等，如果為主機的每個網(wǎng)絡接口和每一種文件系統(tǒng)手工創(chuàng)建監(jiān)控項和觸發(fā)器，可以想見工作量是巨大的，而通過Low-level discovery可以代替手工方式自動化的完成相關任務。
發(fā)現(xiàn)規(guī)則由監(jiān)控項和基于監(jiān)控項的返回值創(chuàng)建的原型（items、triggers、graphs和host）兩部分組成。發(fā)現(xiàn)規(guī)則中的監(jiān)控項和在主機中定義的監(jiān)控項非常相似，不同的是發(fā)現(xiàn)規(guī)則中監(jiān)控項返回值是一個特定的JSON格式的監(jiān)控對象（如網(wǎng)路接口）的列表，例如net.if.discovery的返回值可能是：{#IFNAME} → lo ?和 {#IFNAME} → eth0。
當Zabbix server接收到發(fā)現(xiàn)規(guī)則中監(jiān)控項的返回值后，會根據(jù)返回值中的macro --> value在原型中創(chuàng)建items、triggers、graphs或hosts。這些宏變量可以在name、keys或其他原型中的字段中使用，這些位置包括：
在item prototypes中
names
key parameters
units
SNMP OIDs
IPMI sensor fields
calculated item formulas
SSH and Telnet scripts
database monitor itemparameters
descriptions
在triggerprototypes 中
names
expressions
URLs
descriptions
在graphprototypes 中
names
在host prototypes中
names
visible names
host group prototype names
?
在Zabbix中支持下列六種發(fā)現(xiàn)規(guī)則：
discovery of file systems
discovery of network interfaces
discovery of CPUs and CPU cores
discovery of SNMP OIDs
discovery using ODBC SQLqueries
discovery of Windows services
另外我們也可以自定義發(fā)現(xiàn)規(guī)則，只需要數(shù)據(jù)格式遵循特定的JSON協(xié)議即可，詳細內(nèi)容如下表12-1所示。
表 12-1
item的key | Item類型 | 返回值 |
vfs.fs.discovery | Zabbix agen | { "data": [ {"{#FSNAME}": {"{#FSNAME}": {"{#FSNAME}": …] } |
net.if.discovery | Zabbix agent | { "data":[ {"{#IFNAME}":" {"{#IFNAME}":" {"{#IFNAME}":" } |
system.cpu.discovery | Zabbix agent | { "data":[ {"{#CPU.NUMBER}":" {"{#CPU.NUMBER}":" {"{#CPU.NUMBER}":" …] } |
db.odbc.discovery | Database monitor | { "data": [ ?? {"{#HOST}": ?" ?? {"{#HOST}": ?" ?? ?{"{#HOST}": " ?? …] } |
snmp.discovery | SNMP (v1, v2, or v3) agent | { "data":[ } |
Service.discovery | Zabbix agent | { "data":[ ?? {"{#SERVICE.DISPLAYNAME}": ?" ??? ?"{#SERVICE.NAME}": " ??? ?"{#SERVICE.PATH}": " ??? ?"{#SERVICE.STARTUPNAME}": " ??? ?"{#SERVICE.STARTUP}": “ ??? ?"{#SERVICE.STATENAME}": " ??? ?"{#SERVICE.STATE}":” ??? ?"{#SERVICE.TYPENAME}": " ??? ?"{#SERVICE.TYPE}": “ ??? ?"{#SERVICE.USER}": " ...] } |
custom.discovery | Any | { "data":[ {"{#CUSTOM1}":" {"{#CUSTOM1}":" {"{#CUSTOM1}":" …] } |
當我們準備開始定義發(fā)現(xiàn)規(guī)則時，可以通過zabbix_get工具查看Key收集的數(shù)據(jù)。例如：
# zabbix_get -s 127.0.0.1 -k net.if.discovery
{"data":[
{"{#IFNAME}":"enp0s3"},
{"{#IFNAME}":"lo"}
]}
?
# zabbix_get -s 127.0.0.1 -k vfs.fs.discovery
{"data":[
{"{#FSNAME}":"/","{#FSTYPE}":"rootfs"},
{"{#FSNAME}":"/sys","{#FSTYPE}":"sysfs"},
{"{#FSNAME}":"/proc","{#FSTYPE}":"proc"},
{"{#FSNAME}":"/dev","{#FSTYPE}":"devtmpfs"},
{"{#FSNAME}":"/sys/kernel/security","{#FSTYPE}":"securityfs"},
{"{#FSNAME}":"/dev/shm","{#FSTYPE}":"tmpfs"},
{"{#FSNAME}":"/dev/pts","{#FSTYPE}":"devpts"},
{"{#FSNAME}":"/run","{#FSTYPE}":"tmpfs"},
…
]}
?
SNMP發(fā)現(xiàn)規(guī)則的Key不能通過zabbix_get工具驗證，只能在Web頁面中進行配置使用。
在Configuration --> Templates頁面中，點擊模板的Discovery列中的鏈接，如下圖12-11所示。
圖 12-11
創(chuàng)建Low-level discovery規(guī)則
在Discovery rules頁面中點擊右上角的Creatediscovery rule按鈕可以創(chuàng)建新的發(fā)現(xiàn)規(guī)則。如下圖12-12所示。
圖 12-12
Discovery rule標簽中各參數(shù)的含義如下：
Name：發(fā)現(xiàn)規(guī)則的名稱。
Type：用于發(fā)現(xiàn)的監(jiān)控方式。
Key：item的key，如vfs.fs.discovery。
Update interval (in sec)：執(zhí)行發(fā)現(xiàn)規(guī)則的間隔時間，單位是秒。如果設置為0，item將停止收集數(shù)據(jù)。
Custom intervals：設置Flexible或Scheduling。
Keep lost resources period (indays)：當發(fā)現(xiàn)狀態(tài)變?yōu)镹ot discoveredanymore時，保留發(fā)現(xiàn)記錄的天數(shù)。最大為3650天。如果設置為0將立即刪除，不會保留。
Description：描述信息。
Enabled：勾選此項為啟用該發(fā)現(xiàn)規(guī)則。
?
Filters標簽中設置filters計算類型，通過點擊Add連接添加多個宏變量。如下圖12-13所示。
圖 12-13
其中各參數(shù)的含義如下：
Type of calculation：計算Filters的類型。有以下幾種類型：
And：必須滿足所有filters。
Or：只有滿足其中一個filters。
And/Or：不同的宏變量使用And，相同的宏變量使用Or。
Custom expression：自定義filters計算，公式中必須包括列表中所有filters，不能超過255個字符。
Filters：使用宏變量匹配正在表達式。在Regular expression中正則表達式可以直接輸入，也可以引用 Administration --> General --> Regular expressions中定義的全局正則表達式。例如只需要監(jiān)測文件系統(tǒng)類型為ext和reiserfs的文件系統(tǒng)，使用{#FSTYPE}匹配正則表達式^ext|^reiserfs，此時監(jiān)控項返回值中只包括文件系統(tǒng)類型為 ext或reiserfs的數(shù)據(jù)。
所有的參數(shù)設置后，點擊Add按鈕保存。
創(chuàng)建文件系統(tǒng)的發(fā)現(xiàn)規(guī)則時，使用Zabbix agent監(jiān)控方式，Key使用vfs.fs.discovery，在Filters中需要使用{#FSTYPE}匹配正在表達式，得到你想要的數(shù)據(jù)，windows agent還支持{#FSDRIVETYPE}，例如{#FSDRIVETYPE} --> “fixed”。正則表達式可以使用命令grep –E進行檢測。例如：for f inext2 nfs reiserfs smbfs; do echo $f | grep -E '^ext|^reiserfs' || echo"SKIP: $f"; done。
創(chuàng)建網(wǎng)絡接口的發(fā)現(xiàn)規(guī)則時，使用Zabbix agent監(jiān)控方式，Key使用net.if.discovery，在Filters中使用{#IFNAME}匹配正則表達式。在此規(guī)則上你可以創(chuàng)建 item prototypes，例如 net.if.in[{#IFNAME},bytes]”,“net.if.out[{#IFNAME},bytes]。
創(chuàng)建CPUs和CPU cores發(fā)現(xiàn)規(guī)則時，使用Zabbix agent監(jiān)控方式，Key使用system.cpu.discovery，這個Key返回兩個macros，即 {#CPU.NUMBER} 和{#CPU.STATUS}，需要注意的是這里不能明確的區(qū)分出實際的物理處理器、內(nèi)核和超線程。{#CPU.STATUS} 在Linux、UNIX 和 BSD系統(tǒng)中返回處理器的狀態(tài)為 online 或 offline，在Windows系統(tǒng)中可能是unknown，意思是已經(jīng)檢測到處理器，但還沒有收集到更多的信息。在此規(guī)則上你可以創(chuàng)建 item prototypes，例如system.cpu.util[{#CPU.NUMBER},
創(chuàng)建SNMP OIDs 的發(fā)現(xiàn)規(guī)則時，不像定義文件系統(tǒng)或網(wǎng)絡接口的發(fā)現(xiàn)規(guī)則，不使用snmp.discovery這個Key，使用SNMP agnet監(jiān)控方式就可以，在SNMPOID字段中定義需要發(fā)現(xiàn)的OIDs，格式為 discovery[{#MACRO1}, oid1, {#MACRO2}, oid2, …,]。如下圖12-14所示。
圖 12-14
創(chuàng)建ODBC SQL查詢的發(fā)現(xiàn)規(guī)則時，需要使用SQL查詢并將結果自動轉換成JSON格式。Key使用db.odbc.select[
圖 12-15
創(chuàng)建Windows服務的發(fā)現(xiàn)規(guī)則時，使用Zabbixagent監(jiān)控方式，Key使用service.discovery，和創(chuàng)建文件系統(tǒng)的發(fā)現(xiàn)規(guī)則方法一樣，在Filters中支持使用下面的這些macros：{#SERVICE.NAME}、{#SERVICE.DISPLAYNAME}、{#SERVICE.DESCRIPTION}、{#SERVICE.STATE}、{#SERVICE.STATENAME}、{#SERVICE.PATH}、{#SERVICE.USER}、{#SERVICE.STARTUP}、{#SERVICE.STARTUPNAME}。在此規(guī)則上你可以創(chuàng)建item prototypes，例如 service.info[{#SERVICE.NAME},]，param可以是state、displayname、path、user、startup和description，如果param沒有指定，默認返回state。{#SERVICE.STATE}和 {#SERVICE.STATENAME}返回相同的內(nèi)容，{#SERVICE.STATE} 返回的是數(shù)值（0 - 7），{#SERVICE.STATENAME}返回的是文字（running,paused、start pending、pause pending、continuepending、stop pending、stopped or unknown）。{#SERVICE.STARTUP}返回的是數(shù)值（0 -4），{#SERVICE.STARTUPNAME}返回的是文字（automatic、automatic delayed、 manual、disabled、unknown）。
創(chuàng)建自定義的發(fā)現(xiàn)規(guī)則時，可以使用任意的監(jiān)控方式。通常使用腳本生成JOSN格式的數(shù)據(jù)，在自定義發(fā)現(xiàn)規(guī)則中，宏變量的數(shù)量沒有限制，
1、Item原型
當發(fā)現(xiàn)規(guī)則創(chuàng)建成功后，在發(fā)現(xiàn)規(guī)則列表中點擊ITEMS列中的item prototypes鏈接，在item prototypes頁面中點擊右上角的Createitem prototype按鈕進入Item prototype配置頁面。如下圖12-16所示。
圖 12-16
在Name和Key中需要使用macro，如上圖中的{#FSNAME}。Application prototypes是一個比較特殊的選項，在這個選項中也可以使用宏變量。在同一個發(fā)現(xiàn)規(guī)則中幾個item prototypes可以使用同一個applicationprototypes。
?
2、Trigger原型
在發(fā)現(xiàn)規(guī)則列表中點擊TRIGGERS列中的? Trigger prototypes鏈接，在Trigger prototypes頁面中點擊右上角的Createtrigger prototype按鈕進入Trigger prototype配置頁面。如下12-17圖所示。
圖 12-17
在Dependencies標簽中可以定義依賴的triggerprototypes。一個觸發(fā)器原型可以依賴于相同發(fā)現(xiàn)規(guī)則下的另一個觸發(fā)器原型或一個常規(guī)的觸發(fā)器。一個觸發(fā)器原型不能依賴于其他發(fā)現(xiàn)規(guī)則下的觸發(fā)器原型或從一個觸發(fā)器原型創(chuàng)建的觸發(fā)器。
?
3、Graph原型
在發(fā)現(xiàn)規(guī)則列表中點擊GRAPHS列中的Graph prototypes鏈接，在Graph prototypes頁面中點擊右上角的CreateGraph prototype按鈕進入Graph prototype配置頁面。如下圖12-18所示。
圖 12-18
?
4、Host原型
???? 在發(fā)現(xiàn)規(guī)則列表中點擊HOSTS列中的Host prototypes鏈接，在Host prototypes頁面中點擊右上角的CreateHost prototype按鈕進入Host prototype配置頁面。如下圖12-19所示。
圖 12-19
在Host 原型中，可以鏈接模板，在host name、visible name和groupprototypes中使用LLD 宏變量。通過Host原型創(chuàng)建的主機是以發(fā)現(xiàn)規(guī)則的名稱為名稱前綴創(chuàng)建的，在Web前端主機列表中，這些主機可以手工刪除，也可以自動刪除（基于發(fā)現(xiàn)規(guī)則中定義的Keep lost resources period (in days)參數(shù)設置）。除了Enable選項和host inventory外，大部分選項都是只讀的。
在Zabbix中提供的模板 Template VirtVMware中，在 Discover VMware VMs 和Discover VMware hypervisors 發(fā)現(xiàn)規(guī)則中定義了Host prototypes，分別用來發(fā)現(xiàn)和創(chuàng)建虛擬機和VMwareESX服務器的監(jiān)控主機，可以作為參考更好的理解Host prototypes。
?
??
本文出自?http://ustogether.blog.51cto.com/8236854/1929748，如需轉載請與作者聯(lián)系。
重慶分公司
重慶分公司
