说明：本文译自 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