說明：本文譯自 zabbix 官方文檔 Discovery 一節，包括 Network Discovery, Auto Registration和Low level discovery，同時對文章進行了補充以及更詳細的說明。適用于Zabbix 2.0 版本。

發現包括三種類型：

• 網絡發現 ( Network discovery)
  
• 主動客戶端自動注冊 ( Active agent auto-registration )
  
• 低級別發現 ( low-level discovery )
  

下面將依序詳細講解這三種類型的自動發現。到最后做一個簡單的比較和總結。

一、 網絡發現

1. 概覽

zabbix 提供非常有力和靈活的自動網絡發現功能。

通過網絡發現，你可以：

• 加速zabbix部署
  
• 簡化管理
  
• 在不斷變化的環境中使用zabbix而不需要過多的管理
  

zabbix網絡發現基于以下信息：

• IP段
  
• 可用的外部服務(FTP,SSH,WEB,POP3,IMAP,TCP等等)
  
• 從zabbix客戶端接收到的信息
  
• 從SNMP客戶端接收到的信息
  

它不提供：

• 網絡拓撲的發現
  

網絡發現由兩個步驟組成：發現和動作(action)

2. 發現

zabbix周期性地掃描在網絡發現規則中定義的IP段。能夠針對每一個規則配置自身的檢查頻率。每一個規則都定義了一個對指定IP段的服務檢查集合。

注意：發現檢查獨立于其它的檢查。如果某個檢查沒有找到服務(或檢查失敗)，那么其它的檢查也會進行。

在網絡發現模塊上進行的每個對服務和主機(IP)的檢查會產生一個發現事件：

3. 動作

發現事件是相關動作的基礎，如：

• 發現通知
  
• 添加或刪除主機
  
• 啟用或停用主機
  
• 添加主機到某個組中
  
• 從某個組中刪除主機
  
• 將主機鏈接到某個模塊或刪除主機與模塊的鏈接
  
• 執行遠程腳本
  

這些動作都可以針對設備類型，IP，狀態，運行時間，停機時間等進行相應的配置。對網絡發現的基于事件的動作配置的完整細節，可以查看關于操作和關于條件的文檔頁面。

添加主機時的接口創建

當主機通過網絡發現功能被添加時，他們會基于以下規則自動創建接口：

• 服務檢測 – 例如如果一個SNMP檢測成功了，那么一個SNMP接口將會被創建。
  
• 如果一個節點同時響應zabbix客戶端和SNMP請求，那么兩種類型的接口都會被創建
  
• 如果zabbix客戶端和SNMP返回的數據有獨特的標準，那么第一個被發現的接口將會創建為默認的接口，其它的IP地址會被添加為附加接口。
  
• 如果一個主機只響應了客戶端的檢查，那么它就只會創建一個客戶端接口。如果這個主機在后來開始回應SNMP，那么附加的SNMP接口也會添加上去。
  
• 如果3個單獨的
  主機被一開始就創建了，通過獨特的IP這一個標準來發現的，那么發現規則就會被修改，從而使得主機A，B和C有相同的獨特標準結果，B和C被創建為第一個
  主機A的附加接口。各自的主機B和C會保留。在監控-發現中，被添加的接口會以黑體和縮進顯示在”發現的設置”欄中，但是在”被監控的主機”欄中只會顯示
  A，第一個被創建的主機。不會對作為附加接口的IP統計”運行時間/停機時間”。
  

4. 配置網絡發現規則

1） 概覽

配置一個zabbix的網絡發現規則來發現主機和服務：

1. 跳到 配置 – 發現
   
2. 點擊”創建規則”或選擇編輯已經存在的規則
   
3. 編輯發現規則的屬性
   

2） 規則屬性

3）一個真實的場景

在這個例子中我們會建立一個對IP地址段為192.168.1.1-192.168.1.255的本地網站建立網絡發現。

在我們的場景中我們要實現以下功能：

