This is the documentation page for an unsupported version of Zabbix.
Is this not what you were looking for? Switch to the current version or choose one from the drop-down menu.

1 Usage examples

Overview

This section presents examples of using preprocessing steps to accomplish some practical tasks.

Filtering VMware event log records

This example uses the Matches regular expression preprocessing step to filter unnecessary events from the VMware event log.

1. On a working VMware Hypervisor host, check that the event log item vmware.eventlog is present and working properly. Note that the event log item could already be present on the hypervisor if a VMware template has been linked during the host creation.

2. On the VMware Hypervisor host, create a dependent item of "Log" type and set the event log item as its master.

3. In the Preprocessing tab of the dependent item, select the "Matches regular expression" preprocessing step and specify, for example, one of the following parameters:

# Filters all log events:
       pattern: .* logged in .*
       
       # Filters lines containing usernames after "User":
       pattern: \bUser\s+\K\S+

If the regular expression is not matched, then the dependent item becomes unsupported with a corresponding error message. To avoid this, mark the "Custom on fail" checkbox and select an option such as discarding the value or setting a custom one. Please note that discarded values are not stored in the database; as a result, triggers are not evaluated and trend data is not generated.

Alternatively, you may use the Regular expression preprocessing step to extract matching groups and control output. For example:

# Extracts and outputs the entire log event containing "logged in":
       pattern: .*logged in.*
       output: \0
       
       # Extracts and outputs usernames following "User":
       pattern: User (.*?)(?=\ )
       output: \1

Checking retrieved value type

This example uses the Custom multiplier preprocessing step to check if the retrieved item value type is numeric.

In the Preprocessing tab of an item, select the "Custom multiplier" preprocessing step and set the following parameter:

# Multiplies the retrieved value by 1:
       number: 1

If preprocessing fails (e.g., input is not numeric), then the item becomes unsupported with a corresponding error message. To avoid this, mark the "Custom on fail" checkbox and select an option such as discarding the value or setting a custom one. Please note that discarded values are not stored in the database; as a result, triggers are not evaluated and trend data is not generated.

Checking for not supported value

This example uses the Check for not supported value preprocessing step to check if the item value could not be retrieved.

When a Zabbix server/proxy poller process attempts to collect an item value, it may:

  • Return a valid result.
  • Return a result that initially seems valid but may become unsupported later (e.g., due to a value type mismatch after preprocessing).
  • Return an error of collecting the value, causing the item to become unsupported. Common causes include:
    • Unknown item key (for Zabbix agent, Simple check, or Zabbix internal items)
    • Unknown OID (SNMP agent), unknown sensor (IPMI agent), or no JMX metric (JMX agent)
    • Cannot read trap file (SNMP trap)
    • Script not found (External check)
    • No such URL (HTTP agent)
    • Login failed (SSH agent, TELNET agent)
    • Invalid formula syntax (Calculated), JavaScript syntax error (Script), or invalid SQL (Database monitor)

To detect and handle errors of collecting item values, you can use the "Check for not supported value" preprocessing step. Note that this step is always executed first and only detects errors that occur before preprocessing begins.

In the Preprocessing tab of an item, select the "Check for not supported value" preprocessing step.

Then, use the Custom on fail option to discard the value (in this case, the error), set a custom value, or return a custom error message. Please note that discarded values are not stored in the database; as a result, triggers are not evaluated and trend data is not generated.