Zabbix Documentation 3.4 (current)In development:4.4 (devel)Unsupported:

User Tools

Site Tools



This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
zh:manual:discovery:low_level_discovery [2017/04/04 10:01]
bluetom520 [3.5 ODBC SQL查询的发现]
zh:manual:discovery:low_level_discovery [2019/01/28 14:50] (current)
sasha <code js> => <code java>
Line 4: Line 4:
 === 概述 === === 概述 ===
-Low-level discovery provides a way to automatically create items, triggers, and graphs for different entities on a computer. For instance, Zabbix can automatically start monitoring file systems or network interfaces on your machine, without the need to create items for each file system or network interface manually. Additionally it is possible to configure Zabbix to remove unneeded entities automatically based on actual results of periodically performed discovery. 
 自动发现(LLD)提供了一种在计算机上为不同实体自动创建监控项,触发器和图形的方法。例如,Zabbix可以在你的机器上自动开始监控文件系统或网络接口,而无需为每个文件系统或网络接口手动创建监控项。此外,可以配置Zabbix根据定期执行发现后的得到实际结果,来移除不需要的监控项。 自动发现(LLD)提供了一种在计算机上为不同实体自动创建监控项,触发器和图形的方法。例如,Zabbix可以在你的机器上自动开始监控文件系统或网络接口,而无需为每个文件系统或网络接口手动创建监控项。此外,可以配置Zabbix根据定期执行发现后的得到实际结果,来移除不需要的监控项。
-In Zabbix, six types of discovery items are supported out of the box: 
 在Zabbix中,支持六种类型的发现项目: 在Zabbix中,支持六种类型的发现项目:
-  * discovery of file systems; 
   * 系统文件的发现;   * 系统文件的发现;
-  * discovery of network interfaces; 
   * 网络接口的发现;   * 网络接口的发现;
-  * discovery of CPUs and CPU cores; 
   * CPU和CPU内核的发现   * CPU和CPU内核的发现
-  * discovery of SNMP OIDs; 
   * SNMP OID的发现   * SNMP OID的发现
-  * discovery using ODBC SQL queries; 
   * 使用ODBC SQL查询的发现   * 使用ODBC SQL查询的发现
-  * discovery of Windows services. 
   * Windows服务的发现   * Windows服务的发现
-A user can define their own types of discovery, provided they follow a particular JSON protocol. 
 用户可以自己定义发现类型,只要它们遵循特定的JSON协议。 用户可以自己定义发现类型,只要它们遵循特定的JSON协议。
-The general architecture of the discovery process is as follows. 
 发现过程的一般架构如下。 发现过程的一般架构如下。
-First, a user creates a discovery rule in "​Configuration"​ -> "​Templates"​ -> "​Discovery"​ column. A discovery rule consists of (1) an item that discovers the necessary entities (for instance, file systems or network interfaces) and (2) prototypes of items, triggers, and graphs that should be created based on the value of that item. 
 首先,用户在“配置”→“模板”→“发现”列中创建一个发现规则。发现规则包括(1)发现必要实体(例如,文件系统或网络接口)的项目和(2)应该根据该项目的值创建的监控项,触发器和图形的原型 首先,用户在“配置”→“模板”→“发现”列中创建一个发现规则。发现规则包括(1)发现必要实体(例如,文件系统或网络接口)的项目和(2)应该根据该项目的值创建的监控项,触发器和图形的原型