• 發現Zabbix agent在運行的主機
• 每10分鐘運行一次檢查
• 當主機的在線時間超過1小時后添加主機到監控中
• 當主機的離線時間超過24小時后刪除主機
• 添加Linux主機到”Linux server”組中
• 添加Windows主機到”Windows server”組中
• 對Linux主機使用Template_Linux模板
• 對Windows主機使用Template_Windows模板

步驟 1

對我們的IP段定義一個發現規則，如下圖所示：

Zabbix會通過連接Zabbix客戶端然后獲取system.uname的值來試著發現指定IP段
192.168.1.1-192.168.1.255上的主機。從客戶端接收到的值可以用來對不同的操作系統應用不同的操作。比如鏈接Windows服務
器到Template_Windows，鏈接Linux servers到Template_Linux。

這條規則每10分鐘(600秒)執行一次。通過這條規則，Zabbix會自動開始發現和創建基于發現的事件為更多的處理。

步驟 2

為添加被發現的Linux服務器到相應的組和模板定義一個action 。

如果滿足以下條件，動作會被激活：

• “Zabbix agent” 服務處于”up”狀態
• system.uname的值包含 (在規則定義中使用的Zabbix 客戶端鍵) “Linux”
• 在線時間超過1小時（3600秒）

動作將會執行以下操作：

• 添加發現的主機到”Linux servers”組（如果之前沒有添加主機的話會也同時也添加主機）
• 鏈接主機到”Template_Linux”。Zabbix會使用Template_Linux里面的數據項和觸發器自動開始監控主機。

步驟 3

定義一個動作來添加發現的Windows服務器到相應的組的模板。

步驟 4

定義刪除丟失的服務器的動作。

如果”Zabbix agent”服務停止超過24小時，那么服務器將被刪除。

二、主動客戶端自動注冊

1. 概覽

Zabbix 可以允許Zabbix 客戶端自動注冊，在完成自動注冊后服務器就可以監控他們。通過這種方式新的主機可以自動添加到監控中而不需要在服務器上進行手動配置。

當一個之前未知的主動客戶端請求檢查時就可以發生自動注冊。

這個特性可能對自動監控新的云計算中節點非常方便。只要你在云中有一個新的節點，Zabbix就會自動開始收集主機的性能和可用性數據。

主動客戶端自動注冊同樣支持監控使用被動檢查的已添加的主機。當主動客戶端請求檢查時，假設它在配置文件中配置了’ListenIP’ 或 ‘ListenPort’ 參數，這些也會一起發送到服務器。（如果指定了多個IP地址，那么第一個IP地址會發往服務器）

服務器在添加新的自動注冊的主機時會使用接收到的IP地址和端口來配置客戶端。如果沒有收到IP地址，就使用進來的連接中使用的IP地址。如果沒有收到端口值，默認使用10050端口。

2. 配置

配置主動客戶端自動注冊需要你為主動客戶端自動注冊建立一個action 和需要在客戶端配置文件中設置參數。

注意：建立network discovery 不需要有主動客戶端自動注冊。

1）主動客戶端自動注冊的動作

跳轉到 Configuration → Actions, 選擇Auto registration 作為事件源然后點擊Create action：

• 在Action表單，填寫你的動作名稱
• 在條件表單，不需要任何條件
• 在操作表單，添加相關操作，如添加主機，添中到組（比如組Discovered hosts），鏈接到模板等等。
  

小竅門：如果主機自動注冊的主機可能只支持主動監測（如主機與Zabbix服務器被防火墻隔離開了），這時你可能會想創建一個特殊的模板如Template_Linux-active 來鏈接。

2）客戶端配置文件

確保你在客戶端配置文件zabbix_agentd.conf中指定了Zabbix服務器地址：

除非你在zabbix_agentd.conf定義了主機名，否則客戶端的系統主機名會被用來命名主機。在Linux上可以使用hostname來獲取系統主機名。

重啟agent來讓配置文件的改動生效。

3. 使用主機元數據

注意：“使用主機元數據”一節中的內容為Zabbix 2.2 的文檔

當客戶端發送一個自動注冊請求到服務器時它發送它的主機名。在一些時候（比如Amazon云節點）主機名不足夠讓Zabbix服務器來區分發現的主機。主機元數據可以選擇性地用來從客戶端發送其它的信息到服務器。

