manual:discovery:low_level_discovery

Differences

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
Next revision Both sides next revision
manual:discovery:low_level_discovery [2015/06/15 06:35]
Igors H [3.6 Discovery of Windows services] added info about windows services
manual:discovery:low_level_discovery [2019/03/06 12:11]
martins-v formatting change
Line 5: Line 5:
 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. 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.
  
-In Zabbix, ​five types of item discovery are supported out of the box:+In Zabbix, ​six types of discovery ​items are supported out of the box:
  
   * discovery of file systems;   * discovery of file systems;
Line 11: Line 11:
   * discovery of CPUs and CPU cores;   * discovery of CPUs and CPU cores;
   * discovery of SNMP OIDs;   * discovery of SNMP OIDs;
-  * discovery using ODBC SQL queries. +  * discovery using ODBC SQL queries; 
-  * discovery of Windows services+  * discovery of Windows services.
  
 A user can define their own types of discovery, provided they follow a particular JSON protocol. A user can define their own types of discovery, provided they follow a particular JSON protocol.
Line 24: Line 24:
 <​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>​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>​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>+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 entitySee the full list of [[:manual/appendix/​macros/​supported_by_location#​macros_used_in_low-level_discovery|options]] for using LLD macros.
  
-These macros are then used in names, keys, and other prototype fields that are basis for creating ​real items, triggers, and graphs for each discovered entityThese macros can be used:+When the server receives a value for a discovery itemit 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"​.
  
-  * for item prototypes in +See also: [[#​discovered_entities|Discovered entities]]
-    * names +
-    * key parameters +
-    * IPMI sensor +
-    * SNMP OIDs +
-    * units +
-    * calculated item formulas +
-    * SSH and Telnet scripts +
-    * database monitor item parameters +
-    * descriptions (supported since 2.2.0) +
-  * for trigger prototypes in +
-    * names +
-    * expressions (insofar as when referencing an item key prototype and as standalone constants)  +
-    * URLs (supported since 3.0.0) +
-    * descriptions (supported since 2.2.0) +
-  * for graph prototypes in +
-    * names+
  
-When the server receives ​value for 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" abovethe server would generate one set of itemstriggersand graphs for the loopback interface "​lo",​ and another set for interface "​eth0"​.+The following sections illustrate ​the process described above in detail and serve as how-to ​for performing all types of discovery ​mentioned above. See [[#​creating_custom_lld_rules|Creating custom LLD rules]] for a description of the JSON format ​for discovery ​items and an example ​of how to implement your own file system discoverer as a Perl script. 
 + 
 +== Data limits for return values == 
 + 
 +There is no limit for low-level discovery rule JSON data if it is received directly by Zabbix server, because return values are processed without being stored in a databaseThere'​s also no limit for custom low-level ​discovery ​ruleshoweverif it is intended to acquire custom LLD data using a user parameterthen user parameter return value limit applies (512 KB).
  
-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 Perl script.+If data has to go through Zabbix proxy it has to store this data in database so [[:​manual/​config/​items/​item#​text_data_limits|database limits]] apply, ​for example, 2048 bytes on Zabbix proxy run with IBM DB2 database.
  
 === - Discovery of file systems === === - Discovery of file systems ===
Line 70: Line 58:
 |//​Type// ​ |The type of check to perform discovery; should be //Zabbix agent// or //Zabbix agent (active)// for file system discovery. ​ | |//​Type// ​ |The type of check to perform discovery; should be //Zabbix agent// or //Zabbix agent (active)// for file system discovery. ​ |
 |//​Key// ​ |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. ​ | |//​Key// ​ |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. ​ |
-|//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. ​ | +|//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. ​ | 
-|//Flexible ​intervals// ​ |You can create ​exceptions ​to //Update interval//. For example:\\ Interval: ​**0**, Period: **6-7,​00:​00-24:​00** - will disable the polling ​at the weekend. Otherwise default update interval will be used.\\ Up to seven flexible intervals can be defined.\\ If multiple flexible intervals overlap, the smallest //​Interval//​ value is used for the overlapping period.\\ See [[manual:appendix:time_period|Time period specification]] page for description of the //Period// format.\\ //Note//: If set to '0', the item will not be polled during the flexible interval duration and will resume polling according to the //Update interval// once the flexible interval period is over.  | +|//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.  | 
-|//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.   |+|//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.   |
 |//​Description// ​ |Enter a description. ​ | |//​Description// ​ |Enter a description. ​ |
 |//​Enabled// ​ |If checked, the rule will be processed. ​ | |//​Enabled// ​ |If checked, the rule will be processed. ​ |
Line 85: Line 73:
  
 <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>​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>​The mistake or typo in regex used in LLD rule may cause deleting thousands of configuration elements, historical values and events for many hosts. For example, incorrect “File systems for discovery” regular expression may cause deleting thousands of items, triggers, historical values and events.</​note>​
  
 <​note>​Discovery rule history is not preserved.</​note>​ <​note>​Discovery rule history is not preserved.</​note>​
Line 93: Line 83:
  
 <​note>​If an item prototype is created with a //​Disabled//​ status, it will be added to a discovered entity, but in a disabled state.</​note>​ <​note>​If an item prototype is created with a //​Disabled//​ status, it will be added to a discovered entity, but in a disabled state.</​note>​
 +
 +//​Application prototype// is an option that is specific in item prototype properties. 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.
  
 We can create several item prototypes for each file system metric we are interested in: We can create several item prototypes for each file system metric we are interested in:
Line 101: Line 93:
  
 {{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png|}} {{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png|}}
 +
 +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.
 +
 +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:​discovery:​low_level_discovery:​trigger_prototypes_fs.png|}} {{manual:​discovery:​low_level_discovery:​trigger_prototypes_fs.png|}}
  
-And graph prototypes too:+We can create ​graph prototypestoo:
  
 {{manual:​discovery:​low_level_discovery:​graph_prototype_fs.png|}} {{manual:​discovery:​low_level_discovery:​graph_prototype_fs.png|}}
Line 116: Line 112:
 //Note//: For configuring host prototypes, see the section about [[:​manual/​vm_monitoring#​host_prototypes|host prototype]] configuration in virtual machine monitoring. //Note//: For configuring host prototypes, see the section about [[:​manual/​vm_monitoring#​host_prototypes|host prototype]] configuration in virtual machine monitoring.
  
-The screenshots below illustrate how discovered items, triggers, and graphs look like in the host's configuration. Discovered entities are prefixed with a golden ​link to a discovery rule they come from.+== - Discovered entities == 
 + 
 +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.
  
 {{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.+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. An error message is displayed in this case that the low-level discovery rule could not create certain entities.
  
 Items (similarly, triggers and graphs) created by a low-level discovery rule cannot be manually deleted. However, they 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. Items (similarly, triggers and graphs) created by a low-level discovery rule cannot be manually deleted. However, they 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.
  
-When discovered entities become 'Not discovered anymore', ​an orange ​lifetime indicator is displayed in the items list. Move your mouse pointer over it and a message will be displayed indicating how many days are left until the item will be deleted.+When discovered entities become 'Not discovered anymore', ​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.
  
-{{1.9.9_lifetime_indicator.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. 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.
  
 {{manual:​discovery:​low_level_discovery:​discovered_triggers.png|}} {{manual:​discovery:​low_level_discovery:​discovered_triggers.png|}}
Line 148: Line 148:
 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 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.
  
-Item prototypes that can be created based on CPU discovery include "​system.cpu.load[{#​CPU.NUMBER},​ <​mode>​]"​"​system.cpu.util[{#​CPU.NUMBER},​ <type>, <mode>​]" ​et al.+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>​]"​.
  
 === - Discovery of SNMP OIDs === === - Discovery of SNMP OIDs ===
Line 180: Line 180:
  
 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**: 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**:
-  ​+ 
-      "​data":​ [ +<code java> 
-          +
-              "​{#​SNMPINDEX}":​ "​1",​ +    "​data":​ [ 
-              "​{#​IFDESCR}":​ "lo", +        
-              "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​90:​7a:​75"​ +            "​{#​SNMPINDEX}":​ "​1",​ 
-          }, +            "​{#​IFDESCR}":​ "WAN", 
-          +            "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​90:​7a:​75"​ 
-              "​{#​SNMPINDEX}":​ "​2",​ +        }, 
-              "​{#​IFDESCR}":​ "eth1", +        
-              "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​90:​7a:​75+            "​{#​SNMPINDEX}":​ "​2",​ 
-          }, +            "​{#​IFDESCR}":​ "LAN1", 
-          +            "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​90:​7a:​76
-              "​{#​SNMPINDEX}":​ "​3",​ +        }, 
-              "​{#​IFDESCR}":​ "eth0", +        
-              "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​2b:​af:​9e"​ +            "​{#​SNMPINDEX}":​ "​3",​ 
-          +            "​{#​IFDESCR}":​ "LAN2", 
-      +            "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​2b:​af:​9e"​ 
-  }+        
 +    
 +} 
 +</​code>​
  
 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: 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:
Line 211: Line 214:
    
 Then in this case SNMP discovery ''​discovery[{#​IFDESCR},​ ifDescr, {#IFALIAS}, ifAlias]''​ will return the following structure: ​ Then in this case SNMP discovery ''​discovery[{#​IFDESCR},​ ifDescr, {#IFALIAS}, ifAlias]''​ will return the following structure: ​
-  ​+ 
-      "​data":​ [ +<code java> 
-          +
-              "​{#​SNMPINDEX}":​ 1, +    "​data":​ [ 
-              "​{#​IFDESCR}":​ "​Interface #1", +        
-              "​{#​IFALIAS}":​ "​eth0"​ +            "​{#​SNMPINDEX}":​ 1, 
-          }, +            "​{#​IFDESCR}":​ "​Interface #1", 
-          +            "​{#​IFALIAS}":​ "​eth0"​ 
-              "​{#​SNMPINDEX}":​ 2, +        }, 
-              "​{#​IFDESCR}":​ "​Interface #2", +        
-              "​{#​IFALIAS}":​ "​eth1"​ +            "​{#​SNMPINDEX}":​ 2, 
-          }, +            "​{#​IFDESCR}":​ "​Interface #2", 
-          +            "​{#​IFALIAS}":​ "​eth1"​ 
-              "​{#​SNMPINDEX}":​ 3, +        }, 
-              "​{#​IFALIAS}":​ "​eth2"​ +        
-          }, +            "​{#​SNMPINDEX}":​ 3, 
-          +            "​{#​IFALIAS}":​ "​eth2"​ 
-              "​{#​SNMPINDEX}":​ 4, +        }, 
-              "​{#​IFDESCR}":​ "​Interface #4" +        
-          }, +            "​{#​SNMPINDEX}":​ 4, 
-          +            "​{#​IFDESCR}":​ "​Interface #4" 
-              "​{#​SNMPINDEX}":​ 5, +        }, 
-              "​{#​IFALIAS}":​ "​eth4"​ +        
-          +            "​{#​SNMPINDEX}":​ 5, 
-      +            "​{#​IFALIAS}":​ "​eth4"​ 
-  }  ​+        
 +    
 +}  ​ 
 +</​code>​
  
 {{manual:​discovery:​low_level_discovery:​lld_rule_snmp.png|}} {{manual:​discovery:​low_level_discovery:​lld_rule_snmp.png|}}