-An item that discovers the necessary entities is like a regular item seen elsewhere: the server asks a Zabbix agent (or whatever the type of the item is set to) for a value of that item, the agent responds with a textual value. The difference is that the value the agent responds with should contain a list of discovered entities in a specific JSON format. While the details of this format are only important for implementers of custom discovery checks, it is necessary to know that the returned value contains a list of macro -> value pairs. For instance, item "​net.if.discovery"​ might return two pairs: "​{#​IFNAME}"​ -> "​lo"​ and "​{#​IFNAME}"​ -> "​eth0"​. 
 发现必要实体的项目就像其他地方所看到的常规项目:服务器向该项目的值询问Zabbix agent(或者该项目的任何类型的设置),agent以文本值进行响应。区别在于agent响应的值应该包含特定JSON格式的发现实体的列表。这种格式的自定义检查者发现的细节才是最重要的,因为返回值必须包含宏→值对。例如,项目“net.if.discovery”可能会返回两对键值:“{#​IFNAME}”→“lo”和“{#​IFNAME}”→“eth0”。 发现必要实体的项目就像其他地方所看到的常规项目:服务器向该项目的值询问Zabbix agent(或者该项目的任何类型的设置),agent以文本值进行响应。区别在于agent响应的值应该包含特定JSON格式的发现实体的列表。这种格式的自定义检查者发现的细节才是最重要的,因为返回值必须包含宏→值对。例如,项目“net.if.discovery”可能会返回两对键值:“{#​IFNAME}”→“lo”和“{#​IFNAME}”→“eth0”。
-<​note>​Low-level discovery items "​vfs.fs.discovery"​ and "​net.if.discovery"​ are supported since Zabbix agent version 2.0.\\ Discovery item "​system.cpu.discovery"​ is supported since Zabbix agent version 2.4.\\ Discovery of SNMP OIDs is supported since Zabbix server and proxy version 2.0.\\ Discovery using ODBC SQL queries is supported since Zabbix server and proxy version 3.0.</​note>​ 
 <​note>​Zabbix agent版本2.0支持自动发现项目“vfs.fs.discovery”和“net.if.discovery”。\\ 从Zabbix agent版本2.4起支持发现项目“system.cpu.discovery”。\\ 从Zabbix server和proxy版本2.0起支持发现SNMP OID。\\ 从Zabbix server和proxy版本3.0起支持使用ODBC SQL查询的发现。</​note>​ <​note>​Zabbix agent版本2.0支持自动发现项目“vfs.fs.discovery”和“net.if.discovery”。\\ 从Zabbix agent版本2.4起支持发现项目“system.cpu.discovery”。\\ 从Zabbix server和proxy版本2.0起支持发现SNMP OID。\\ 从Zabbix server和proxy版本3.0起支持使用ODBC SQL查询的发现。</​note>​
-<​note>​Return values of a low-level discovery rule are limited to 2048 bytes on a Zabbix proxy run with IBM DB2 database. This limit does not apply to Zabbix server as return values are processed without being stored in a database.</​note>​ 
 <​note>​在使用IBM DB2数据库运行的Zabbix proxy上,自动发现规则的返回值限制为2048字节。此限制不适用于Zabbix server,因为返回值不会被存储在数据库中。</​note>​ <​note>​在使用IBM DB2数据库运行的Zabbix proxy上,自动发现规则的返回值限制为2048字节。此限制不适用于Zabbix server,因为返回值不会被存储在数据库中。</​note>​
-These macros are used in names, keys and other prototype fields where they are then substituted with the received values for creating real items, triggers, graphs or even hosts for each discovered entity. See the full list of [[:​manual/​config/​macros/​lld_macros|options]] for using LLD macros. 
 这些宏用于名称,键值和其他原型字段中,然后用接收到的值为每个发现的实体创建实际的监控项,触发器,图形甚至主机。请参阅使用LLD宏的[[:​manual/​config/​macros/​lld_macros|选项]]的完整列表。 这些宏用于名称,键值和其他原型字段中,然后用接收到的值为每个发现的实体创建实际的监控项,触发器,图形甚至主机。请参阅使用LLD宏的[[:​manual/​config/​macros/​lld_macros|选项]]的完整列表。
-When the server receives a value for a discovery item, it looks at the macro -> value pairs and for each pair generates real items, triggers, and graphs, based on their prototypes. In the example with "​net.if.discovery"​ above, the server would generate one set of items, triggers, and graphs for the loopback interface "​lo",​ and another set for interface "​eth0"​. 
 当服务器接收到发现项目的值时,它会查看宏→值对,每对都根据原型生成实际监控项,触发器和图形。在上面的“net.if.discovery”示例中,服务器将生成环路接口“lo”的一组监控项,触发器和图表,另一组用于界面“eth0”。 当服务器接收到发现项目的值时,它会查看宏→值对,每对都根据原型生成实际监控项,触发器和图形。在上面的“net.if.discovery”示例中,服务器将生成环路接口“lo”的一组监控项,触发器和图表,另一组用于界面“eth0”。
-The following sections illustrate the process described above in detail and serve as a how-to for performing all types of discovery mentioned above. The last section describes the JSON format for discovery items and gives an example of how to implement your own file system discoverer as a Perl script. 
 以下部分将详细说明上述过程,并作为一个指导上述类型的所有发现。最后一节描述了发现项目的JSON格式,并给出了文件系统发现实现的Perl脚本的示例。 以下部分将详细说明上述过程,并作为一个指导上述类型的所有发现。最后一节描述了发现项目的JSON格式,并给出了文件系统发现实现的Perl脚本的示例。
 === - 文件系统的发现 === === - 文件系统的发现 ===
-To configure the discovery of file systems, do the following: 
 要配置文件系统的发现,请执行以下操作: 要配置文件系统的发现,请执行以下操作:
-  * Go to: //​Configuration//​ -> //​Templates// ​ 
   * 转到://​配置 → 模板//   * 转到://​配置 → 模板//
-  * Click on //​Discovery//​ in the row of an appropriate template 
   * 在一个合适的模板的行点击//​发现//​   * 在一个合适的模板的行点击//​发现//​
 {{manual:​discovery:​low_level_discovery:​fs_templates.png|}} {{manual:​discovery:​low_level_discovery:​fs_templates.png|}}
-  * Click on //Create discovery rule// in the upper right corner of the screen 
   * 单击屏幕右上角的//​创建发现规则//​   * 单击屏幕右上角的//​创建发现规则//​
-  * Fill in the form with the following details 
   * 填写以下详细信息。   * 填写以下详细信息。
-The **Discovery rule** tab contains general discovery rule attributes: ​ 
 **发现规则**选项卡包含常规发现规则属性: **发现规则**选项卡包含常规发现规则属性:
Line 87: Line 58:
 ^参数^描述^ ^参数^描述^
 |//​名称// ​ |发现规则名称。 | |//​名称// ​ |发现规则名称。 |
-|//​类型// ​ |The type of check to perform discovery; should be //Zabbix agent// or //Zabbix agent (active)// for file system discovery. ​ | 
 |//​类型// ​ |执行发现的检查类型;​ 可以是 //Zabbix agent//​或//​Zabbix agent(主动)//​文件系统发现。 | |//​类型// ​ |执行发现的检查类型;​ 可以是 //Zabbix agent//​或//​Zabbix agent(主动)//​文件系统发现。 |
-|//​键值// ​ |An item with "​vfs.fs.discovery"​ key is built into the Zabbix agent on many platforms (see [[manual:​appendix:​items:​supported_by_platform|supported item key list]] for details), and will return a JSON with the list of file systems present on the computer and their types. ​ | 
 |//​键值// ​ |许多平台上的Zabbix agent程序内置了“vfs.fs.discovery”键值的项目(有关详细信息,请参阅 [[manual:​appendix:​items:​supported_by_platform|支持的项目键列表]]),并将返回一个JSON,其中包含计算机上存在的文件系统列表及其类型。 | |//​键值// ​ |许多平台上的Zabbix agent程序内置了“vfs.fs.discovery”键值的项目(有关详细信息,请参阅 [[manual:​appendix:​items:​supported_by_platform|支持的项目键列表]]),并将返回一个JSON,其中包含计算机上存在的文件系统列表及其类型。 |
-|//Update interval (in sec)// ​ |This field specifies how often Zabbix performs discovery. In the beginning, when you are just setting up file system discovery, you might wish to set it to a small interval, but once you know it works you can set it to 30 minutes or more, because file systems usually do not change very often.\\ //Note//: If set to '​0',​ the item will not be polled. However, if a flexible interval also exists with a non-zero value, the item will be polled during the flexible interval duration. ​ | 
 |//​数据更新间隔(秒)// ​ |此字段设置Zabbix执行发现的频率。一开始,当你只是设置文件系统发现时,您可能希望将其设置为段间隔时间,但一旦发现它可以将其设置为30分钟或更长时间,因为文件系统通常不会更改。\\ //​注意//​:如果设置为“0”,则不会轮询该项。但是,如果灵活间隔也存在非零值,则在灵活间隔持续时间内将轮询该项。| |//​数据更新间隔(秒)// ​ |此字段设置Zabbix执行发现的频率。一开始,当你只是设置文件系统发现时,您可能希望将其设置为段间隔时间,但一旦发现它可以将其设置为30分钟或更长时间,因为文件系统通常不会更改。\\ //​注意//​:如果设置为“0”,则不会轮询该项。但是,如果灵活间隔也存在非零值,则在灵活间隔持续时间内将轮询该项。|
-|//Custom intervals// ​ |You can create custom rules for checking the item:\\ **Flexible** - create an exception to the //Update interval// (interval with different frequency)\\ **Scheduling** - create a custom polling schedule.\\ For detailed information see [[manual:​config:​items:​item:​custom_intervals|Custom intervals]]. Scheduling is supported since Zabix 3.0.0. ​ | 
 |//​自定义时间间隔// ​ |您可以创建用于检查项目的自定义规则:\\ **灵活** - 创建更新//​间隔//​(不同频次的间隔)的\\ **调度** - 创建自定义轮询调度。\\ 有关详细信息,请参阅[[manual:​config:​items:​item:​custom_intervals|自定义时间间隔]]。从Zabix 3.0.0起支持调度 | |//​自定义时间间隔// ​ |您可以创建用于检查项目的自定义规则:\\ **灵活** - 创建更新//​间隔//​(不同频次的间隔)的\\ **调度** - 创建自定义轮询调度。\\ 有关详细信息,请参阅[[manual:​config:​items:​item:​custom_intervals|自定义时间间隔]]。从Zabix 3.0.0起支持调度 |
-|//Keep lost resources period (in days)// ​ |This field allows you to specify for how many days the discovered entity will be retained (won't be deleted) once its discovery status becomes "Not discovered anymore"​ (max 3650 days). \\ //Note:// If set to "​0",​ entities will be deleted immediately. Using "​0"​ is not recommended,​ since just wrongly editing the filter may end up in the entity being deleted with all the historical data.   | 
 |//​保留失去的资源期间(天)// ​ |该字段允许你设置发现的实体将被发现状态变为“不再支持”(最多3650天)后将被保留(不会被删除)的天数。\\ //​注意//​:如果设置为“0”,将立即删除实体。不建议使用“0”,因为错误地编辑过滤器可能会在实体中删除所有的历史数据。 | |//​保留失去的资源期间(天)// ​ |该字段允许你设置发现的实体将被发现状态变为“不再支持”(最多3650天)后将被保留(不会被删除)的天数。\\ //​注意//​:如果设置为“0”,将立即删除实体。不建议使用“0”,因为错误地编辑过滤器可能会在实体中删除所有的历史数据。 |
 |//​描述// ​ |输入说明文字。 | |//​描述// ​ |输入说明文字。 |
 |//​已启用// ​ |如果选中,该规则将被执行。 ​ | |//​已启用// ​ |如果选中,该规则将被执行。 ​ |
-The **Filters** tab contains discovery rule filter definitions: ​ 
 **过滤器**选项卡包含发现规则过滤器定义: **过滤器**选项卡包含发现规则过滤器定义:
Line 107: Line 72:
 ^参数^描述^ ^参数^描述^
-|//Type of calculation// ​ |The following options for calculating filters are available:​\\ **And** - all filters must be passed;\\ **Or** - enough if one filter is passed;\\ **And/Or** - uses //And// with different macro names and //Or// with the same macro name;\\ **Custom expression** - offers the possibility to define a custom calculation of filters. The formula must include all filters in the list. Limited to 255 symbols. ​ |+
 |//​计算方式// ​ |计算过滤器的可用选项如下:\\ **与** -所有过滤器满足;​ \\ **或** - 只需一个过滤器满足;​ \\ **与/或** - 不同的宏名称用//​与//​,相同的宏名称用//​或//;​ \\ **自定义表达式** - 提供定义自定义计算的过滤器的。该公式必须包括列表中的所有过滤器。限于255个符号 | |//​计算方式// ​ |计算过滤器的可用选项如下:\\ **与** -所有过滤器满足;​ \\ **或** - 只需一个过滤器满足;​ \\ **与/或** - 不同的宏名称用//​与//​,相同的宏名称用//​或//;​ \\ **自定义表达式** - 提供定义自定义计算的过滤器的。该公式必须包括列表中的所有过滤器。限于255个符号 |
-|//​Filters// ​ |A filter can be used to generate real items, triggers, and graphs only for certain file systems. It expects a [[manual:​regular_expressions|POSIX Extended Regular Expression]]. For instance, if you are only interested in C:, D:, and E: file systems, you could put {#FSNAME} into "​Macro"​ and <​nowiki>"​^C|^D|^E"</​nowiki>​ regular expression into "​Regular expression"​ text fields. Filtering is also possible by file system types using {#FSTYPE} macro (e.g. <​nowiki>"​^ext|^reiserfs"</​nowiki>​) and by drive types (supported only by Windows agent) using {#​FSDRIVETYPE} macro (e.g., <​nowiki>"​fixed"</​nowiki>​).\\ You can enter a regular expression or reference a global [[manual:​regular_expressions|regular expression]] in "​Regular expression"​ field.\\ In order to test a regular expression you can use "grep -E", for example: <code bash>for f in ext2 nfs reiserfs smbfs; do echo $f | grep -E '​^ext|^reiserfs'​ || echo "SKIP: $f"; done</​code>​{#​FSDRIVETYPE} macro on Windows is supported since Zabbix **3.0.0**.\\ Defining several filters is supported since Zabbix **2.4.0**.\\ Note that if some macro from the filter is missing in the response, the found entity will be ignored. ​ | 
 |//​过滤器// ​ |过滤器可用于仅为特定文件系统生成实际监控项,触发器和图形。它支持[[manual:​regular_expressions|POSIX扩展正则表达式]]。例如,如果你只对C :, D :,​和E:文件系统感兴趣,则可以将{#​FSNAME}放入“宏”和<​nowiki>"​^C|^D|^E"</​nowiki>​正则表达式到“正则表达式”文本字段。也可以使用{#​FSTYPE}宏(例如<​nowiki>"​^ext|^reiserfs"</​nowiki>​)的文件系统类型以及使用{#​FSDRIVETYPE}宏(例如<​nowiki>"​fixed"</​nowiki>​)的驱动器类型(仅由Windows agent支持)进行过滤。\\ 你可以在“正则表达式”字段中输入正则表达式或引用全局 [[manual:​regular_expressions|正则表达式]]。\\ 为了测试正则表达式,你可以使用“grep -E”,例如:<​code bash>for f in ext2 nfs reiserfs smbfs; do echo $f | grep -E '​^ext|^reiserfs'​ || echo "SKIP: $f"; done</​code>​从Zabbix **3.0.0**起支持Windows上的宏{#​FSDRIVETYPE}。\\ Zabbix **2.4.0**起支持定义多个过滤器。\\ 注意,如果响应中缺少过滤器中的某些宏,则找到的实体将被忽略。. ​ | |//​过滤器// ​ |过滤器可用于仅为特定文件系统生成实际监控项,触发器和图形。它支持[[manual:​regular_expressions|POSIX扩展正则表达式]]。例如,如果你只对C :, D :,​和E:文件系统感兴趣,则可以将{#​FSNAME}放入“宏”和<​nowiki>"​^C|^D|^E"</​nowiki>​正则表达式到“正则表达式”文本字段。也可以使用{#​FSTYPE}宏(例如<​nowiki>"​^ext|^reiserfs"</​nowiki>​)的文件系统类型以及使用{#​FSDRIVETYPE}宏(例如<​nowiki>"​fixed"</​nowiki>​)的驱动器类型(仅由Windows agent支持)进行过滤。\\ 你可以在“正则表达式”字段中输入正则表达式或引用全局 [[manual:​regular_expressions|正则表达式]]。\\ 为了测试正则表达式,你可以使用“grep -E”,例如:<​code bash>for f in ext2 nfs reiserfs smbfs; do echo $f | grep -E '​^ext|^reiserfs'​ || echo "SKIP: $f"; done</​code>​从Zabbix **3.0.0**起支持Windows上的宏{#​FSDRIVETYPE}。\\ Zabbix **2.4.0**起支持定义多个过滤器。\\ 注意,如果响应中缺少过滤器中的某些宏,则找到的实体将被忽略。. ​ |
-<note important>​Zabbix database in MySQL must be created as case-sensitive if file system names that differ only by case are to be discovered correctly.</​note>​ 
 <note important>​如果要正确发现不同的文件系统名称,则必须将MySQL中的Zabbix数据库创建为区分大小写。</​note>​ <note important>​如果要正确发现不同的文件系统名称,则必须将MySQL中的Zabbix数据库创建为区分大小写。</​note>​
-<​note>​Discovery rule history is not preserved.</​note>​ 
 <​note>​发现规则历史记录不被保留。</​note>​ <​note>​发现规则历史记录不被保留。</​note>​
-Once a rule is created, go to the items for that rule and press "​Create prototype"​ to create an item prototype. Note how macro {#FSNAME} is used where a file system name is required. When the discovery rule is processed, this macro will be substituted with the discovered file system. 
 创建规则后,转到该规则的项目,然后点击“创建监控项原型”创建项目原型。请注意在需要文件系统名称时使用宏{#​FSNAME}的宏。当发现规则被处理时,该宏将被替换为发现的文件系统。 创建规则后,转到该规则的项目,然后点击“创建监控项原型”创建项目原型。请注意在需要文件系统名称时使用宏{#​FSNAME}的宏。当发现规则被处理时,该宏将被替换为发现的文件系统。
Line 126: Line 87:
 {{manual:​discovery:​low_level_discovery:​item_prototype_fs.png|}} {{manual:​discovery:​low_level_discovery:​item_prototype_fs.png|}}
-Attributes that are specific for item prototypes:+
 监控项原型特有的属性: 监控项原型特有的属性:
 ^参数^描述^ ^参数^描述^
-|//New application prototype// ​ |You may define a new application prototype.\\ In application prototypes you can use low-level discovery macros that, after discovery, will be substituted with real values to create applications that are specific for the discovered entity. See also [[manual:​discovery:​low_level_discovery:​notes|application discovery notes]] for more specific information. ​ |+
 |//​新应用原型// ​ |您可以定义一个新的应用原型。\\ 在应用原型中,你可以使用自动发现(LLD)宏,在发现后,将用实际值替换创建特定于发现实体的应用。有关更多具体信息,请参阅[[manual:​discovery:​low_level_discovery:​notes|应用发现说明]]。 | |//​新应用原型// ​ |您可以定义一个新的应用原型。\\ 在应用原型中,你可以使用自动发现(LLD)宏,在发现后,将用实际值替换创建特定于发现实体的应用。有关更多具体信息,请参阅[[manual:​discovery:​low_level_discovery:​notes|应用发现说明]]。 |
-|//​Application prototypes// ​ |Select from the existing application prototypes. ​ | +|//​应用原型// ​ |从现有应用原型中选择。 | |
-|//​应用原型// ​ |从现有应用原型中选择。 | +
-|//Create enabled// ​ |If checked the item will be added in an enabled state.\\ If unchecked, the item will be added to a discovered entity, but in a disabled state.  ​|+
 |//​创建已启用// ​ |如果选中,项目将被添加到启用状态。\\ 如果未选中,该项目将被添加到已发现的实体,但处于禁用状态。 | |//​创建已启用// ​ |如果选中,项目将被添加到启用状态。\\ 如果未选中,该项目将被添加到已发现的实体,但处于禁用状态。 |
-We can create several item prototypes for each file system metric we are interested in: 
 我们可以为我们感兴趣的每个文件系统度量创建几个项目原型: 我们可以为我们感兴趣的每个文件系统度量创建几个项目原型:
 {{manual:​discovery:​low_level_discovery:​item_prototypes_fs.png|}} {{manual:​discovery:​low_level_discovery:​item_prototypes_fs.png|}}
-Then, we create trigger prototypes in a similar way: 
 然后,我们以类似的方式创建触发器原型: 然后,我们以类似的方式创建触发器原型:
Line 149: Line 105:
 {{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png|}} {{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png|}}
-Attributes that are specific for trigger prototypes: 
 触发原型特有的属性: 触发原型特有的属性:
 ^参数^描述^ ^参数^描述^
-|//​创建启用// ​ |If checked the trigger will be added in an enabled state.\\ If unchecked, the trigger will be added to a discovered entity, but in a disabled state. ​ | 
-|//​创建启用// ​ | 如果选中,触发器将被添加到启用状态。\\ 如果未选中,触发器将被添加到已发现的实体,但处于禁用状态。 | 
-When real triggers are created from the prototypes, there may be a need to be flexible as to what constant ('​20'​ in our example) is used for comparison in the expression. See how [[:manual/discovery/low_level_discovery#​using_lld_macros_in_user_macro_contexts|user macros with context]] can be useful to accomplish such flexibility.+|//创建启用// ​ | 如果选中,触发器将被添加到启用状态。\\ 如果未选中,触发器将被添加到已发现的实体,但处于禁用状态。 ​|
 当从原型创建真实触发器时,对表达式中使用什么常量(在我们的示例中为'​20'​)是比较灵活的。了解[[:​manual/​discovery/​low_level_discovery#​using_lld_macros_in_user_macro_contexts|具有上下文的用户宏]]可以实现这种灵活性。 当从原型创建真实触发器时,对表达式中使用什么常量(在我们的示例中为'​20'​)是比较灵活的。了解[[:​manual/​discovery/​low_level_discovery#​using_lld_macros_in_user_macro_contexts|具有上下文的用户宏]]可以实现这种灵活性。
-You can define [[:​manual/​config/​triggers/​dependencies|dependencies]] between trigger prototypes as well (supported since Zabbix 3.0). To do that, go to the //​Dependencies//​ tab. A trigger prototype may depend on another trigger prototype from the same low-level discovery (LLD) rule or on a regular trigger. A trigger prototype may not depend on a trigger prototype from a different LLD rule or on a trigger created from trigger prototype. Host trigger prototype cannot depend on a trigger from a template. 
 在//​依赖关系//​选项卡,也可以定义触发器原型之间的[[:​manual/​config/​triggers/​dependencies|依赖关系]](自Zabbix 3.0起支持)。触发器原型可以依赖于来自相同自动发现(LLD)规则另一个触发器原型或常规触发器。触发原型也可不依赖于不同的LLD规则触发原型或常规触发器的产生的触发器原型。。主机触发器原型不能依赖于模板的触发器。 在//​依赖关系//​选项卡,也可以定义触发器原型之间的[[:​manual/​config/​triggers/​dependencies|依赖关系]](自Zabbix 3.0起支持)。触发器原型可以依赖于来自相同自动发现(LLD)规则另一个触发器原型或常规触发器。触发原型也可不依赖于不同的LLD规则触发原型或常规触发器的产生的触发器原型。。主机触发器原型不能依赖于模板的触发器。
Line 167: Line 118:
 {{manual:​discovery:​low_level_discovery:​trigger_prototypes_fs.png|}} {{manual:​discovery:​low_level_discovery:​trigger_prototypes_fs.png|}}
-We can create graph prototypes, too: 
 我们也可以创建图形原型: 我们也可以创建图形原型:
Line 174: Line 124:
 {{manual:​discovery:​low_level_discovery:​graph_prototypes_fs.png|}} {{manual:​discovery:​low_level_discovery:​graph_prototypes_fs.png|}}
-Finally, we have created a discovery rule that looks like shown below. It has five item prototypes, two trigger prototypes, and one graph prototype. 
 最后,我们创建了一个发现规则,如下图所示。它有五个监控项目原型,两个触发器原型和一个图形原型。 最后,我们创建了一个发现规则,如下图所示。它有五个监控项目原型,两个触发器原型和一个图形原型。
 {{manual:​discovery:​low_level_discovery:​lld_rules_fs.png|}} {{manual:​discovery:​low_level_discovery:​lld_rules_fs.png|}}
-//Note//: For configuring host prototypes, see the section about [[:​manual/​vm_monitoring#​host_prototypes|host prototype]] configuration in virtual machine monitoring. 
 //注意//: 有关配置主机模板,请参阅虚拟机监控中有关[[:​manual/​vm_monitoring#​host_prototypes|主机模板]]配置的部分。 //注意//: 有关配置主机模板,请参阅虚拟机监控中有关[[:​manual/​vm_monitoring#​host_prototypes|主机模板]]配置的部分。
-The screenshots below illustrate how discovered items, triggers, and graphs look like in the host's configuration. Discovered entities are prefixed with an orange link to a discovery rule they come from. 
 下面的屏幕截图说明了主机配置中发现的监控项,触发器和图形的样子。发现的实体前缀有橙色链接到他们来自的发现规则。 下面的屏幕截图说明了主机配置中发现的监控项,触发器和图形的样子。发现的实体前缀有橙色链接到他们来自的发现规则。
Line 191: Line 136:
 {{manual:​discovery:​low_level_discovery:​discovered_items.png|}} {{manual:​discovery:​low_level_discovery:​discovered_items.png|}}
-Note that discovered entities will not be created in case there are already existing entities with the same uniqueness criteria, for example, an item with the same key or graph with the same name. 
 请注意,如果已经存在具有相同唯一性条件的现有实体,例如具有相同键值或具有相同名称的图形的项目,则不会创建发现的实体。 请注意,如果已经存在具有相同唯一性条件的现有实体,例如具有相同键值或具有相同名称的图形的项目,则不会创建发现的实体。
-Items (similarly, triggers and graphs) created by a low-level discovery rule will be deleted automatically if a discovered entity (file system, interface, etc) stops being discovered (or does not pass the filter anymore). In this case the items, triggers and graphs will be deleted after the days defined in the //Keep lost resources period// field pass. 
 如果发现的实体(文件系统,接口等)停止发现(或不再通过过滤器),则由自动发现规则(LLD)创建的项目(类似地,触发器和图形)将被自动删除。这时,监控项,触发器和图表将在//​保留失去的资源期间//​字段中定义的日期过去后被删除。 如果发现的实体(文件系统,接口等)停止发现(或不再通过过滤器),则由自动发现规则(LLD)创建的项目(类似地,触发器和图形)将被自动删除。这时,监控项,触发器和图表将在//​保留失去的资源期间//​字段中定义的日期过去后被删除。
-When discovered entities become 'Not discovered anymore',​ a lifetime indicator is displayed in the item list. Move your mouse pointer over it and a message will be displayed indicating how many days are left until the item is deleted. 
 当发现的实体变为“不再支持”时,项目列表中将显示生命周期指示符。将鼠标指针移动到其上,并显示一条消息,指示在删除项目之前剩下多少天。。 当发现的实体变为“不再支持”时,项目列表中将显示生命周期指示符。将鼠标指针移动到其上,并显示一条消息,指示在删除项目之前剩下多少天。。
 {{:​manual:​discovery:​low_level_discovery:​not_discovered_message.png|}} {{:​manual:​discovery:​low_level_discovery:​not_discovered_message.png|}}
-If entities were marked for deletion, but were not deleted at the expected time (disabled discovery rule or item host), they will be deleted the next time the discovery rule is processed. 
 如果实体被标记为删除,但未在预期时间被删除(禁用的发现规则或项目主机),则在下次发现规则被处理时,它们将被删除。 如果实体被标记为删除,但未在预期时间被删除(禁用的发现规则或项目主机),则在下次发现规则被处理时,它们将被删除。
-Entities containing other entities, which are marked for deletion, will not update if changed on the discovery rule level. For example, LLD-based triggers will not update if they contain items that are marked for deletion. 
 标记为删除的其他实体的实体,如果在发现规则级别上更改,则不会更新。例如,如果基于LLD的触发器标记为要删除的项目,则它们将不会更新。 标记为删除的其他实体的实体,如果在发现规则级别上更改,则不会更新。例如,如果基于LLD的触发器标记为要删除的项目,则它们将不会更新。
Line 219: Line 158:
 === - 网络接口的发现 === === - 网络接口的发现 ===
-Discovery of network interfaces is done in exactly the same way as discovery of file systems, except that you use the discovery rule key "​net.if.discovery"​ instead of "​vfs.fs.discovery"​ and use macro {#IFNAME} instead of {#FSNAME} in filter and item/​trigger/​graph prototypes. 
 网络接口的发现与文件系统的发现完全相同,只是你使用发现规则的键值是“net.if.discovery”而不是“vfs.fs.discovery”,并使用宏{#​IFNAME}而不是{#​FSNAME}。 网络接口的发现与文件系统的发现完全相同,只是你使用发现规则的键值是“net.if.discovery”而不是“vfs.fs.discovery”,并使用宏{#​IFNAME}而不是{#​FSNAME}。
-Examples of item prototypes that you might wish to create based on "​net.if.discovery":​ "​[{#​IFNAME},​bytes]",​ "​net.if.out[{#​IFNAME},​bytes]"​. 
 你可能希望基于“net.if.discovery”创建的监控项原型示例:“[{#​IFNAME},​bytes]”,“net.if.out[{#​IFNAME},​bytes]“。 你可能希望基于“net.if.discovery”创建的监控项原型示例:“[{#​IFNAME},​bytes]”,“net.if.out[{#​IFNAME},​bytes]“。
-[[#​discovery_of_file_systems|See above]] for more information about the filter. 
 有关过滤器的更多信息,请参阅[[#​discovery_of_file_systems|上文]]。 有关过滤器的更多信息,请参阅[[#​discovery_of_file_systems|上文]]。
Line 233: Line 168:
 === - CPU和CPU内核的发现 === === - CPU和CPU内核的发现 ===
-Discovery of CPUs and CPU cores is done in a similar fashion as network interface discovery with the exception being that the discovery rule key is "​system.cpu.discovery"​. This discovery key returns two macros - {#​CPU.NUMBER} and {#​CPU.STATUS} identifying the CPU order number and status respectively. To note, a clear distinction cannot be made between actual, physical processors, cores and hyperthreads. {#​CPU.STATUS} on Linux, UNIX and BSD systems returns the status of the processor, which can be either "​online"​ or "​offline"​. On Windows systems, this same macro may represent a third value - "​unknown"​ - which indicates that a processor has been detected, but no information has been collected for it yet. 
 CPU和CPU内核的发现以与网络接口发现类似的方式完成相同,除了发现规则的键值是“system.cpu.discovery”之外。此发现键返回两个宏 - {#CPU.NUMBER}和{#CPU.STATUS}分别标识CPU序号和状态。要注意,实际物理处理器,内核和超线程之间不能做出明确的区分。在Linux,UNIX和BSD系统上的{#CPU.STATUS}返回处理器的状态,可以是“online”还是“offline”。在Windows系统上,同一个宏可能表示第三个值 - “unknown” - 这表示处理器已被检测到,但尚未收集到任何信息 CPU和CPU内核的发现以与网络接口发现类似的方式完成相同,除了发现规则的键值是“system.cpu.discovery”之外。此发现键返回两个宏 - {#CPU.NUMBER}和{#CPU.STATUS}分别标识CPU序号和状态。要注意,实际物理处理器,内核和超线程之间不能做出明确的区分。在Linux,UNIX和BSD系统上的{#CPU.STATUS}返回处理器的状态,可以是“online”还是“offline”。在Windows系统上,同一个宏可能表示第三个值 - “unknown” - 这表示处理器已被检测到,但尚未收集到任何信息
-CPU discovery relies on the agent'​s collector process to remain consistent with the data provided by the collector and save resources on obtaining the data. This has the effect of this item key not working with the test (-t) command line flag of the agent binary, which will return a NOT_SUPPORTED status and an accompanying message indicating that the collector process has not been started. 
 CPU发现依赖于agent的收集器进程去收集和获取数据。如果agent的测试(-t)命令行不起作用,这将返回一个NOT_SUPPORTED状态以及附带的消息,表明收集器进程尚未启动。 CPU发现依赖于agent的收集器进程去收集和获取数据。如果agent的测试(-t)命令行不起作用,这将返回一个NOT_SUPPORTED状态以及附带的消息,表明收集器进程尚未启动。
-Item prototypes that can be created based on CPU discovery include, for example, "​system.cpu.util[{#​CPU.NUMBER},​ <​type>,​ <​mode>​]"​ or "​system.hw.cpu[{#​CPU.NUMBER},​ <​info>​]"​. 
 可以基于CPU发现规则创建的监控项原型包括例如: "​system.cpu.util[{#​CPU.NUMBER},​ <​type>,​ <​mode>​]"​ 或 "​system.hw.cpu[{#​CPU.NUMBER},​ <​info>​]"​。 可以基于CPU发现规则创建的监控项原型包括例如: "​system.cpu.util[{#​CPU.NUMBER},​ <​type>,​ <​mode>​]"​ 或 "​system.hw.cpu[{#​CPU.NUMBER},​ <​info>​]"​。
 === - SNMP OID的发现 === === - SNMP OID的发现 ===
-In this example, we will perform SNMP discovery on a switch. First, go to "​Configuration"​ -> "​Templates"​. 
 例如,我们将在交换机上执行SNMP发现。首先,进入“配置”→“模板”。 例如,我们将在交换机上执行SNMP发现。首先,进入“配置”→“模板”。
 {{manual:​discovery:​low_level_discovery:​templates_snmp.png|}} {{manual:​discovery:​low_level_discovery:​templates_snmp.png|}}
-To edit discovery rules for a template, click on the link in the "​Discovery"​ column. 
 要编辑模板的发现规则,请单击“自动发现”列中的链接。 要编辑模板的发现规则,请单击“自动发现”列中的链接。
-Then, press "​Create rule" and fill the form with the details in the screenshot below. 
 然后,按“创建发现规则”,并在下面的屏幕截图中填写表单与详细信息。 然后,按“创建发现规则”,并在下面的屏幕截图中填写表单与详细信息。
-Unlike file system and network interface discovery, the item does not necessarily have to have "​snmp.discovery"​ key - item type of SNMP agent is sufficient. 
 与文件系统和网络接口发现不同,项目不一定必须具有“snmp.discovery”键值 - SNMP agent的项目类型就足够了。 与文件系统和网络接口发现不同,项目不一定必须具有“snmp.discovery”键值 - SNMP agent的项目类型就足够了。
-The OIDs to discover are defined in SNMP OID field in the following format: ''​discovery[{#​MACRO1},​ oid1, {#MACRO2}, oid2, …,​]''​ 
 要发现的OID在SNMP OID字段中以下列格式定义: ''​discovery[{#​MACRO1},​ oid1, {#MACRO2}, oid2, …,​]''​ 要发现的OID在SNMP OID字段中以下列格式定义: ''​discovery[{#​MACRO1},​ oid1, {#MACRO2}, oid2, …,​]''​
-where //​{#​MACRO1}//,​ //​{#​MACRO2}//​ …  are valid lld macro names and //oid1//, //oid2//... are OIDs capable of generating meaningful values for these macros. A built-in macro //​{#​SNMPINDEX}//​ containing index of the discovered OID is applied to discovered entities. The discovered entities are grouped by //​{#​SNMPINDEX}//​ macro value. 
 其中//​{#​MACRO1}//,​ //​{#​MACRO2}//​ ...是有效的lld宏名称和//​oid1//,​ //oid2//... 是能够为这些宏生成有意义的值的OID。已发现OID索引的内置宏{#​SNMPINDEX}将应用于发现的实体。发现的实体按{#​SNMPINDEX}宏值分组。 其中//​{#​MACRO1}//,​ //​{#​MACRO2}//​ ...是有效的lld宏名称和//​oid1//,​ //oid2//... 是能够为这些宏生成有意义的值的OID。已发现OID索引的内置宏{#​SNMPINDEX}将应用于发现的实体。发现的实体按{#​SNMPINDEX}宏值分组。
-To understand what we mean, let us perform few snmpwalks on our switch: ​ 
 为了理解清楚,在我们的交换机上执行几个snmpwalk: 为了理解清楚,在我们的交换机上执行几个snmpwalk:
Line 286: Line 204:
   IF-MIB::​ifPhysAddress.3 = STRING: 8:​0:​27:​2b:​af:​9e   IF-MIB::​ifPhysAddress.3 = STRING: 8:​0:​27:​2b:​af:​9e
-And set SNMP OID to: ''​discovery[{#​IFDESCR},​ ifDescr, {#​IFPHYSADDRESS},​ ifPhysAddress]''​ 
 并将SNMP OID设置为: ''​discovery[{#​IFDESCR},​ ifDescr, {#​IFPHYSADDRESS},​ ifPhysAddress]''​ 并将SNMP OID设置为: ''​discovery[{#​IFDESCR},​ ifDescr, {#​IFPHYSADDRESS},​ ifPhysAddress]''​
-Now this rule will discover entities with {#IFDESCR} macros set to **WAN**, **LAN1** and **LAN2**, {#​IFPHYSADDRESS} macros set to **8:​0:​27:​90:​7a:​75**,​ **8:​0:​27:​90:​7a:​76**,​ and **8:​0:​27:​2b:​af:​9e**,​ {#​SNMPINDEX} macros set to the discovered OIDs indexes **1**, **2** and **3**: 
 现在,这个规则会发现设置为{#​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: 现在,这个规则会发现设置为{#​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:
Line 313: Line 228:
   }   }
-If an entity does not have the specified OID, then the corresponding macro will be omitted for this entity. For example if we have the following data: 
 如果一个实体没有指定的OID,则该实体将忽略相应的宏。例如,如果我们有以下数据: 如果一个实体没有指定的OID,则该实体将忽略相应的宏。例如,如果我们有以下数据:
Line 324: Line 238:
   ifAlias.3 "​eth2"​   ifAlias.3 "​eth2"​
   ifAlias.5 "​eth4"​   ifAlias.5 "​eth4"​
-Then in this case SNMP discovery ''​discovery[{#​IFDESCR},​ ifDescr, {#IFALIAS}, ifAlias]''​ will return the following structure: ​ 
 那么在这种情况下,SNMP发现''​discovery[{#​IFDESCR},​ ifDescr, {#IFALIAS}, ifAlias]''​ 将返回以下结构: 那么在这种情况下,SNMP发现''​discovery[{#​IFDESCR},​ ifDescr, {#IFALIAS}, ifAlias]''​ 将返回以下结构:
Line 356: Line 268:
 {{manual:​discovery:​low_level_discovery:​lld_rule_snmp.png|}} {{manual:​discovery:​low_level_discovery:​lld_rule_snmp.png|}}
-The following screenshot illustrates how we can use these macros in item prototypes: 
 以下屏幕截图显示了我们如何在监控项原型中使用这些宏: 以下屏幕截图显示了我们如何在监控项原型中使用这些宏:
 {{manual:​discovery:​low_level_discovery:​item_prototype_snmp.png|}} {{manual:​discovery:​low_level_discovery:​item_prototype_snmp.png|}}
-Again, creating as many item prototypes as needed: 
 再次,根据需要创建尽可能多的监控项原型: 再次,根据需要创建尽可能多的监控项原型:
 {{manual:​discovery:​low_level_discovery:​item_prototypes_snmp.png|}} {{manual:​discovery:​low_level_discovery:​item_prototypes_snmp.png|}}
-As well as trigger prototypes: 
 以及触发原型: 以及触发原型:
Line 377: Line 282:
 {{manual:​discovery:​low_level_discovery:​trigger_prototypes_snmp.png|}} {{manual:​discovery:​low_level_discovery:​trigger_prototypes_snmp.png|}}
-And graph prototypes: 
 和图形原型: 和图形原型:
Line 385: Line 289:
 {{manual:​discovery:​low_level_discovery:​graph_prototypes_snmp.png|}} {{manual:​discovery:​low_level_discovery:​graph_prototypes_snmp.png|}}
-A summary of our discovery rule: 
 我们的发现规则摘要: 我们的发现规则摘要:
 {{manual:​discovery:​low_level_discovery:​lld_rules_snmp.png|}} {{manual:​discovery:​low_level_discovery:​lld_rules_snmp.png|}}
-When server runs, it will create real items, triggers and graphs based on the values the SNMP discovery rule returns. In the host configuration they are prefixed with an orange link to a discovery rule they come from. 
 当服务器运行时,它将根据SNMP发现规则返回的值创建实际监控项,触发器和图形。在主机配置中,它们的前缀是橙色链接到它们来自的发现规则。 当服务器运行时,它将根据SNMP发现规则返回的值创建实际监控项,触发器和图形。在主机配置中,它们的前缀是橙色链接到它们来自的发现规则。
Line 403: Line 304:
 === - ODBC SQL查询的发现 === === - ODBC SQL查询的发现 ===
-This type of discovery is done using SQL queries, whose results get automatically transformed into a JSON object suitable for low-level discovery. SQL queries are performed using items of type "​Database monitor"​. Therefore, most of the instructions on [[:​manual/​config/​items/​itemtypes/​odbc_checks|ODBC monitoring]] page apply in order to get a working "​Database monitor"​ discovery rule, the only difference being that "​db.odbc.discovery[<​description>,<​dsn>​]"​ key should be used instead of "​[<​description>,<​dsn>​]"​. 
 这种类型的发现使用SQL查询完成,其结果自动转换为适合于自动发现(LLD)的JSON对象。使用“数据库监控”类型的项目执行SQL查询。因此,[[:​manual/​config/​items/​itemtypes/​odbc_checks|ODBC监控]]页面上的说明都适用于“数据库监控”发现规则,唯一的区别是应该使用"​db.odbc.discovery[<​description>,<​dsn>​]"​键代替"​[<​description>,<​dsn>​]”。 这种类型的发现使用SQL查询完成,其结果自动转换为适合于自动发现(LLD)的JSON对象。使用“数据库监控”类型的项目执行SQL查询。因此,[[:​manual/​config/​items/​itemtypes/​odbc_checks|ODBC监控]]页面上的说明都适用于“数据库监控”发现规则,唯一的区别是应该使用"​db.odbc.discovery[<​description>,<​dsn>​]"​键代替"​[<​description>,<​dsn>​]”。
-As a practical example to illustrate how the SQL query is transformed into JSON, let us consider low-level discovery of Zabbix proxies by performing an ODBC query on Zabbix database. This is useful for automatic creation of "​zabbix[proxy,<​name>,​lastaccess]"​ [[:​manual/​config/​items/​itemtypes/​internal|internal items]] to monitor which proxies are alive. 
 举例来说明SQL查询如何转换为JSON,我们可以通过在Zabbix数据库上执行ODBC查询来执行Zabbix proxies 自动发现(LLD)。这对于自动创建"​zabbix[proxy,<​name>,​lastaccess]" ​ [[:​manual/​config/​items/​itemtypes/​internal|内部项目]]来监视哪些proxies是存活的很有用。 举例来说明SQL查询如何转换为JSON,我们可以通过在Zabbix数据库上执行ODBC查询来执行Zabbix proxies 自动发现(LLD)。这对于自动创建"​zabbix[proxy,<​name>,​lastaccess]" ​ [[:​manual/​config/​items/​itemtypes/​internal|内部项目]]来监视哪些proxies是存活的很有用。
-Let us start with discovery rule configuration:​ 
 让我们从发现规则配置开始: 让我们从发现规则配置开始:
Line 417: Line 314:
 {{manual:​discovery:​low_level_discovery:​discovery_rule_odbc.png}} {{manual:​discovery:​low_level_discovery:​discovery_rule_odbc.png}}
-Here, the following direct query on Zabbix database is used to select all Zabbix proxies, together with the number of hosts they are monitoring. The number of hosts can be used, for instance, to filter out empty proxies: 
 这里,对Zabbix数据库的执行查询用于选择所有Zabbix proxies以及它们正在监视的主机数量。例如,可以使用主机数量来过滤掉空 proxies: 这里,对Zabbix数据库的执行查询用于选择所有Zabbix proxies以及它们正在监视的主机数量。例如,可以使用主机数量来过滤掉空 proxies:
Line 432: Line 328:
 3 rows in set (0.01 sec) 3 rows in set (0.01 sec)
 </​code>​ </​code>​
-By the internal workings of "​db.odbc.discovery[]"​ item, the result of this query gets automatically transformed into the following JSON: 
 通过“db.odbc.discovery []”项目的内部工作,此查询的结果将自动转换为以下JSON: 通过“db.odbc.discovery []”项目的内部工作,此查询的结果将自动转换为以下JSON:
-<​code ​js>+<​code ​java>
 { {
     "​data":​ [     "​data":​ [
Line 461: Line 355:
 <​note>​ <​note>​
-If it is not obvious how a column name would be transformed into a macro name, it is suggested to use column aliases like "​COUNT( AS count" in the example above. 
 如果将列名称变换为宏名称不明显,建议在上述示例中使用像"​COUNT( AS count"​这样的列别名。 如果将列名称变换为宏名称不明显,建议在上述示例中使用像"​COUNT( AS count"​这样的列别名。
-In case a column name cannot be converted into a valid macro name, the discovery rule becomes not supported, with the error message detailing the offending column number. If additional help is desired, the obtained column names are provided under DebugLevel=4 in Zabbix server log file: 
 如果列名称无法转换为有效的宏名称,则不支持发现规则,错误消息将详细列出违规列号。如果需要其他帮助,获取的列名称在Zabbix服务器日志文件中的DebugLevel = 4下提供: 如果列名称无法转换为有效的宏名称,则不支持发现规则,错误消息将详细列出违规列号。如果需要其他帮助,获取的列名称在Zabbix服务器日志文件中的DebugLevel = 4下提供:
Line 479: Line 370:
 </​code>​ </​code>​
 </​note>​ </​note>​
-Now that we understand how a SQL query is transformed into a JSON object, we can use {#HOST} macro in item prototypes: 
 现在我们了解SQL查询如何转换为JSON对象,我们可以在项目原型中使用{#​HOST}宏: 现在我们了解SQL查询如何转换为JSON对象,我们可以在项目原型中使用{#​HOST}宏:
Line 486: Line 375:
 {{manual:​discovery:​low_level_discovery:​item_prototype_odbc.png}} {{manual:​discovery:​low_level_discovery:​item_prototype_odbc.png}}
-Once discovery is performed, an item will be created for each proxy: 
 执行发现后,将为每个proxy创建一个监控项: 执行发现后,将为每个proxy创建一个监控项:
 {{manual:​discovery:​low_level_discovery:​discovered_items_odbc.png}} {{manual:​discovery:​low_level_discovery:​discovered_items_odbc.png}}
-=== - Discovery of Windows ​services ​===+=== - Windows服务的发现 ​===
-Windows ​service discovery is done in the same way as discovery of file systems. The key to use in the  discovery rule is "service.discovery" and the following macros are supported for use in the [[#​discovery_of_file_systems|filter]] and item/trigger/graph prototypes:+ 
 <​code>​ <​code>​
Line 507: Line 396:
 </​code>​ </​code>​
-Based on Windows ​service discovery you may create an item prototype like "​[{#​SERVICE.NAME},<​param>​]"​, where //​param// ​accepts the following values: ​//state//, //​displayname//,​ //path//, //user//, //​startup// ​or //​description//​. For example, to acquire the display name of a service you should use a "​[{#​SERVICE.NAME},​displayname]" ​item. If //​param// ​value is not specified ("​[{#​SERVICE.NAME}]"​)the default parameter ​//state// is used.+基于Windows服务发现,你可以创建一个监控项原型,如"​[{#​SERVICE.NAME},<​param>​]"​),其中//param//接受以下值://state//, //​displayname//,​ //path//, //user//, //​startup// ​或 //​description//​。例如,要获取服务的显示名称,您应该使用"​[{#​SERVICE.NAME},​displayname]"​项目。如果没有指定//param//值("​[{#​SERVICE.NAME}]"​),则使用默认参//​param//​态。 
 +{#SERVICE.STATE}和{#SERVICE.STATENAME}宏返回相同的内容,但{#SERVICE.STATE}返回数值(0-7),而{#SERVICE.STATENAME}返回文字(//​running//​, //paused//, //start pending//, //pause pending//, //continue pending//, //stop pending//, //stopped// or //​unknown//​)。{#SERVICE.STARTUP}和{#SERVICE.STARTUPNAME}也是如此,其中一个返回数字值(0-4),而另一个文本(//​automatic//,​ //automatic delayed//, //manual//, //​disabled//,​ //​unknown//​)。
-{#​SERVICE.STATE} and {#​SERVICE.STATENAME} macros return the same content, however, {#​SERVICE.STATE} returns a numerical value (0-7), while {#​SERVICE.STATENAME} returns text (//​running//,​ //paused//, //start pending//, //pause pending//, //continue pending//, //stop pending//, //stopped// or //​unknown//​). The same applies to {#​SERVICE.STARTUP} and {#​SERVICE.STARTUPNAME},​ where one returns a numerical value (0-4) while the other - text (//​automatic//,​ //automatic delayed//, //manual//, //​disabled//,​ //​unknown//​).+=== 为同一项目设置多个LLD规则 ===
-=== - Setting up multiple LLD rules for the same item === 
-Since Zabbix agent version ​3.2 it is possible to alter low-level discovery item keys using "​Alias"​ parameter in [[manual/​appendix/​config/​zabbix_agentd|zabbix_agentd.conf]] ​file to enable configuration of several ​LLD rules for the same item.+Zabbix agent版本3.2,可以使用[[manual/​appendix/​config/​zabbix_agentd|zabbix_agentd.conf]]文件中的“Alias”参数来更改自动发现项目键值,以便为同一项目配置多个LLD规则。
-=== - Creating custom ​LLD rules ===+=== - 创建自定义LLD规则===
-It is also possible to create a completely custom ​LLD rule, discovering any type of entities ​for example, databases on a database server.+也可以创建完全自定义的LLD规则,发现任何类型的实体 ​例如数据库服务器上的数据库。
-To do so, a custom item should be created that returns ​JSON, specifying found objects and optionally ​some properties of them. The amount of macros per entity is not limited - while the built-in discovery rules return either one or two macros (for example, two for filesystem discovery), it is possible to return more.+为此,应该创建一个返回JSON的自定义项目,指定找到的对象以及可选的一些属性。每个实体的宏数量不受限制 ​而内置的发现规则返回一个或两个宏(例如,两个用于文件系统发现)。
-The required ​JSON format is best illustrated with an example. Suppose we are running an old Zabbix 1.8 agent (one that does not support ​"​vfs.fs.discovery"​), but we still need to discover file systems. Here is a simple ​Perl script for Linux that discovers mounted file systems and outputs ​JSON, which includes both file system name and type. One way to use it would be as a UserParameter with key "​vfs.fs.discovery_perl"​:+下面举例说明JSON格式。假设我们运行一个旧的Zabbix 1.8 agent(不支持"​vfs.fs.discovery"​),但是我们仍然需要发现文件系统。这是一个用于Linux的简单Perl脚本,用于发现挂载的文件系统并输出JSON,其中包含文件系统名称和类型。使用它的一种方式是具有键值"​vfs.fs.discovery_perl"​的参数:
 <code perl> <code perl>
Line 548: Line 439:
 </​code>​ </​code>​
-<note important>​Allowed symbols for LLD macro names are **0-9** , **A-Z** , **_** , **.** \\ \\  Lowercase letters are not supported in the names.</​note>​ 
-An example of its output (reformatted for clarity) is shown below. JSON for custom discovery checks has to follow the same format.+<note important>​对于LLD宏名允许的符号为 **0-9** , **A-Z** , **_** , **.** \\ \\ 名称中不支持小写字母。</​note>​ 
   {   {
Line 571: Line 464:
   }   }
-Then, in the discovery rule's "​Filter"​ field, we could specify "​{#​FSTYPE}"​ as a macro and "​rootfs|ext3"​ as a regular expression. 
-<​note>​You don't have to use macro names FSNAME/FSTYPE ​with custom LLD rules, you are free to use whatever names you like.</​note>​+然后,在发现规则的“过滤器”字段中,我们可以将“{#​FSTYPE}”指定为宏,将 "​rootfs|ext3"​指定为正则表达式。
-=== - Using LLD macros in user macro contexts === 
-User macros [[:manual/config/macros/​usermacros#​user_macro_context|with context]] can be used to accomplish more flexible thresholds in trigger expressions. Different thresholds may be defined on user macro level and then used in trigger constants depending on the discovered context. Discovered context appears when the [[:​manual/​config/​macros/​lld_macros|low-level discovery macros]] used in the macros are resolved to real values.+<​note>​你不一定使用具有自定义LLD规则的宏名称FSNAME/FSTYPE,你可以随意使用任何名称。<​/note>
-To illustrate we can use data from the example above and assume that the following file systems will be discovered: ''/'',​ ''/​home'',​ ''/​tmp'',​ ''/​usr'', ​ ''/​var''​.+=== - 在用户宏上下文中使用LLD宏 ===
-We may define a free-disk-space trigger prototype for a host, where the threshold is expressed by a user macro with context:+ 
 +为了说明我们可以从例子中使用上述数据和假设下面的文件系统将被发现:''/'',​ ''/​home'',​ ''/​tmp'',​ ''/​usr'', ​ ''/​var''​。 
 ''​{host:​vfs.fs.size[{#​FSNAME},​pfree].last()}<​**{$LOW_SPACE_LIMIT:<​nowiki>"</​nowiki>​{#​FSNAME}<​nowiki>"</​nowiki>​}**''​ ''​{host:​vfs.fs.size[{#​FSNAME},​pfree].last()}<​**{$LOW_SPACE_LIMIT:<​nowiki>"</​nowiki>​{#​FSNAME}<​nowiki>"</​nowiki>​}**''​
-Then add user macros:+然后添加用户宏:
   * ''​{$LOW_SPACE_LIMIT}''​ **10**   * ''​{$LOW_SPACE_LIMIT}''​ **10**
   * ''​{$LOW_SPACE_LIMIT:/​home}''​ **20**   * ''​{$LOW_SPACE_LIMIT:/​home}''​ **20**
   * ''​{$LOW_SPACE_LIMIT:/​tmp}''​ **50**   * ''​{$LOW_SPACE_LIMIT:/​tmp}''​ **50**
-Now, once the file systems are discovered, events will be generated if ''/'',​ ''/​usr''​ and ''/​var''​ filesystems have less than **10**% of free disk space, the ''/​home''​ filesystem - less than **20**% of free disk space or the ''/​tmp''​ filesystem - less than **50**% of free disk space. 
-<note important>​LLD macros are not supported inside of user macro contexts in [[manual:​config:​triggers:​expression#​function_parameters|trigger function parameters]].</​note>​+现在,一旦文件系统被发现,事件将被告知是否产生/​,/​usr以及/​var文件系统具有小于**10**% 的可用磁盘空间,该/​home文件系统-小于 **20**% 的可用磁盘空间或,/​tmp的文件系统-小于**50**%的可用磁盘空间 。 
 +<note important>​[[manual:​config:​triggers:​expression#​function_parameters|触发功能参数]]中的用户宏上下文内不支持LLD宏。</​note>​