主機元數可以在客戶端配置文件中zabbix_agentd.conf中配置。有兩種在配置文件中指定元數據的方法：

選項的描述可以在上面的鏈接中查看。

注意：自動注冊請求發生在每次主動客戶端發送一個刷新主動檢查的請求到服務器時。請求間的延時在客戶端中的RefreshActiveChecks 參數中指定。第一次請求將在客戶端重啟之后立即發送。

例1

使用主機元數據來區分Linux和Windows主機

假設你希望主機自動注冊到Zabbix服務器。在你的網絡中有主動Zabbix客戶
端。在你的網絡中有Windows主機和Linux主機，而且在你的Zabbix前端有”Template OS Linux” 和 “Template
OS
Windows”模板。因此在主機注冊時你想將合適的模板應用到注冊的主機上。默認在自動注冊時只有主機名發送到服務器，而這是不夠的。為了確保合適的模
板應用到主機你必須使用主機元數據。

客戶端配置

要做的第一件事是配置客戶端。添加下面這一些到客戶端配置文件：

通過這種方法你就確保存了主機元數據包含了依賴于主機正在運行的”Linux”或”Windows”。下面是這種情況下的一個主機元數據的例子：

Linux: Linux server3 3.2.0-4-686-pae #1 SMP Debian 3.2.41-2 i686 GNU/Linux 

Windows: Windows WIN-0PXGGSTYNHO 6.0.6001 Windows Server 2008 Service Pack 1 Intel IA-32 

別忘了在對配置文件做了任何修改后重啟客戶端。

前端配置

現在你需要配置前端，創建2個動作，第1個動作：

• Name: Linux host autoregistration
  
• Conditions: Host metadata like Linux
  
• Operations: Link to templates: Template OS Linux
  

注意：你可以在這個例子中跳過添加”Add host” 操作。鏈接到模塊前需要先添加主機來讓服務器自動鏈接到模板。

第2個動作：

• Name: Windows host autoregistration
  
• Conditions: Host metadata like Windows
  
• Operations: Link to templates: Template OS Windows
  

例2

使用主機元數據來提供一些基礎的保護，去除不想要的主機注冊。

客戶端配置

添加下行到客戶端配置文件：

這里Linux是平臺，剩下的字符串是一些難以猜解的秘密文本。

別忘了在對配置文件做了任何修改后重啟客戶端。

前端配置

在前端創建一個動作，使用上面談及的難以猜解的秘密來禁止不需要的主機。

• Name: Auto registration action Linux
  
• Conditions:
  
  • Type of calculation: AND
    
  • Condition (A): Host metadata like Linux
    
  • Condition (B): Host metadata like 21df83bf21bf0be663090bb8d4128558ab9b95fba66a6dbf834f8b91ae5e08ae
    
• Operations:
  
  • Send message to users: Admin via all media
    
  • Add to host groups: Linux servers
    
  • Link to templates: Template OS Linux
    

注意單獨這種方法不能提供強保護，因為數據是明碼傳輸的。

三、低級別發現Low-level discovery

1. 概覽

低級別發現為一臺電
腦上的不同實體提供了一種自動創建數據項，觸發器和圖像的方法。比如Zabbix可以自動開始監控你機器上的文件系統或網絡接口，不需要對每個文件系統和
網絡接口手動創建數據項。另外還可以配置Zabbix自動刪除不需要的實體，基于定期執行的發現的結果。

在Zabbix 2.0中，支持三種現成的類型的數據項發現：

• 文件系統發現
  
• 網絡接口發現
  
• SNMP OID發現
  

一個用戶可以定義他們自己的發現類型，只需要他們遵守一個特定的JSON協議。

發現過程的通用架構是這樣的：

首先，一個用戶創建發現規則，在”Configuration” → “Templates” → “Discovery”欄中創建。一個發現規則由以下幾部分組成：

1. 發現必要的實體的數據項（比如文件系統或網絡接口）
2. 數據項，觸發器和基于數據項的值創建的圖形的原形