Line 262: Line 268:
 A summary of our discovery rule: A summary of our discovery rule:
  
-{{manual:​discovery:​low_level_discovery:​lld_rules_snmp.png?600|}}+{{manual:​discovery:​low_level_discovery:​lld_rules_snmp.png|}}
  
-When server runs, it will create real items, triggersand graphsbased on the values ​"snmp.discovery" ​returns. In host'​s ​configuration they will be prefixed with a golden ​link to a discovery rule they come from.+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.
  
-{{manual:​discovery:​low_level_discovery:​discovered_items_snmp.png|}}+{{manual:​discovery:​low_level_discovery:​discovered_items_snmp.png?600|}}
  
-{{manual:​discovery:​low_level_discovery:​discovered_triggers_snmp.png|}}+{{manual:​discovery:​low_level_discovery:​discovered_triggers_snmp.png?600|}}
  
-{{manual:​discovery:​low_level_discovery:​discovered_graphs_snmp.png|}}+{{manual:​discovery:​low_level_discovery:​discovered_graphs_snmp.png?600|}}
  
 === - Discovery using ODBC SQL queries === === - Discovery using ODBC SQL queries ===
Line 298: Line 304:
 By the internal workings of "​db.odbc.discovery[]"​ item, the result of this query gets automatically transformed into the following JSON: By the internal workings of "​db.odbc.discovery[]"​ item, the result of this query gets automatically transformed into the following JSON:
  
