3 自动发现（LLD）

概述

自动发现（LLD）提供了一种在计算机上为不同实体自动创建监控项，触发器和图形的方法。例如，Zabbix可以在你的机器上自动开始监控文件系统或网络接口，而无需为每个文件系统或网络接口手动创建监控项。此外，可以配置Zabbix根据定期执行发现后的得到实际结果，来移除不需要的监控。

用户可以自己定义发现类型，只要它们遵循特定的JSON协议。

发现过程的一般架构如下。

首先，用户在“配置”→“模板”→“发现”列中创建一个发现规则。发现规则包括（1）发现必要实体（例如，文件系统或网络接口）的项 和（2）应该根据该项的值创建的监控项，触发器和图形的原型

发现所需实体的项就像其他地方所看到的常规项一样：服务器（server）向Zabbix agent（或者对应该项的其他类型的设置）查询该项的值，agent以文本值进行响应。区别在于agent响应的值应该包含特定JSON格式的已发现实体的列表。虽然这个列表的详细信息仅对自定义发现检查来说很重要，但有必要知道返回的值包含宏 - >值对的列表。 例如，项目“net.if.discovery”可能会返回两对：“{#IFNAME}” - >“lo”和“{#IFNAME}” - >“eth0”。

这些宏用于名称，键值和其他原型字段中，然后用接收到的值为每个发现的实体创建实际的监控项，触发器，图形甚至主机。请参阅使用LLD宏选项的完整列表。 。

当服务器接收到已发现项的值时，它会查看宏→值对，每对都根据原型生成实际监控项，触发器和图形。在上面的“net.if.discovery”示例中，服务器将生成环路接口“lo”的一组监控项，触发器和图表，另一组用于界面“eth0”。

配置低级别发现（LLD）

我们来用文件系统发现为例子说明低级别发现（LLD）。

请执行以下操作，配置发现：

• 进入: 配置 → 模板

• 选择一个合适的模板的行点击发现

• 单击屏幕右上角的 创建发现规则

• 填写需要的详细信息

发现规则

发现规则 选项卡包含常规发现规则属性：

所有必填输入字段都标有红色星号。

发现规则过滤器

过滤器 选项卡包括发现规则过滤器定义:

for f in ext2 nfs reiserfs smbfs; do echo $f | grep -E ‘^ext|^reiserfs’ || echo “SKIP: $f”; done

如果要正确发现仅按大小写不同的文件系统名称，则必须将MySQL中的Zabbix数据库创建为区分大小写。

在正则表达式中的错误或错字，应用在LLD规则中时可能会导致删除删除数以千计的配置元素，历史值和许多主机的活动。例如，错误的“用于发现的文件系统”正则表达式可能会导致删除数以千计的监控项，触发器，历史值和活动。

不保留发现规则历史记录。

表格按钮

在表格底部的按钮会显示许多可用的操作。

	新增一个发现规则，此按钮仅可用于新的发现规则。
	更新发现规则的属性。 此按钮仅适用于现有发现规则。
	在现有的发现规则的属性基础上创建另一个发现规则。
	立即根据发现规则执行发现。 发现规则必须已存在。 查看 详情. 注意 当立即执行发现时，配置缓存不会更新，因此结果并不代表发现规则配置中最新的改变。
	删除发现规则。
	取消编辑发现规则属性。

监控项原型

一旦规则创建完成了，找到那条规则下的监控项，并点击“创建原型”来创建一个监控项原型。请注意在需要文件系统名称的情况下如何使用宏 {#FSNAME} 。 处理发现规则时，此宏将替换为发现的文件系统。

低级别发现 宏 and 用户 宏 可能会被用在监控项原型配置和监控项值预处理 参数.

执行特定于上下文的低级别发现宏的转义，以便在正则表达式和XPath预处理参数中安全使用。

Attributes that are specific for item prototypes: 特定于监控项原型的属性:

我们可以根据需求为每个文件系统指标创建许多监控项原型:

触发器原型

我们创建触发器原型的方式和创建监控项原型的方式相似：

特定于触发器原型的属性：

当真实的触发器从原型创建，可能需要灵活地确定在表达式中用于比较的常量（在我们的示例中为’20’）。了解 基于环境的用户宏 如何有助于实现这种灵活性。

您也可以定义触发器原型之间的（从Zabbix 3.0开始支持）。You can define 依赖关系（从Zabbix 3.0开始支持）。为此，转到 依赖关系 选项卡。 触发器原型可能依赖于来自相同低级别发现（LLD）规则的另一个触发器原型或常规触发器。触发器原型可能不依赖于来自不同LLD规则的触发器原型或依赖于触发器原型创建的触发器。主机触发器原型不能依赖于来自模板的触发器。

图表原型

我们也能创建图表原型:

最后，我们像下面的展示的一样创建一个发现规则。有五个监控项原型，两个触发器原型，和一个图表原型。

注意: 有关配置主机原型的信息，请参阅虚拟机监视中有关主机原型配置的部分。

发现的实体

下面的屏幕截图说明了主机配置中发现的项目，触发器和图形的外观。 发现的实体的前缀是橙色链接，指向它们来自的发现规则。

请注意，如果已存在具有相同唯一性条件的实体，则不会创建已发现的实体，例如，具有相同key或具有相同名称的图形的监控项。

如果一个发现的实体（文件系统，接口等）停止被发现（或是再也不通过过滤器），使用低级别发现规则创建的监控项（触发器和图表也相似）将会自动被删除。在这种情况下，在Keep lost resources period字段传递中定义的日期之后，将删除监控项，触发器和图表。

当发现实体转变成“不再发现”状态，生命周期指示符显示在监控项列表中。将鼠标指针移到它上面，将显示一条消息，表示在删除项目之前剩余的天数。

如果实体已标记为删除但未在预期时间删除（已禁用的发现规则或项目主机），则下次处理发现规则时将删除这些实体。

如果在发现规则级别更改，则包含标记为删除的其他实体的实体将不会更新。 例如，如果基于LLD的触发器包含标记为删除的监控项，则不会更新。

其他类型的发现

以下部分提供了有关其他类型的开箱即用发现的更多详细信息和方法：

• discovery of network interfaces;

• discovery of CPUs and CPU cores;

• discovery of SNMP OIDs;

• discovery of JMX objects;

• discovery using ODBC SQL queries;

• discovery of Windows services;

• discovery of host interfaces in Zabbix.

• 网络接口发现;

• CPUs 和 CPU 核心发现;

• SNMP OIDs发现;

• JMX 对象发现;

• 使用ODBC SQL 查询发现;

• Windows services发现;

• 在Zabbix中的主机接口发现

有关发现项的JSON格式的更多详细信息以及如何将自己的文件系统发现者实现为Perl脚本的示例，请参阅创建自定义LLD规则。

反馈值的数据限制

如果是直接来自Zabbix server，那对低级别发现规则JSON数据没有限制，因为反馈值是在没有存储在数据库中的情况下处理的。对于定制的低级别发现规则也没有限制，但是，如果 如果要使用用户参数获取自定义LLD数据，则应用用户参数反馈值会有限制（512 KB）。

如果数据必须通过Zabbix proxy，则必须将此数据存储在数据库中，以便应用数据库限制，例如，在运行IBM DB2数据库的Zabbix proxy上应用2048字节。

同一监控项的多个LLD规则

自从Zabbix agent 3.2版本开始，就可以使用相同的发现监控项定义许多低级别发现规则了。

为此，你需要定义Alias agent 参数, 在不同的发现规则中允许使用更改发现监控项密钥。例如， vfs.fs.discovery[foo], vfs.fs.discovery[bar]等。

创建自定义LLD规则

也可以创建一个完整的自定义LLD规则，同时发现任何类型的实体——例如，在database server上的数据库。

为此，应创建一个反馈JSON的自定义项，指定找到的对象并可选——他们的一些属性。 每个实体宏不受限制——虽然内置的发现规则反馈一个或两个宏（例如，两个用于文件系统发现），单反馈更多宏也是可能的。

这里有个例子可以最好地证明需要的JSON格式。假设我们正在运行一个接的Zabbix 1.8 agent（不支持“vfs.fs.discovery”），但我们仍旧需要发现文件系统。这有一个简单的Linux Perl脚本，可以发现挂载的文件系统，并输出JSON，其中包括文件系统的名称和类型。一种使用它的方式是使用键 “vfs.fs.discovery_perl”作为UserParameter：

#!/usr/bin/perl
$first = 1;
print "{\n";
print "\t\"data\":[\n\n";
for (`cat /proc/mounts`)
{
    ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
    print "\t,\n" if not $first;
    $first = 0;
    print "\t{\n";
    print "\t\t\"{#FSNAME}\":\"$fsname\",\n";
    print "\t\t\"{#FSTYPE}\":\"$fstype\"\n";
    print "\t}\n";
}
print "\n\t]\n";
print "}\n";

LLD宏名称的允许符号为 0-9 , A-Z , _ , .

名称中不支持小写字母。

其输出示例（为清晰起见重新格式化）如下所示。 自定义发现检查的JSON必须遵循相同的格式。

{
  "data":[
  { "{#FSNAME}":"/",                           "{#FSTYPE}":"rootfs"   },
  { "{#FSNAME}":"/sys",                        "{#FSTYPE}":"sysfs"    },
  { "{#FSNAME}":"/proc",                       "{#FSTYPE}":"proc"     },
  { "{#FSNAME}":"/dev",                        "{#FSTYPE}":"devtmpfs" },
  { "{#FSNAME}":"/dev/pts",                    "{#FSTYPE}":"devpts"   },
  { "{#FSNAME}":"/lib/init/rw",                "{#FSTYPE}":"tmpfs"    },
  { "{#FSNAME}":"/dev/shm",                    "{#FSTYPE}":"tmpfs"    },
  { "{#FSNAME}":"/home",                       "{#FSTYPE}":"ext3"     },
  { "{#FSNAME}":"/tmp",                        "{#FSTYPE}":"ext3"     },
  { "{#FSNAME}":"/usr",                        "{#FSTYPE}":"ext3"     },
  { "{#FSNAME}":"/var",                        "{#FSTYPE}":"ext3"     },
  { "{#FSNAME}":"/sys/fs/fuse/connections",    "{#FSTYPE}":"fusectl"  }
  ]
}

然后，在发现规则中的“过滤器”部分，我们可以指定“{#FSTYPE}“作为一个宏， “rootfs|ext3” 作为一个正则表达式。

你不必要使用自定义LLD规则的宏名称 FSNAME/FSTYPE ，你可以使用任何你喜欢的名称。

需要注意的是，如果使用一个用户参数，反馈值限制到512 KB。更多信息，请参考LLD反馈值的数据限制.

在用户宏环境中使用LLD宏

环境中的用户宏可用于在触发器表达式中实现更灵活的阈值。不同的阙值 可以在用户宏级别上定义不同的阈值，然后根据发现的环境将其用于触发器常量。当宏中使用的 低级别发现宏 被解析为实际值时，将显示已发现的环境。

为了证明我们可以使用上述的例子中的数据， 假设将发现以下文件系统： /, /home, /tmp, /usr, /var.

我们可以为主机定义一个自由磁盘空间触发器原型，其中阈值由具有发现环境的用户宏表示：

{host:vfs.fs.size[{#FSNAME},pfree].last()}<**{$LOW_SPACE_LIMIT:"{#FSNAME}"}**

然后新增用户宏:

• {$LOW_SPACE_LIMIT} 10

• {$LOW_SPACE_LIMIT:/home} 20

• {$LOW_SPACE_LIMIT:/tmp} 50

现在，一旦文件系统被发现了，如果/, /usr and /var文件系统有少于10%的自由磁盘空间，/home文件系统——少于20%的自由磁盘空间或/tmp文件系统——少于50%的自由磁盘空间，将生成事件。