發現必要實體的數據項就像在其它地方看到的數據項一樣：服務器向Zabbix客戶端
（或其它類型的數據采集端）請求數據項的值，客戶端響應一個文本值。不同之處在于客戶端響應的值應該以一種特定的JSON格式包含一個已發現的實體的列
表。格式的細節只對自定義發現檢查的實施者很重要，它必須知道返回的數據包含一個macro->value對的列表。比如數據
項”net.if.discovery”可能返回兩對數據：”{#IFNAME}” → “lo” 和 “{#IFNAME}” → “eth0″。

注意：在下文中macro將被翻譯為宏。

注意：低級別發現數據項 – vfs.fs.discovery, net.if,discovery 從Zabbix agent 2.0版本開始支持。

注意：在一個Zabbix代理上，低級別發現規則返回的值限制于4000個字符（Oracle數據庫）和2048個字符(IBM DB2數據庫)。

這些宏接著被用在名稱，鍵和其它作為為每個被發現實體創建真實數據項，觸發器和圖形的基礎的原型域?？梢允褂眠@些宏：

• 數據項原型中：
  • 名稱
  • 鍵
  • SNMP OID
  • 計算數據項公式
  • SSH和Telnet腳本
  • 數據庫監控數據項參數
• 觸發器原型中：
  • 名稱
  • 表達式（在引用數據項原型時）
• 圖形原型中：
  • 名稱

當服務器接收到一個發現的數據項的值后，它會查找macro → value對然后對每一對基于他們的原型創建真實的數據項，觸發器和圖形。在上面的net.if.discovery例了中，服務器會為環回接口lo和eth0接口創建一個數據項，觸發器和圖形的集合。

下面的部分將會詳細闡釋上面描述的過程和作為一個執行文件系統，網絡接口和SNMP　OID發現的how-to文檔。最后的部分將描述發現數據項的JSON格式和提供一個例子來說明如何用一個Perl腳本來實施你自己的文件系統發現。

2. 文件系統發現

要配置文件系統發現，按如下所示：

• 跳到 Configuration → Templates
• 在合適的模板行中點擊Discovery

• 在屏幕右上角點擊Create discovery rule
• 填寫表單中的項目

for f in ext2 nfs reiserfs smbfs; do echo $f | grep -E '^ext|^reiserfs' || echo "SKIP: $f"; done

警告：Zabbix 數據庫如果存放在MySQL的話，如果文件系統名稱只是大小寫不同的話，數據庫在創建時必須使用大小寫敏感的方式，這樣才能正確地發現。

注意：發現規則歷史不會保存。

一旦規則被創建，跳轉到規則的數據項上，然后點擊 “Create prototype” 來創建數據項原型。注意在需要文件系統名稱的地方宏{#FSNAME} 是怎樣使用的。當發現規則被處理后，這個宏會被替換為已發現的文件系統。

注意：如果一個數據項原型在創建時是Disabled 狀態，那么它會被添加到一個已發現的實體，但是是disabled 狀態。

我們可以對每個我們感興趣的文件系統指標創建多個數據項原型。

然后我們以類似的方式創建觸發器原型：

圖形原型也一樣：

最后，我們創建了如下所示的發現規則。它有5個婁據項原型，兩個觸發器原型和一個圖形原型。

下面的屏幕截圖說明了發現的數據項，觸發器和圖形是如何看起來像主機的配置。發現的實體都以他們鏈接的發現規則作為前綴。

通過低級別發現創建的數據項（觸發器和圖形也類似）不能被手動刪除。然而如果一個已發現的實體（文件系統，網絡接口等）停止被發現了，那么他們可以自動刪除。在這種情況下這些數據項，觸發器和圖形將會在過了Keep lost resources period 域指定的時間后立即被刪除。

當已發現的實體變為’Not discovered anymore’時，一個橙色的生命時間指示器會顯示在數據項列表上。移動你的鼠標到它們上，一個信息將會顯示他們在刪除前還會留下多少天。

3. 網絡接口發現

發現網絡接口可以通過與文件系統發現幾乎相同的方式來做，除了你可以使用發現規則鍵”net.if.discovery” 來代替”vfs.fs.discovery” 和在過濾器和數據項/觸發器/圖形原型中使用宏{#IFNAME}來代替{#FSNAME}。

比如你可以創建基于 “net.if.discovery”的數據項原型: “net.if.in[{#IFNAME},bytes]“, “net.if.out[{#IFNAME},bytes]“。

查看See above 來獲取關于過濾器的更多信息。

4. SNMP OID發現

在這個例子中，我們會在一個交換機上執行SNMP 發現。首先跳到”Configuration” → “Templates”。

要編輯模板的發現規則，點擊 “Discovery” 欄中的鏈接。

然后點擊 “Create rule” 和填寫下面截屏中的表單信息。

不像文件系統和網絡接口發現，這個項目并不需要包含 “snmp.discovery” 鍵。項目類型選擇SNMP代理就足夠了。

同樣，不像前面的例子，這個發現項目會為每個發現的實體創建兩個宏
{#SNMPINDEX} 和 {#SNMPVALUE}。如果要對返回的值過濾lo接口，你可以將”{#SNMPVALUE}” 放到 “Macro”
然后將 “^([^l]|l$)[^o]?” 正則表達式放到 “Regexp” 文本域中。See above 查看更多關于過濾器的信息。

在 “SNMP OID” 域，你要放置一個這些宏可以產生有意義的值的OD。

為理解我們的意思，讓我們在我們的交換機上執行snmpwalk：

宏 {#SNMPINDEX} 從OID中截取ifDescr
的后面（在這個例子中是1,2,3）獲取值。宏 {#SNMPVALUE} 從相應的OID中獲取值(這里是 WAN, LAN1,
LAN2)。因此我們的 “snmp.discovery” 項目將返回3個macro → value 對的集合：

下面的圖中顯示了我們如何在數據項原型中使用這些宏：

類似的，創建需要的數據項原型：

同樣創建觸發器原型：

和圖形原型：

我們發現規則的匯總如下：

當服務器運行時，它會創建真實的數據項，觸發器和圖形，基于 “snmp.discovery” 所返回的值。在主機配置中他們包含了一個金色的發現規則名稱的前綴。

5. 創建定制的低級別發現規則

創建一個完全定制的低級別發現規則是可能的，發現任何種類的的實體，如數據庫服務器上的數據庫。

要這樣做，應該創建一個定制的項目來返回JSON，指定發現的物體和他們的一些屬性（可選的）。每個實體的宏的數量是不受限制的，雖然內建的發現規則返回一個或兩個宏，但也可以返回更多。

需要的JSON格式可以通過一個例子來解釋。假設我們在運行一個老的Zabbix
1.8客戶端（這個客戶端不支持
“vfs.fs.discovery”)，但是我們仍然需要發現文件系統。這里是Linux上一個簡單的Perl腳本，用來發現掛載的文件系統和輸出
JSON，這個JSON包含文件系統名稱和類型。一種使用它的方法是使用一個鍵為”vfs.fs.discovery_perl”的UserParameter:

它的輸出的一個例子如下（為了清晰進行了重新排版）。定制的發現檢查的JSON必須要遵義相同的格式。

然后，在發現規則的 “Filter” 域，我們可以指定”{#FSTYPE}”作為宏 然后指定 “rootfs|ext3″ 作為正則表達式。

注意：你不必在定制的低級別發現規則中使用宏名FSNAME/FSTYPE，你可以任意使用任何你喜歡的名稱。

四、三種發現的比較和總結

簡單比較

總結

Zabbix通過這種方式，能夠滿足大部分的自動化需求，如：

• 自動添加節點，不管節點是在某一個網段還是分散在多個網段，都可以使用網絡發現或自動注冊中的一種方法來實現節點的監控，這個過程不需要任何的手動配置。
  

• 自動添加數據項，對于一些與主機相關的數據，如主機的網絡接口名稱和數量，使用低級別發現可以很好的解決這個問題。實現自動添加數據項，以及添加對數據項的進一步處理。

文章鏈接：http://www.jsxubar.info/zabbix-discovery-chinese.html