-<​code ​js>+<​code ​java>
 { {
     "​data":​ [     "​data":​ [
Line 341: Line 347:
 Once discovery is performed, an item will be created for each proxy: Once discovery is performed, an item will be created for each proxy:
  
-{{manual:​discovery:​low_level_discovery:​discovered_items_odbc.png}}+{{manual:​discovery:​low_level_discovery:​discovered_items_odbc.png?600}}
  
 === - Discovery of Windows services === === - Discovery of Windows services ===
  
-Discovery of Windows ​services ​is done in exactly ​the same way as discovery of file systems. The discovery rule key is "​service.discovery"​ and the following macros are supported in filter and item/​trigger/​graph prototypes:+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>​
-#​SERVICE.NAME +{#​SERVICE.NAME} 
-#​SERVICE.DISPLAYNAME +{#​SERVICE.DISPLAYNAME} 
-#​SERVICE.DESCRIPTION +{#​SERVICE.DESCRIPTION} 
-#​SERVICE.STATE +{#​SERVICE.STATE} 
-#​SERVICE.STATENAME +{#​SERVICE.STATENAME} 
-#​SERVICE.PATH +{#​SERVICE.PATH} 
-#​SERVICE.USER +{#​SERVICE.USER} 
-#​SERVICE.STARTUP +{#​SERVICE.STARTUP} 
-#​SERVICE.STARTUPNAME+{#​SERVICE.STARTUPNAME}
 </​code>​ </​code>​
  
-THe item prototype that can be created based on Windows service discovery ​is "​service.info[{#​SERVICE.NAME},​ <​param>​]",​ where //​param// ​field can accept ​the following: //displayname//, //state//, //path//, //user//, //startup// or //​description//​. For example, ​item "​service.info[{#​SERVICE.NAME},​ displayname]" ​should be used to acquire the display name of a serviceThe default parameter is //state// if //param// value is not specified ("​service.info[{#​SERVICE.NAME}]"​). ​+Based on Windows service discovery ​you may create an item prototype like "​service.info[{#​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.info[{#​SERVICE.NAME},​displayname]" ​itemIf //param// value is not specified ("​service.info[{#​SERVICE.NAME}]"​), the default parameter //state// is used.
  
-Macro #​SERVICE.STATE and macro #​SERVICE.STATENAME return the same values - #​SERVICE.STATE returns numerical value (0-7), ​but #​SERVICE.STATENAME returns text (running, paused, start pending, pause pending, continue pending, stop pending, stopped or unknown). The same applies to #​SERVICE.STARTUP ​(0-4) and #​SERVICE.STARTUPNAME (automatic, automatic delayed, manual, disabled, unknown)+{#​SERVICE.STATEand {#​SERVICE.STATENAME} macros ​return the same content, however, {#​SERVICE.STATEreturns ​numerical value (0-7), ​while {#​SERVICE.STATENAMEreturns text (//running////paused////start pending////pause pending////continue pending////stop pending////stopped// or //unknown//). The same applies to {#​SERVICE.STARTUPand {#​SERVICE.STARTUPNAME}, where one returns a numerical value (0-4) while the other - text (//automatic////automatic delayed////manual////disabled////unknown//).
- +
-[[#​discovery_of_file_systems|See above]] for more information about the filter.+
 === - Creating custom LLD rules === === - Creating custom LLD rules ===
  
Line 383: Line 387:
 { {
     ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;     ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
-    $fsname =~ s!/!\\/!g; 
  
     print "​\t,​\n"​ if not $first;     print "​\t,​\n"​ if not $first;
Line 405: Line 408:
     "​data":​[     "​data":​[
     ​     ​
-    { "​{#​FSNAME}":"​\/", ​                          "​{#​FSTYPE}":"​rootfs" ​  }, +    { "​{#​FSNAME}":"/", ​                          "​{#​FSTYPE}":"​rootfs" ​  }, 
-    { "​{#​FSNAME}":"​\/​sys", ​                       "​{#​FSTYPE}":"​sysfs" ​   }, +    { "​{#​FSNAME}":"/​sys", ​                       "​{#​FSTYPE}":"​sysfs" ​   }, 
-    { "​{#​FSNAME}":"​\/​proc", ​                      "​{#​FSTYPE}":"​proc" ​    }, +    { "​{#​FSNAME}":"/​proc", ​                      "​{#​FSTYPE}":"​proc" ​    }, 
-    { "​{#​FSNAME}":"​\/​dev", ​                       "​{#​FSTYPE}":"​devtmpfs"​ }, +    { "​{#​FSNAME}":"/​dev", ​                       "​{#​FSTYPE}":"​devtmpfs"​ }, 
-    { "​{#​FSNAME}":"​\/dev\/​pts", ​                  ​"​{#​FSTYPE}":"​devpts" ​  }, +    { "​{#​FSNAME}":"/​dev/​pts", ​                   "​{#​FSTYPE}":"​devpts" ​  }, 
-    { "​{#​FSNAME}":"​\/", ​                          "​{#​FSTYPE}":"​ext3" ​    }, +    { "​{#​FSNAME}":"/​lib/​init/​rw", ​               "​{#​FSTYPE}":"​tmpfs" ​   }, 
-    { "​{#​FSNAME}":"​\/lib\/init\/​rw", ​             "​{#​FSTYPE}":"​tmpfs" ​   }, +    { "​{#​FSNAME}":"/​dev/​shm", ​                   "​{#​FSTYPE}":"​tmpfs" ​   }, 
-    { "​{#​FSNAME}":"​\/dev\/​shm", ​                  ​"​{#​FSTYPE}":"​tmpfs" ​   }, +    { "​{#​FSNAME}":"/​home", ​                      "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​home", ​                      "​{#​FSTYPE}":"​ext3" ​    }, +    { "​{#​FSNAME}":"/​tmp", ​                       "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​tmp", ​                       "​{#​FSTYPE}":"​ext3" ​    }, +    { "​{#​FSNAME}":"/​usr", ​                       "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​usr", ​                       "​{#​FSTYPE}":"​ext3" ​    }, +    { "​{#​FSNAME}":"/​var", ​                       "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​var", ​                       "​{#​FSTYPE}":"​ext3" ​    }, +    { "​{#​FSNAME}":"/​sys/​fs/​fuse/​connections", ​   "​{#​FSTYPE}":"​fusectl" ​ }
-    { "​{#​FSNAME}":"​\/sys\/fs\/fuse\/​connections",​ "​{#​FSTYPE}":"​fusectl" ​ }+
     ​     ​
     ]     ]
Line 425: Line 427:
  
 <​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>​ <​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>​
 +
 +Note that, if using a user parameter, the return value is limited to 512 KB. For more details, see [[:​manual/​discovery/​low_level_discovery#​data_limits_for_return_values|data limits for LLD return values]].
 +
 +=== - 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/​appendix/​macros/​supported_by_location#​macros_used_in_low-level_discovery|low-level discovery macros]] used in the macros are resolved to real values.
 +
 +To illustrate we can use data from the example above and assume that the following file systems will be discovered: ''/'',​ ''/​home'',​ ''/​tmp'',​ ''/​usr'', ​ ''/​var''​.
 +
 +We may define a free-disk-space trigger prototype for a host, where the threshold is expressed by a user macro with context:
 +
 +''​{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:/​home}''​ **20**
 +  * ''​{$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>​
 +