Это перевод страницы документации с английского языка. Помогите нам сделать его лучше.

1. Примеры использования

Обзор

В этом разделе представлены примеры использования шагов предварительной обработки для решения некоторых практических задач.

Фильтрация записей журнала событий VMware

В этом примере используется шаг предварительной обработки Совпадение регулярному выражению для фильтрации ненужных событий из журнала событий VMware.

1. Убедитесь, что на работающем узле сети гипервизора VMware элемент данных журнала событий vmware.eventlog присутствует и работает должным образом. Обратите внимание, что элемент данных журнала событий уже может присутствовать у гипервизора, если при создании узла сети был присоединён шаблон VMware.

2. На узле сети гипервизора VMware создайте зависимый элемент данных с типом «Журнал (лог)» и выберите элемент данных журнала событий в качестве основного элемента данных.

3. На вкладке Предобработка зависимого элемента данных выберите шаг предобработки «Совпадение регулярному выражению» и укажите, например, один из следующих параметров:

# Фильтрация всех событий входа в систему:
       pattern: .* logged in .*
       
       # Фильтрация строк, содержащих имена пользователей после «User»:
       pattern: \bUser\s+\K\S+

Если нет соответствия регулярному выражению, то зависимый элемент данных станет неподдерживаемым с соответствующим сообщением об ошибке. Чтобы избежать этого, отметьте флажок «Другое при ошибке» и выберите опцию — например, отбросить значение либо выставить пользовательское значение.

В качестве альтернативы вы можете использовать шаг предварительной обработки Регулярное выражение для извлечения соответствующих групп и управления выводом. Например:

# Извлечь и вывести из журнала событий полное событие, содержащащее строку «logged in»:
       pattern: .*logged in.*
       output: \0
       
       # Извлечь и вывести имена пользователей после «User»:
       pattern: User (.*?)(?=\ )
       output: \1

Проверка типа полученного значения

В этом примере используется шаг предварительной обработки Пользовательский множитель для проверки того, является ли тип полученного значения элемента данных числовым.

На вкладке Предобработка элемента данных выберите шаг предварительной обработки «Пользовательский множитель» и задайте следующий параметр:

# Домножить полученное значение на 1:
       число: 1

Если предварительная обработка не удалась (например, значение на входе не является числовым), то элемент данных становится неподдерживаемым с соответствующим сообщением об ошибке. Чтобы избежать этого, отметьте флажок «Другое при ошибке» и выберите параметр, например, отбрасывание значения или установка пользовательского значения.

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.