1. 网络发现
概述
Zabbix提供了有效和非常灵活的自动网络发现功能。
正确设置网络发现后，您可以：
-
加快Zabbix部署
-
简化管理
-
在快速变化的环境中使用Zabbix，而无需过多管理
Zabbix网络发现基于以下信息：
-
IP范围
-
外部服务的可用性（FTP，SSH，WEB，POP3，IMAP，TCP等）
-
从Zabbix代理接收的信息（仅支持未加密模式）
-
从SNMP代理接收的信息
它不提供：
-
发现网络拓扑
网络发现基本上包括两个阶段：发现和动作。
发现
Zabbix定期扫描网络发现规则中定义的IP范围。可以为每个规则单独配置检查的频率。
请注意，一个发现规则将始终由单个发现者进程处理。IP范围不会在多个发现者进程之间分割。
每个规则具有一组定义为对IP范围执行的服务检查。
发现检查独立于其他检查进行处理。如果任何检查未找到服务（或失败），则仍会处理其他检查。
由网络发现模块执行的服务和主机（IP）的每个检查生成发现事件。
| 事件 | 检查服务结果 |
|---|---|
| 服务发现 | 该服务是“up”后，“down”或第一次发现。 |
| 服务 | 服务是“连续”的。 |
| 服务丢失 | 服务在“上”之后是“下来”。 |
| 服务下 | 服务是“down”，连续。 |
| 已发现主机 | 在主机的所有服务都“关闭”之后，主机的至少一个服务是“up”。 |
| 主机上 | 主机的至少一个服务是“up”，连续地。 |
| 主机丢失 | 主机的所有服务在至少一个“up”之后是“down”。 |
| 主机关闭 | 主机的所有服务都是“down”的，连续的。 |
操作
发现事件可以是相关操作的基础，例如：
-
正在发送通知
-
添加/删除主机
-
启用/禁用主机
-
将主机添加到组
-
从组中删除主机
-
将主机链接到模板或从模板取消链接
-
执行远程脚本
这些动作可以相对于所述设备类型，IP，状态，运行时间/停机等有关为基于网络的发现事件配置的动作全部细节来配置，看到动作操作和条件页。
主机创建
如果选择添加主机操作，则会添加主机。如果选择导致主机上的操作的操作，则即使添加主机操作丢失，也会添加主机。这样的操作是：
-
启用主机
-
禁用主机
-
将主机添加到主机组
-
链接模板到主机
添加主机时，如果反向查找失败，则主机名是反向DNS查找或IP地址的结果。查找是从Zabbix服务器或Zabbix代理执行的，具体取决于执行发现。如果代理上的查找失败，则不会在服务器上重试。如果具有这样的名称的主机已经存在，则下一个主机将使_2附加到名称，然后_3等。
创建的主机将添加到“ 发现的主机”组（默认情况下，可在管理 → 常规 → 其他中配置）。如果希望将主机添加到其他组，请添加从主机组操作删除（指定“发现的主机”），并添加添加到主机组操作（指定另一个主机组），因为主机必须属于主机组。
如果主机已存在且具有发现的IP地址，则不会创建新主机。但是，如果发现操作包含操作（链接模板，添加到主机组等），则它们在现有主机上执行。
主机删除
从Zabbix 2.4.0开始，如果发现的实体不在规则的IP范围内，则由网络发现规则创建的主机将被自动删除。主机将立即删除。
添加主机时创建接口
当由于网络发现而添加主机时，它们获得根据以下规则创建的接口：
-
检测到的服务 - 例如，如果SNMP检查成功，将创建SNMP接口
-
如果主机响应Zabbix代理和SNMP请求，将创建两种类型的接口
-
如果唯一性标准是Zabbix代理或SNMP返回的数据，则将为主机找到的第一个接口创建为默认接口。其他IP地址将作为附加接口添加。
-
如果主机仅响应代理检查，则将仅使用代理接口创建。如果它以后开始响应SNMP，将添加额外的SNMP接口。
-
如果最初创建了由“IP”唯一性标准发现的3个单独的主机，然后修改发现规则，使得主机A，B和C具有相同的唯一性标准结果，则创建B和C作为A的附加接口，第一主机。个体主机B和C保留。在监控→发现中，添加的接口将显示在“发现的设备”列中，黑色字体和缩进，但“监控主机”列将只显示第一个创建的主机A. 对于被视为附加接口的IP，不会测量“正常运行时间/停机时间”。
2. 配置网络发现规则
配置->自动发现->创建发现规则
| 参数 | 描述 |
|---|---|
| 名称 | 规则的唯一名称。例如，“本地网络”。 |
| 通过代理发现 | 什么执行发现： 无代理 - Zabbix服务器正在执行发现 <代理名称> - 此代理执行发现 |
| IP范围 | 发现的IP地址范围。它可以具有以下格式： 单个IP：192.168.1.33 IP地址 范围：192.168.1-10.1-255。范围受限于覆盖地址的总数（小于64K）。 IP掩码：192.168.4.0/24 支持的IP掩码： IPv4地址为/ 16 - / 30 / IPv6地址为112 - / 128 列表：192.168.1.1-255,192.168.2.1-100,192.168.2.200,192.168.4.0 / 24 由于Zabbix 3.0.0，此字段支持空格，制表和多行。 |
| 延迟（以秒为单位） | 此参数定义Zabbix将执行规则的频率。 在执行先前的发现实例结束之后测量延迟，因此没有重叠。 |
| 检查 | Zabbix将使用这个检查列表进行发现。 支持的检查：SSH，LDAP，SMTP，FTP，HTTP，HTTPS，POP，NNTP，IMAP，TCP，Telnet，Zabbix代理，SNMPv1代理，SNMPv2代理，SNMPv3代理， 基于协议的发现使用net.tcp.service []功能测试每个主机，除了查询SNMP OID的SNMP。通过以未加密模式查询项目来测试Zabbix代理。有关更多详情，请参阅代理商项目。 “端口”参数可以是以下之一： 单端口：22端口 范围：22-45 列表：22-45,55,60-70 |
| 设备唯一性标准 | 唯一性标准可以是： IP地址 - 不处理多个单IP设备。如果具有相同IP的设备已经存在，则将被视为已经发现，并且不会添加新主机。 发现检查类型 - SNMP或Zabbix代理检查。 |
| 启用 | 选中复选框后，规则将处于活动状态，并由Zabbix服务器执行。 如果未标记，则规则不活动。它不会被执行。 |
更改代理设置
由于Zabbix 2.2.0由不同的代理发现的主机总是被视为不同的主机。虽然这允许在不同子网使用的匹配IP范围上执行发现，但是更改已监视子网的代理很复杂，因为代理更改也必须应用于所有发现的主机。例如，在发现规则中替换代理的步骤：
-
禁用发现规则
-
同步代理配置
-
替换发现规则中的代理
-
替换由此规则发现的所有主机的代理
-
启用发现规则
2.1 配置用例
为IP范围为192.168.1.1-192.168.1.254的本地网络设置网络发现。
在我们的场景中，我们要：
-
发现有Zabbix代理运行的那些主机
-
每10分钟运行一次发现
-
如果主机正常运行时间超过1小时，请添加主机以进行监视
-
如果主机停机时间超过24小时，请删除主机
-
将Linux主机添加到“Linux服务器”组
-
将Windows主机添加到“Windows服务器”组
-
使用模板操作系统 Linux for Linux主机
-
使用Windows主机的模板操作系统 Windows
步骤1
为我们的IP范围定义网络发现规则。
步骤2
配置->动作->事件源->自动发现->创建
如果发生以下情况，操作将被激活：
-
“Zabbix代理”服务是“向上”
-
system.uname（我们在规则定义中使用的Zabbix代理键）的值包含“Linux”
-
正常运行时间为1小时（3600秒）或更长时间
该操作将执行以下操作：
-
将发现的主机添加到“Linux服务器”组（如果以前未添加主机，也添加主机）
-
链接主机到“模板操作系统 Linux”模板。Zabbix将自动开始使用来自“Template OSLinux”的项目和触发器监视主机。
步骤3
定义将发现的Windows服务器添加到相应组/模板的操作。
步骤4
定义用于删除丢失的服务器的操作。
3. 活动代理自动注册
概述
可以允许主动Zabbix代理自动注册，之后服务器可以开始监控它们。这样，可以添加新主机进行监控，而无需在服务器上手动配置。
当以前未知的活动代理要求检查时，可能会发生自动注册。
该功能可能非常方便用于新的云节点的自动监视。一旦您在Cloud中有一个新节点，Zabbix将自动开始收集主机的性能和可用性数据。
活动代理自动注册还支持使用被动检查监视添加的主机。当活动代理程序请求检查时，如果它具有配置文件中定义的“ListenIP”或“ListenPort”配置参数，则将这些参数发送到服务器。（如果指定了多个IP地址，则会将第一个IP地址发送到服务器。
服务器，当添加新的自动注册的主机时，使用接收的IP地址和端口配置代理。如果未接收到IP地址值，则使用用于传入连接的IP地址值。如果未接收到端口值，则使用10050。
配置
指定服务器
确保您在代理配置文件 - zabbix_agentd.conf中标识 了Zabbix服务器
ServerActive = 192.168.195.202
除非在zabbix_agentd.conf中特别定义主机名，否则服务器将使用代理位置的系统主机名来命名主机。Linux中的系统主机名可以通过运行'hostname'命令获取。
在对配置文件进行任何更改后重新启动代理。
活动代理自动注册的操作
当服务器从代理接收到自动注册请求时，它调用操作。必须为代理自动注册配置事件源“自动注册”的操作。
设置网络发现不要求活动代理自动注册。
在Zabbix前端，转到配置→动作，选择自动注册作为事件源，然后单击创建操作：
-
在“操作”选项卡中，为操作指定名称
-
（可选）指定条件。如果要使用“主机元数据”条件。
-
在操作选项卡中，添加相关操作，例如 - “添加主机”，“添加到主机组”（例如，发现的主机），“链接到模板”等。
如果将自动注册的主机可能只支持主动监视（例如，从Zabbix服务器防火墙的主机），那么您可能需要创建一个特定的模板，如Template_Linux-active链接到。
使用主机元数据
当代理向服务器发送自动注册请求时，它会发送其主机名。在某些情况下（例如，Amazon云节点），主机名不足以让Zabbix服务器区分发现的主机。主机元数据可以可选地用于将其他信息从代理发送到服务器。
在代理配置文件 - zabbix_agentd.conf 中配置主机元数据。在配置文件中指定主机元数据有两种方法：
主机元数据 HostMetadataItem
每次活动代理程序向服务器发送刷新活动检查的请求时，都会进行自动注册尝试。请求之间的延迟在代理的RefreshActiveChecks参数中指定。第一个请求在代理重新启动后立即发送。
3.1 自动注册实例
使用主机元数据区分Linux和Windows主机。
假设您希望主机由Zabbix服务器自动注册。您的网络上具有活动的Zabbix代理（请参阅上面的“配置”部分）。在您的网络上有Windows主机和Linux主机，并且您的Zabbix前端有“模板操作系统 Linux”和“模板操作系统 Windows” 模板。因此在主机注册时，您需要将相应的Linux / Windows模板应用于正在注册的主机。默认情况下，只有主机名在自动注册时发送到服务器，这可能不够。为了确保正确的模板应用于主机，您应该使用主机元数据。
代理配置
首先要做的是配置代理。将以下行添加到代理配置文件：
HostMetadataItem = system.uname
这样，您可以确保主机元数据将包含“Linux”或“Windows”，具体取决于运行代理的主机。
重新启动代理。
前端配置
现在需要配置前端。创建2个操作。第一个动作：
-
名称：Linux主机自动注册
-
条件：托管元数据如Linux
-
操作：链接到模板：模板操作系统 Linux
在这种情况下，可以跳过“添加主机”操作。链接到模板需要首先添加主机，以便服务器自动执行此操作。
第二个动作：
-
名称：Windows主机自动注册
-
条件：托管元数据（如Windows）
-
操作：链接到模板：模板操作系统 Windows
3.2 自动注册实例
使用主机元数据允许一些基本保护，防止不必要的主机注册。
代理配置
将以下行添加到代理配置文件：
HostMetadata = Linux 21df83bf21bf0be663090bb8d4128558ab9b95fba66a6dbf834f8b91ae5e08ae
其中“Linux”是一个平台，其余的字符串是一些难以猜测的秘密文本。
重新启动代理。
前端配置
在前端中创建动作，使用上述难以猜测的密码来禁止不需要的主机：
-
名称：自动注册操作Linux
-
条件：
-
计算类型：AND
-
条件（A）：像Linux这样的主机元数据
-
条件（B）：像
-
21df83bf21bf0be663090bb8d4128558ab9b95fba66a6dbf834f8b91ae5e08ae的主机元数据
-
-
操作：
-
向用户发送消息：通过所有媒体管理
-
添加到主机组：Linux服务器
-
模板链接：模板操作系统 Linux
-
请注意，这种方法不能提供强大的保护，因为数据是以纯文本传输的。
4. 低级发现
概述
低级发现提供了一种在计算机上为不同实体自动创建项目，触发器和图形的方法。例如，Zabbix可以自动开始监视计算机上的文件系统或网络接口，而无需手动为每个文件系统或网络接口创建项目。此外，可以配置Zabbix根据周期性执行的发现的实际结果自动删除不需要的实体。
在Zabbix中，支持开箱即用的六种类型的发现项目：
-
发现文件系统;
-
发现网络接口;
-
发现CPU和CPU核心;
-
发现SNMP OID;
-
发现使用ODBC SQL查询;
-
发现Windows服务。
如果用户遵循特定的JSON协议，则用户可以定义自己的发现类型。
发现过程的一般架构如下。
首先，用户在“配置”→“模板”→“发现”列中创建发现规则。发现规则包括（1）发现必要实体（例如，文件系统或网络接口）的项目和（2）应当基于项目的值创建的项目，触发器和图形的原型。
发现必要实体的项目类似于其他地方看到的常规项目：服务器向该项目的值请求Zabbix代理程序（或任何类型的项目设置），代理程序用文本值进行响应。不同之处在于代理响应的值应包含以特定JSON格式发现的实体的列表。虽然此格式的详细信息仅对定制发现检查的实施者很重要，但有必要知道返回的值包含一个宏→值对的列表。例如，项目“net.if.discovery”可能返回两对：“{#IFNAME}”→“lo”和“{#IFNAME}”→“eth0”。
这些宏在名称，键和其他原型字段中使用，然后用接收到的值替换，用于为每个发现的实体创建实际项目，触发器，图形或甚至主机。
当服务器接收到发现项目的值时，它查看宏→值对，并且对于每对，基于它们的原型生成真实项目，触发器和图形。在上面的“net.if.discovery”示例中，服务器将为环回接口“lo”生成一组项目，触发器和图形，另一组用于接口“eth0”。
以下部分详细说明了上述过程，并且用作执行上述所有类型的发现的方法。最后一部分描述了发现项目的JSON格式，并给出了如何将您自己的文件系统发现器实现为Perl脚本的示例。
4.1文件系统的发现
要配置文件系统的发现，请执行以下操作：
-
转到：配置 → 模板
-
点击发现一个合适的模板的行
-
单击屏幕右上角的创建发现规则
-
在表单中填写以下详细信息
“ 发现规则 ”选项卡包含常规发现规则属性：
| 参数 | 描述 |
|---|---|
| 名称 | 发现规则的名称。 |
| 类型 | 执行发现的检查类型; 应该是Zabbix代理或Zabbix代理（活动）用于文件系统发现。 |
| 键 | 带有“vfs.fs.discovery”键的项目在许多平台上内置到Zabbix代理中（有关详细信息，请参阅支持的项目键列表），并返回一个带有计算机上存在的文件系统列表及其类型的JSON。 |
| 更新间隔（以秒为单位） | 此字段指定Zabbix执行发现的频率。在开始时，当您只是设置文件系统发现时，您可能希望将其设置为一个小的时间间隔，但一旦知道它的工作原理，您可以将其设置为30分钟或更多，因为文件系统通常不会很频繁地更改。 注意：如果设置为“0”，则不会轮询该项目。然而，如果也存在具有非零值的灵活间隔，则将在灵活间隔持续时间期间轮询该项目。 |
| 自定义间隔 | 您可以创建用于检查项目的自定义规则： 灵活 - 为更新间隔（具有不同频率的间隔）创建 例外计划 - 创建自定义轮询计划。 有关详细信息，请参阅自定义间隔。从Zabix 3.0.0开始支持计划。 |
| 保留丢失的资源期限（天） | 此字段允许您指定发现的实体在其发现状态变为“不再发现”（最多3650天）后将保留（不会被删除）多少天。 注意：如果设置为“0”，实体将立即删除。不推荐使用“0”，因为只是错误地编辑过滤器可能会在要删除的实体中包含所有历史数据。 |
| 描述 | 输入说明。 |
| 启用 | 如果选中，将处理规则。 |
“ 过滤器 ”选项卡包含发现规则过滤器定义：
| 参数 | 描述 |
|---|---|
| 计算类型 | 计算过滤器的以下选项可用： 和 - 所有过滤器必须通过; 或者 - 如果一个过滤器通过就足够了; 和/或 -用途和不同的宏名和或者用相同的宏名; 自定义表达式 - 提供了定义自定义计算过滤器的可能性。公式必须包括列表中的所有过滤器。限制为255个符号。 |
| 过滤器 | 过滤器可用于仅为某些文件系统生成实际项目，触发器和图形。它期望一个POSIX扩展正则表达式。例如，如果你只对C :, D：和E：文件系统感兴趣，你可以把{#FSNAME}放入“正则表达式”中的“Macro”和“^ C | ^ D | ^ E”文本字段。也可以使用{#FSTYPE}宏（例如“^ ext | ^ reiserfs”）和驱动器类型（仅由Windows代理支持）通过使用{#FSDRIVETYPE}宏（例如“固定”）的文件系统类型进行过滤。 您可以在“正则表达式”字段中输入正则表达式或引用全局正则表达式。 为了测试正则表达式，你可以使用“grep -E”，例如： for f in ext2 nfs reiserfs smbfs; do echo $ f | grep -E '^ ext | ^ reiserfs' || echo “SKIP：$ f ” ; 完成 自Zabbix 3.0.0以来，支持Windows上的{#FSDRIVETYPE}宏。 |
如果要正确发现不同大小写不同的文件系统名称，则必须创建MySQL中的Zabbix数据库区分大小写。
不保留发现规则历史记录。
创建规则后，转到该规则的监控项原型，然后按“创建原型”以创建项目原型。请注意在需要文件系统名称的位置使用宏{#FSNAME}。处理发现规则时，此宏将替换为已发现的文件系统。
特定于项目原型的属性：
| 参数 | 描述 |
|---|---|
| 新应用程序原型 | 您可以定义一个新的应用程序原型。 在应用程序原型中，您可以使用低级发现宏，在发现后，将用实际值替换，以创建特定于发现的实体的应用程序。有关更多特定信息，请参阅应用程序发现说明。 |
| 应用原型 | 从现有应用程序原型中选择。 |
| 创建已启用 | 如果选中，项目将添加为启用状态。 如果取消选中，项目将添加到已发现的实体，但处于禁用状态。 |
我们可以为我们感兴趣的每个文件系统指标创建几个项目原型：
然后，我们以类似的方式创建触发器原型(选择原型)：
触发原型特定的属性：
| 参数 | 描述 |
|---|---|
| 创建已启用 | 如果选中，触发器将添加为启用状态。 如果未选中，触发器将添加到已发现的实体，但处于禁用状态。 |
当从原型创建真实触发器时，可能需要灵活地使用什么常数（在我们的示例中为“20”）用于表达式中的比较。查看具有上下文的用户宏如何有助于实现这种灵活性。
您也可以定义触发器原型之间的依赖关系（自Zabbix 3.0起支持）。为此，请转到“ 依赖关系 ”选项卡。触发器原型可以依赖于来自相同低级发现（LLD）规则或常规触发器的另一触发器原型。触发器原型可以不依赖于来自不同LLD规则的触发器原型或者基于从触发器原型创建的触发器。主机触发器原型不能依赖于来自模板的触发器。
我们也可以创建图形原型：
最后，我们创建了一个发现规则，如下所示。它有五个项目原型，两个触发器原型和一个图形原型。
注意：有关配置主机原型，请参阅虚拟机监视中有关主机原型配置的部分。
下面的屏幕截图说明了发现的项目，触发器和图形在主机配置中的样子。发现的实体前缀有一个橙色链接，它们来自于它们的发现规则。
请注意，如果已存在具有相同唯一性标准的实体（例如，具有相同名称的相同键或图形的项），则不会创建发现的实体。
如果发现的实体（文件系统，接口等）停止发现（或不再通过过滤器），则由低级别发现规则创建的项目（类似地，触发器和图形）将被自动删除。在这种情况下，项目，触发器和图形将在“ 保留丢失的资源期”字段传递中定义的天数后删除。
当发现的实体变为“不再发现”时，项目列表中将显示生命期指示器。将鼠标指针移动到其上，将显示一条消息，指示在删除项目之前剩余的天数。
如果实体标记为删除，但未在预期时间被删除（禁用发现规则或项目主机），则下次处理发现规则时，它们将被删除。
如果在发现规则级别更改了包含标记为要删除的其他实体的实体，则不会更新。例如，如果基于LLD的触发器包含标记为要删除的项目，则不会更新。
4.2网络接口的发现
网络接口的发现与发现文件系统完全相同，不同的是您使用发现规则键“net.if.discovery”而不是“vfs.fs.discovery”，并使用宏{#IFNAME}，而不是{#FSNAME}在过滤器和项目/触发器/图形原型中。
您可能希望基于“net.if.discovery”创建的项目原型的示例：“net.if.in [{＃IFNAME}，bytes]”，“net.if.out [{＃IFNAME}，bytes] “。
4.3发现CPU和CPU内核
CPU和CPU核心的发现以与网络接口发现类似的方式完成，除了发现规则键是“system.cpu.discovery”。此发现键返回两个宏 - {＃CPU.NUMBER}和{＃CPU.STATUS}，分别标识CPU订单号和状态。要注意，不能在实际的物理处理器，内核和超线程之间做出明确的区分。Linux，UNIX和BSD系统上的{＃CPU.STATUS}返回处理器的状态，可以是“在线”或“离线”。在Windows系统上，此同一宏可能表示第三个值 - “未知”，表示已检测到处理器，但尚未收集任何信息。
CPU发现依赖代理的收集器进程来保持与收集器提供的数据一致，并节省获取数据的资源。这具有这个项目键不与代理二进制的测试（-t）命令行标志一起工作的效果，其将返回NOT_SUPPORTED状态和指示收集器进程尚未开始的伴随消息。
基于CPU发现可以创建的项目原型包括例如“system.cpu.util [{＃CPU.NUMBER}，
4.4发现SNMP OID
在本例中，我们将在交换机上执行SNMP发现。首先，进入“配置”→“模板”。
要编辑模板的发现规则，请单击“发现”列中的链接。
然后，按“创建规则”，并在下面的屏幕截图中填写表单的详细信息。
与文件系统和网络接口发现不同，该项不一定必须具有“snmp.discovery”键 - SNMP代理的项类型就足够了。
要发现的OID在SNMP OID字段中以以下格式定义： discovery[{#MACRO1}, oid1, {#MACRO2}, oid2, …,]
其中{＃MACRO1}，{＃MACRO2} ...是有效的lld宏名称，oid1，oid2 ...是能够为这些宏生成有意义的值的OID。发现的OID的内置宏{#SNMPINDEX}索引应用于发现的实体。发现的实体按{#SNMPINDEX}宏值分组。
要了解我们的意思，让我们在我们的交换机上执行几个snmpwalks：
$ snmpwalk -v 2c -c public 192.168.1.1 IF-MIB :: ifDescr IF-MIB :: ifDescr.1 = STRING：WAN IF-MIB :: ifDescr.2 = STRING：LAN1 IF-MIB :: ifDescr.3 = STRING：LAN2 $ snmpwalk -v 2c -c public 192.168.1.1 IF-MIB :: ifPhysAddress IF-MIB :: ifPhysAddress.1 = STRING：8：0：27：90：7a：75 IF-MIB :: ifPhysAddress.2 = STRING：8：0：27：90：7a：76 IF-MIB :: ifPhysAddress.3 = STRING：8：0：27：2b：af：9e
并将SNMP OID设置为： discovery[{#IFDESCR}, ifDescr, {#IFPHYSADDRESS}, ifPhysAddress]
现在，这条规则将发现设置为{} #IFDESCR宏实体WAN，LAN1和LAN2，{} #IFPHYSADDRESS宏设置为8：0：27：90：7A：75，8：0：27：90：7A：76和8：0：27：图2b：AF：9e中，{#SNMPINDEX}宏设定为所发现的OID索引1，2和3：
{
“data”：[
{
“{#SNMPINDEX}”：“1”，
“{#IFDESCR}”：“WAN”，
“{#IFPHYSADDRESS}”：“8：0：27：90：7a：75”
}，
{
“{#SNMPINDEX}”：“2”，
“{#IFDESCR}”：“LAN1”，
“{#IFPHYSADDRESS}”：“8：0：27：90：7a：76”
}，
{
“{#SNMPINDEX}”：“3”，
“{#IFDESCR}”：“LAN2”，
“{#IFPHYSADDRESS}”：“8：0：27：2b：af：9e”
}}
]]
}}
如果实体没有指定的OID，则对于该实体将省略相应的宏。例如，如果我们有以下数据：
ifDescr.1“Interface＃1” ifDescr.2“Interface＃2” ifDescr.4“Interface＃4” ifAlias.1“eth0” ifAlias.2“eth1” “ace2” ifAlias.5“eth4”
然后在这种情况下，SNMP发现discovery[{#IFDESCR}, ifDescr, {#IFALIAS}, ifAlias]将返回以下结构：
{
“data”：[
{
“{#SNMPINDEX}”：1，
“{#IFDESCR}”：“Interface＃1”，
“{#IFALIAS}”：“eth0”
}，
{
“{#SNMPINDEX}”：2，
“{#IFDESCR}”：“Interface＃2”，
“{#IFALIAS}”：“eth1”
}，
{
“{#SNMPINDEX}”：3，
“{#IFALIAS}”：“eth2”
}，
{
“{#SNMPINDEX}”：4，
“{#IFDESCR}”：“接口＃4”
}，
{
“{#SNMPINDEX}”：5，
“{#IFALIAS}”：“eth4”
}}
]]
}}
以下屏幕截图说明了如何在项目原型中使用这些宏：
再次，根据需要创建尽可能多的项目原型：
除了触发器原型：
图形原型：
我们的发现规则的摘要：
当服务器运行时，它将根据SNMP发现规则返回的值创建实际项目，触发器和图形。在主机配置中，它们以橙色链接作为前缀，它们来自它们的发现规则。
3.5使用ODBC SQL查询进行发现
这种类型的发现是使用SQL查询完成的，其结果自动转换为适用于低级发现的JSON对象。SQL查询使用类型为“数据库监视器”的项来执行。因此，ODBC监视页面上的大多数指令适用于获得有效的“数据库监视器”发现规则，唯一的区别是应该使用“db.odbc.discovery [
作为一个说明如何将SQL查询转换为JSON的实际示例，让我们考虑通过对Zabbix数据库执行ODBC查询来低级发现Zabbix代理。这对于自动创建“zabbix [proxy，
让我们从发现规则配置开始：
这里，以下对Zabbix数据库的直接查询用于选择所有Zabbix代理以及它们正在监视的主机数。可以使用主机数量，例如，过滤掉空代理：
mysql> SELECT h1.host，COUNT（h2.host）AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN（5，6）GROUP BY h1.host; + --------- + ------- + | 主机| 计数| + --------- + ------- + | 日本1 | 5 | | 日本2 | 12 | | 拉脱维亚| 3 | + --------- + ------- + 3排套（0.01秒）
通过“db.odbc.discovery []”项的内部工作，此查询的结果将自动转换为以下JSON：
{
“data” ： [
{
“{#HOST}” ： “日本1” ，
“{#COUNT}” ： “5