[comment]: # ({a14b62f1-a14b62f1}) # 3. Низкоуровневое обнаружение (LLD) [comment]: # ({/a14b62f1-a14b62f1}) [comment]: # ({d9e6fe1c-4fc0f22c}) ### Обзор Низкоуровневое обнаружение (LLD) предоставляет способ автоматически создавать элементы данных, триггеры и графики для различных сущностей на узле сети. Например, Zabbix может автоматически начать мониторинг файловых систем или сетевых интерфейсов на вашем компьютере без необходимости вручную создавать элементы данных для каждой файловой системы или сетевого интерфейса. LLD также может создавать узлы сети, например, для [заполнения виртуальных машин](/manual/vm_monitoring), обнаруженных на гипервизоре, и [вложенных правил обнаружения](/manual/discovery/low_level_discovery/discovery_prototypes), что позволяет выполнять многоуровневое обнаружение. Кроме того, можно настроить Zabbix так, чтобы он автоматически удалял ненужные сущности на основе фактических результатов периодически выполняемого обнаружения. Пользователь может определить собственные типы обнаружения при условии, что они следуют определенному JSON-протоколу. Общая архитектура процесса обнаружения выглядит следующим образом. Сначала пользователь создает правило обнаружения в *Сбор данных > Шаблоны*, в столбце *Обнаружение*. Правило обнаружения состоит из (1) элемента данных, который обнаруживает необходимые сущности (например, файловые системы или сетевые интерфейсы), и (2) прототипов элементов данных, триггеров и графиков, которые должны быть созданы на основе значения этого элемента данных. Элемент данных, который обнаруживает необходимые сущности, похож на обычный элемент данных, встречающийся в других местах: сервер запрашивает у агента Zabbix (или у того типа, который задан для элемента данных) значение этого элемента данных, а агент отвечает текстовым значением. Разница в том, что значение, которое возвращает агент, должно содержать список обнаруженных сущностей в формате JSON. Хотя детали этого формата важны только для разработчиков пользовательских проверок обнаружения, необходимо знать, что возвращаемое значение содержит список пар макрос → значение. Например, элемент данных "net.if.discovery" может вернуть две пары: "{\#IFNAME}" → "lo" и "{\#IFNAME}" → "eth0". Эти макросы используются в именах, ключах и других полях прототипов, где затем подставляются полученные значения для создания реальных элементов данных, триггеров, графиков или даже узлов сети для каждой обнаруженной сущности. См. полный список [параметров](/manual/config/macros/lld_macros) для использования макросов LLD. Когда сервер получает значение для элемента данных обнаружения, он анализирует пары макрос → значение и для каждой пары создает реальные элементы данных, триггеры и графики на основе их прототипов. В приведенном выше примере с "net.if.discovery" сервер создал бы один набор элементов данных, триггеров и графиков для петлевого интерфейса "lo" и еще один набор для интерфейса "eth0". Обратите внимание, что начиная с **Zabbix 4.2** формат JSON, возвращаемого правилами низкоуровневого обнаружения, был изменен. Больше не ожидается, что JSON будет содержать объект "data". Теперь низкоуровневое обнаружение принимает обычный JSON, содержащий массив, чтобы поддерживать новые возможности, такие как предварительная обработка значения элемента данных и пользовательские пути к значениям макросов низкоуровневого обнаружения в JSON-документе. Встроенные ключи обнаружения были обновлены так, чтобы возвращать массив строк LLD в корне JSON-документа. Zabbix автоматически извлечет макрос и значение, если поле массива использует синтаксис {\#MACRO} в качестве ключа. Все новые встроенные проверки обнаружения будут использовать новый синтаксис без элементов "data". При обработке значения низкоуровневого обнаружения сначала определяется корень (массив в `$.` или `$.data`). Хотя элемент "data" был удален из всех встроенных элементов данных, связанных с обнаружением, для обратной совместимости Zabbix по-прежнему будет принимать JSON-нотацию с элементом "data", хотя ее использование не рекомендуется. Если JSON содержит объект только с одним элементом массива "data", то содержимое этого элемента будет автоматически извлечено с использованием JSONPath `$.data`. Низкоуровневое обнаружение теперь принимает необязательные пользовательские макросы LLD с пользовательским путем, указанным в синтаксисе JSONPath. ::: notewarning В результате указанных выше изменений более новые агенты больше не смогут работать со старым сервером Zabbix. ::: См. также: [Обнаруженные сущности](#discovered-entities) [comment]: # ({/d9e6fe1c-4fc0f22c}) [comment]: # ({4fe6a092-61b5f21c}) ### Настройка низкоуровневого обнаружения Мы продемонстрируем низкоуровневое обнаружение на примере обнаружения файловой системы. Чтобы настроить обнаружение, выполните следующие действия: - Перейдите в: *Сбор данных* > *Шаблоны* или *Узлы сети*. - Нажмите *Обнаружение* в строке соответствующего шаблона/узла сети. ![](../../../assets/en/manual/discovery/low_level_discovery/fs_templates.png){width="600"} - Нажмите *Создать правило обнаружения* в правом верхнем углу экрана. - Заполните форму правила обнаружения, указав необходимые сведения. [comment]: # ({/4fe6a092-61b5f21c}) [comment]: # ({6bb5f59f-ae1c521e}) #### Правило обнаружения Диалог правила обнаружения содержит пять вкладок, представляющих (слева направо) поток обработки данных во время обнаружения: - *Правило обнаружения (Discovery rule)* — самое главное, определяет встроенный элемент данных или пользовательский сценарий для получения данных обнаружения. - *Предобработка (Preprocessing)* — применяет какую-либо предобработку к данным обнаружения. - *LLD макросы (LLD macros)* — позволяет извлечь значения некоторых макросов, чтобы использовать в обнаруженных элементах данных, триггерах и т.д. - *Фильтры (Filters)* — позволяет отфильтровать обнаруженные значения. - *Замещения (Overrides)* — позволяет изменить прототипы элементов данных, триггеров, графиков или узлов сети, когда они применяются к конкретным найденным объектам. Вкладка **Правило обнаружения (Discovery rule)** содержит ключ элемента данных, используемого для обнаружения (а также некоторые общие атрибуты правила обнаружения): ![](../../../assets/en/manual/discovery/low_level_discovery/lld_rule_fs.png) Все обязательные поля ввода отмечены красной звёздочкой. |Параметр|Описание| |--|--------| |*Имя (Name)*|Имя правила обнаружения.| |*Тип*
*(Type)*|Тип проверки выполняемого обнаружения.
В данном примере мы используем тип *Zabbix агент*.
Правило обнаружения также может являться [зависимым элементом данных](/manual/config/items/itemtypes/dependent_items), зависящим от обычного элемента данных. Оно не может зависеть от другого правила обнаружения. Для зависимых элементов данных выберите соответствующий тип (*Зависимый элемент данных (Dependent item)*) и укажите основной элемент данных в поле «Основной элемент данных (Master item)». Основной элемент данных должен существовать.| |*Ключ*
*(Key)*|Введите ключ элемента данных, используемого для обнаружения (до 2048 символов).
Например, вы можете использовать встроенный ключ элемента данных «vfs.fs.discovery», который возвращает строку JSON со списком файловых систем, присутствующих в компьютере, их типов и опций монтирования.
Обратите внимание, что другой вариант обраружения файловых систем — это использовать результаты, возвращаемые ключом агента «vfs.fs.get» (смотрите [пример](/manual/discovery/low_level_discovery/examples/mounted_filesystems)).| |*Интервал обновления*
*(Update interval)*|Это поле задаёт, как часто Zabbix выполняет обнаружение. Вначале, когда вы только настраиваете обнаружение файловых систем, вы можете указать маленький интервал; но как только вы удостоверитесь что всё работает, вы можете установить его в 30 минут или более, потому что обычно файловые системы не меняются очень часто.
Поддерживаются [суффиксы времени](/manual/appendix/suffixes), например: 30s, 1m, 2h, 1d.
Поддерживаются [пользовательские макросы](/manual/config/macros/user_macros).
*Обратите внимание*: интервал обновления может быть выставлен в «0» только если существует пользовательский интервал с ненулевым значением. Если укажете значение, равное «0», и пользовательский интервал (переменный или по расписанию) с ненулевым значением существует, элемент данных будет опрашиваться в течение действия переменного интервала.
Новые правила обнаружения будут проверяться в течение 60 секунд с момента их создания, если только для них не заданы интервал обновления по расписанию или переменный интервал обновления, а *Интервал обновления (Update interval)* не установлен в 0.
*Обратите внимание*, что уже созданное правило обнаружения можно выполнить незамедлительно нажатием [кнопки](#кнопки-диалога) *Выполнить сейчас*.| |*Пользовательские интервалы*
*(Custom intervals)*|Вы можете создавать пользовательские правила проверки элемента данных:
**Гибкий (Flexible)** — создание исключений из *Интервала обновления* (интервал с другой частотой обновления)
**По расписанию (Scheduling)** — создание пользовательского расписания проверки.
Для получения более подробной информации смотрите [Пользовательские интервалы](/manual/config/items/item/custom_intervals).| |*Время ожидания*
*(Timeout)*|Укажите тайм-аут проверки обнаружения. Выберите вариант тайм-аута:
**Глобальный (Global)** — используется глобальный тайм-аут или тайм-аут прокси (отображается в поле *Время ожидания* на сером фоне);
**Замещения (Override)** — применяется пользовательский тайм-аут (заданный в поле *Время ожидания*; допустимый диапазон: 1 - 600s). Поддерживаются [суффиксы времени](/manual/appendix/suffixes#суффиксы-времени), например: 30s, 1m; также поддерживаются [пользовательские макросы](/manual/config/macros/user_macros).
Щелчок по ссылке *Время ожидания (Timeouts)* позволяет настроить тайм-ауты [прокси](/manual/distributed_monitoring/proxies#настройка) либо [глобальные](/manual/web_interface/frontend_sections/administration/general#время-ожидания) тайм-ауты (если прокси не используется). Обратите внимание, что ссылка *Время ожидания (Timeouts)* видна только пользователям с типом *Супер-администратор*, имеющим доступ к разделам веб-интерфейса *Администрирование (Administration)* → [*Общие (General)*](/manual/web_interface/frontend_sections/administration/general) или *Администрирование (Administration)* → [*Прокси (Proxies)*](/manual/web_interface/frontend_sections/administration/proxies).| |*Удаление потерянных ресурсов*
*(Delete lost resources)*|Укажите, через какое время обнаруженный объект будет удалён, после того как его состояние обнаружения станет «более не обнаруживается (Not discovered anymore)»:
*Никогда (Never)* — не будет удалён;
*Незамедлительно (Immediately)* — будет удалён сразу же;
*После (After)* — будет удалён по истечении указанного периода времени. Значение должно быть больше, чем значение в поле *Деактивация потерянных ресурсов (Disable lost resources)*.
Поддерживаются [суффиксы времени](/manual/appendix/suffixes), например: 2h, 1d.
Поддерживаются [пользовательские макросы](/manual/config/macros/user_macros).
*Обратите внимание*: Использование значения «Незамедлительно (Immediately)» не рекомендуется, так как простое ошибочное изменение фильтра может закончиться тем, что объект будет удалён вместе со всеми данными истории.
Обратите внимание, что ресурсы, деактивированные вручную, правилом низкоуровневого обнаружения удалены не будут.| |*Деактивация потерянных ресурсов*
*(Disable lost resources)*|Укажите, через какое время обнаруженный объект будет деактивирован, после того как его состояние обнаружения станет «более не обнаруживается (Not discovered anymore)»:
*Никогда (Never)* — не будет деактивирован;
*Незамедлительно (Immediately)* — будет деактивирован сразу же;
*После (After)* — будет деактивирован по истечении указанного периода времени. Значение должно быть больше, чем интервал обновления правила обнаружения.
Обратите внимание, что автоматически деактивированные ресурсы будут активированы снова, если будут заново обнаружены низкоуровневым обнаружением. Ресурсы, деактивированные вручную, не станут активированы снова при повторном обнаружении.
Это поле не отображается, если параметр *Удаление потерянных ресурсов (Delete lost resources)* задан в «Незамедлительно (Immediately)».
Поддерживаются [суффиксы времени](/manual/appendix/suffixes), например: 2h, 1d.
Поддерживаются [пользовательские макросы](/manual/config/macros/user_macros).| |*Описание (Description)*|Введите описание.| |*Активировано (Enabled)*|Если отмечено, правило будет обрабатываться.| ::: noteclassic История правил обнаружения не сохраняется. ::: [comment]: # ({/6bb5f59f-ae1c521e}) [comment]: # ({2e8e1698-0e438e85}) #### Предобработка Вкладка **Предобработка** позволяет определить правила преобразования, применяемые к результату обнаружения. На этом этапе возможны одно или несколько преобразований. Преобразования выполняются в том порядке, в котором они определены. Вся предобработка выполняется сервером Zabbix. См. также: - [Подробности предобработки](/manual/config/items/preprocessing/preprocessing_details) - [Тестирование предобработки](/manual/config/items/preprocessing#testing) ![](../../../assets/en/manual/discovery/low_level_discovery/lld_fs_b.png) |Type|<|<| |-|----------|----------------------------------------| | |*Transformation*|Description| |Text|<|<| |<|*Regular expression*|Сопоставьте полученное значение с регулярным выражением и замените значение извлеченным . Регулярное выражение поддерживает извлечение максимум 10 захваченных групп с помощью последовательности \\N.
Параметры:
**pattern** - регулярное выражение
**output** - шаблон форматирования вывода. Экранирующая последовательность \\N (где N=1…9) заменяется на N-ю совпавшую группу. Экранирующая последовательность \\0 заменяется на совпавший текст.
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| |^|*Replace*|Найдите строку поиска и замените ее другой строкой (или ничем). Все вхождения строки поиска будут заменены.
Параметры:
**search string** - строка для поиска и замены, с учетом регистра (обязательно)
**replacement** - строка, которой нужно заменить строку поиска. Строка замены также может быть пустой, что фактически позволяет удалить строку поиска при ее нахождении.
Можно использовать escape-последовательности для поиска или замены разрывов строк, возврата каретки, табуляции и пробелов "\\n \\r \\t \\s"; обратную косую черту можно экранировать как "\\\\" и escape-последовательности можно экранировать как "\\\\n". Экранирование разрывов строк, возврата каретки и табуляции автоматически выполняется во время обнаружения на низком уровне.| |Structured data|<|<| |<|*JSONPath*|Извлеките значение или фрагмент из данных JSON с помощью [функциональности JSONPath](/manual/config/items/preprocessing/jsonpath_functionality).
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| |<|*XML XPath*|Извлеките значение или фрагмент из данных XML с помощью функциональности XPath.
Чтобы эта опция работала, сервер Zabbix должен быть собран с поддержкой libxml.
Примеры:
`number(/document/item/value)` извлечет `10` из `10`
`number(/document/item/@attribute)` извлечет `10` из ``
`/document/item` извлечет `10` из `10`
Обратите внимание, что пространства имен не поддерживаются.
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| |<|*CSV to JSON*|Преобразуйте данные CSV-файла в формат JSON.
Дополнительные сведения см. в разделе: [Предобработка CSV to JSON](/manual/config/items/preprocessing/csv_to_json#csv-header-processing).| |^|*XML to JSON*|Преобразуйте данные в формате XML в JSON.
Дополнительные сведения см. в разделе: [Правила сериализации](/manual/config/items/preprocessing/javascript/javascript_objects#serialization-rules).
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| |SNMP|<|<| | |*SNMP walk value*|Извлеките значение по указанному имени OID/MIB и примените параметры форматирования:
**Unchanged** - вернуть Hex-STRING как неэкранированную шестнадцатеричную строку (*note*: при этом по-прежнему применяются подсказки отображения);
**UTF-8 from Hex-STRING** - преобразовать Hex-STRING в строку UTF-8;
**MAC from Hex-STRING** - преобразовать Hex-STRING в строку MAC-адреса (при этом `' '` будет заменено на `':'`);
**Integer from BITS** - преобразовать первые 8 байт битовой строки, представленной последовательностью шестнадцатеричных символов (например, "1A 2B 3C 4D"), в 64-битное беззнаковое целое. В битовых строках длиннее 8 байт последующие байты будут проигнорированы.
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| | |*SNMP walk to JSON*|Преобразуйте значения SNMP в JSON. Укажите имя поля в JSON и соответствующий путь SNMP OID. Значения полей будут заполнены значениями по указанному пути SNMP OID.
Этот шаг предобработки можно использовать для [обнаружения SNMP OID](/manual/discovery/low_level_discovery/examples/snmp_oids_walk).
Доступны аналогичные параметры форматирования значений, как и в шаге *SNMP walk value*.
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| | |*SNMP get value*|Примените параметры форматирования к значению SNMP get:
**UTF-8 from Hex-STRING** - преобразовать Hex-STRING в строку UTF-8;
**MAC from Hex-STRING** - преобразовать Hex-STRING в строку MAC-адреса (при этом `' '` будет заменено на `':'`);
**Integer from BITS** - преобразовать первые 8 байт битовой строки, представленной последовательностью шестнадцатеричных символов (например, "1A 2B 3C 4D"), в 64-битное беззнаковое целое. В битовых строках длиннее 8 байт последующие байты будут проигнорированы.
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| |Custom scripts|<|<| |<|*JavaScript*|Введите код JavaScript в модальном редакторе, который открывается при щелчке в поле параметра или по значку карандаша рядом с ним.
Обратите внимание, что доступная длина JavaScript зависит от используемой [базы данных](/manual/config/items/item#custom-script-limit).
Дополнительные сведения см. в разделе: [Предобработка Javascript](/manual/config/items/preprocessing/javascript)| |Validation|<|<| |<|*Does not match regular expression*|Укажите регулярное выражение, которому значение не должно соответствовать.
Например, `Error:(.*?)\.`
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| |^|*Check for error in JSON*|Проверьте наличие сообщения об ошибке уровня приложения, расположенного по JSONPath. Остановите обработку, если проверка выполнена успешно и сообщение не пустое; в противном случае продолжите обработку со значением, которое было до этого шага предобработки. Обратите внимание, что ошибки внешнего сервиса сообщаются пользователю как есть, без добавления информации о шаге предобработки.
Например, `$.errors`. Если получен JSON вида `{"errors":"e1"}`, следующий шаг предобработки выполняться не будет.
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| |^|*Check for error in XML*|Проверьте наличие сообщения об ошибке уровня приложения, расположенного по Xpath. Остановите обработку, если проверка выполнена успешно и сообщение не пустое; в противном случае продолжите обработку со значением, которое было до этого шага предобработки. Обратите внимание, что ошибки внешнего сервиса сообщаются пользователю как есть, без добавления информации о шаге предобработки.
Ошибка не будет сообщена в случае неудачного разбора некорректного XML.
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| |<|*Matches regular expression*|Укажите регулярное выражение, которому значение должно соответствовать.
Если установить флажок *Custom on fail*, можно указать пользовательские параметры обработки ошибки: либо отбросить значение, либо задать указанное значение, либо задать указанное сообщение об ошибке.| |Throttling|<|<| |<|*Discard unchanged with heartbeat*|Отбрасывайте значение, если оно не изменилось в течение заданного периода времени (в секундах).
Поддерживаются положительные целые значения секунд (минимум - 1 секунда). В этом поле можно использовать суффиксы времени (например, 30s, 1m, 2h, 1d). В этом поле можно использовать пользовательские макросы и макросы обнаружения на низком уровне.
Для элемента обнаружения можно указать только один параметр ограничения частоты.
Например, `1m`. Если одинаковый текст будет передан в это правило дважды в течение 60 секунд, он будет отброшен.
*Note*: Изменение прототипов элементов не сбрасывает ограничение частоты. Ограничение частоты сбрасывается только при изменении шагов предобработки.| |Prometheus|<|<| |<|*Prometheus to JSON*|Преобразуйте требуемые метрики Prometheus в JSON.
Подробнее см. в разделе [Проверки Prometheus](/manual/config/items/itemtypes/http/prometheus).| Обратите внимание: если правило обнаружения было применено к узлу сети через шаблон, содержимое этой вкладки доступно только для чтения. [comment]: # ({/2e8e1698-0e438e85}) [comment]: # ({e23af783-c5db0ca2}) #### Настраиваемые макросы Вкладка **LLD макросы (LLD macros)** позволяет указать настраиваемые макросы низкоуровневого обнаружения. Настраиваемые макросы полезны в случаях, когда возвращаемый JSON не имеет нужных макросов, уже определённых должным образом. Так, например: - Встроенный ключ `vfs.fs.discovery` для обнаружения файловых систем возвращает JSON с некоторыми уже определёнными LLD макросами, такими как {\#FSNAME} и {\#FSTYPE}. Эти макросы могут быть непосредственно использованы в прототипах элементов данных и триггеров (смотрите последующие разделы на этой странице); определение настраиваемых макросов не требуется; - Элемент данных агента `vfs.fs.get` также возвращает JSON с [данными о файловой системе](/manual/discovery/low_level_discovery/examples/mounted_filesystems), однако, без готовых LLD макросов. В этом случае вы можете определить эти макросы самостоятельно, и выставить соответствие между ними и значениями в JSON-е, используя JSONPath: ![](../../../assets/en/manual/discovery/low_level_discovery/lld_fs_c.png) Извлечённые значения могут использоваться в обнаруженных элементах данных, триггерах и т.п. Обратите внимание, что значения будут извлекаться из результата обнаружения после выполнения шагов предобработки. |Параметр|Описание| |--|--------| |*LLD макрос*
*(LLD macro)*|Имя макроса низкоуровневого обнаружения, с использованием следующего синтаксиса: {\#MACRO}.| |*JSONPath*|Путь, используемый для извлечения значения LLD макроса из строки LLD, используя синтаксис JSONPath.
Значения, извлекаемые из возвращаемого JSON-а, используются для замены LLD макросов в полях прототипов элемента данных, триггера и т.п.
JSONPath может быть указан, используя нотацию с точкой или с квадратными скобками. Нотация с квадратными скобками должна использоваться в случаях использования любых специальных символов и символов Unicode, наподобие следующего: `$['unicode + special chars #1']['unicode + special chars #2']`.

Например, `$.foo` извлечёт «bar» и «baz» из такого JSON-а: `[{"foo":"bar"}, {"foo":"baz"}]`
Обратите внимание, что `$.foo` также извлечёт «bar» и «baz» из такого JSON-а: `{"data":[{"foo":"bar"}, {"foo":"baz"}]}` из-за того, что одиночный объект "data" обрабатывается автоматически (для [обратной совместимости](#обзор) с реализацией низкоуровневого обнаружения в версиях Zabbix до 4.2).| [comment]: # ({/e23af783-c5db0ca2}) [comment]: # ({db7ca1d0-db0f5889}) #### Фильтр Фильтры могут использоваться для того, чтобы генерировать реальные элементы данных, триггеры и графики только для объектов, соответствующих неким критериям. Вкладка **Фильтры (Filters)** содержит определения правил фильтрации обнаружения, позволяющих фильтровать обнаруженные значения: ![](../../../assets/en/manual/discovery/low_level_discovery/lld_fs_d.png){width="600"} |Параметр|Описание| |--|--------| |*Тип вычисления*
*(Type of calculation)*|Доступны следующие опции расчёта фильтров:
**И (And)** — должны выполниться все фильтры;
**Или (Or)** — достаточно выполнения одного фильтра;
**И/Или (And/Or)** — используется *И* для разных имён макросов и *Или* для одинаковых имён макросов;
**Пользовательское выражение (Custom expression)** — появляется возможность указать пользовательское вычисление фильтров. Формула должна включать в себя все фильтры из списка. Ограничено 255 символами.| |*Фильтры*
*(Filters)*|Доступны следующие операторы условий фильтра: *совпадает*, *не соответствует*, *существует*, *не существует* (*matches*, *does not match*, *exists*, *does not exist*).
Операторы *совпадает* и *не соответствует* ожидают [Perl Compatible Regular Expression](https://ru.wikipedia.org/wiki/PCRE) (PCRE). Например, если вы заинтересованы только в файловых системах C:, D: и E:, вы можете поместить {\#FSNAME} в текстовое поле «Макрос», а регулярное выражение «\^C\|\^D\|\^E» — в поле «Регулярное выражение». Фильтрация также возможна по типам файловых систем, при использовании макроса {\#FSTYPE} (например, «\^ext\|\^reiserfs») и по типу диска (поддерживается только Windows агентами), используя макрос {\#FSDRIVETYPE} (например, «fixed»).
В поле «Регулярное выражение» вы можете ввести регулярное выражение или ссылку на глобальное [регулярное выражение](/manual/regular_expressions).
Для проверки регулярного выражения вы можете использовать «grep -E», например: ````for f in ext2 nfs reiserfs smbfs; do echo $f | grep -E '^ext|^reiserfs' || echo "SKIP: $f"; done````

Операторы *существует* и *не существует* позволяют фильтровать объекты на основе присутствия или отсутствия указанных LLD макросов в ответе.

Обратите внимание, что если какой-то макрос из фильтра пропущен в ответе, найденный объект будет игнорироваться, если только для этого макроса не задано условие «не существует».

Если отсутствие макроса влияет на результат выражения, то будет отображено предупреждение. Например, если {#B} отсутствует в:
{#A} совпадает 1 и {#B} совпадает 2 — выдаст предупреждение
{#A} совпадает 1 или {#B} совпадает 2 — предупреждения не будет.| ::: notewarning Ошибка или опечатка в регулярном выражении, которое используется в LLD правиле (например, некорректное регулярное выражение «File systems for discovery»), может привести к удалению тысяч элементов конфигурации, данных истории и событий на большом количестве узлов сети. ::: ::: noteimportant Если имена файловых систем различаются только по регистру, то для корректной работы обнаружения необходимо, чтобы база данных Zabbix в MySQL была создана чувствительной к регистру. ::: [comment]: # ({/db7ca1d0-db0f5889}) [comment]: # ({59797b5c-8d616544}) #### Переопределение Вкладка **Overrides** позволяет задавать правила для изменения списка прототипов элемента данных, триггера, графика, узла сети и обнаружения или их атрибутов для обнаруженных объектов, которые соответствуют заданным критериям. ![](../../../assets/en/manual/discovery/low_level_discovery/lld_fs_e.png) Переопределения (если есть) отображаются в виде списка с возможностью изменения порядка перетаскиванием и выполняются в том порядке, в котором они определены. Чтобы настроить параметры нового переопределения, нажмите ![](../../../assets/en/manual/config/add_link.png) в блоке *Overrides*. Чтобы изменить существующее переопределение, нажмите на его имя. Откроется всплывающее окно, в котором можно изменить параметры правила переопределения. ![](../../../assets/en/manual/discovery/low_level_discovery/lld_override.png) Все обязательные параметры отмечены красными звездочками. |Parameter|Description| |--|--------| |*Name*|Уникальное имя переопределения (в пределах одного правила LLD).| |*If filter matches*|Определяет, будут ли обрабатываться следующие переопределения, если условия фильтра выполнены:
**Continue overrides** - последующие переопределения будут обработаны.
**Stop processing** - будут выполнены операции из предыдущих (если есть) и этого переопределения, последующие переопределения будут проигнорированы для совпавших строк LLD.| |*Filters*|Определяет, к каким обнаруженным сущностям должно применяться переопределение. Фильтры переопределения обрабатываются после [фильтров](low_level_discovery#filter) правила обнаружения и имеют ту же функциональность.| |*Operations*|Операции переопределения отображаются со следующими сведениями:
**Condition** - тип объекта и условие, которое должно быть выполнено для имени объекта; например: прототип триггера не равен *Disk space is low (used > 50%)*.
**Actions** - отображаются ссылки для редактирования и удаления операции.| **Настройка операции** Чтобы настроить параметры новой операции, нажмите ![](../../../assets/en/manual/config/add_link.png) в блоке Operations. Чтобы изменить существующую операцию, нажмите ![](../../../assets/en/manual/config/edit_link.png) рядом с операцией. Откроется всплывающее окно, в котором можно изменить параметры операции. ![](../../../assets/en/manual/discovery/low_level_discovery/lld_override_op.png) |Parameter|<|<|Description| |-|-|----------|----------------------------------------| |*Object*|<|<|Доступны пять типов объектов:
Прототип элемента данных
Прототип триггера
Прототип графика
Прототип узла сети
Прототип обнаружения| |*Condition*|<|<|Позволяет фильтровать сущности, к которым должна применяться операция.| | |Operator|<|Поддерживаемые операторы:
**equals** - применить к этому прототипу
**does not equal** - применить ко всем прототипам, кроме этого
**contains** - применить, если имя прототипа содержит эту строку
**does not contain** - применить, если имя прототипа не содержит эту строку
**matches** - применить, если имя прототипа соответствует регулярному выражению
**does not match** - применить, если имя прототипа не соответствует регулярному выражению
| |^|Pattern|<|Регулярное выражение [regular expression](/manual/regular_expressions) или строка для поиска.| |^|Object: *Item prototype*|<|<| |^| |*Create enabled*|Когда флажок установлен, появятся кнопки, позволяющие переопределить исходные настройки прототипа элемента данных:
*Yes* - элемент данных будет добавлен в включенном состоянии.
*No* - элемент данных будет добавлен к обнаруженной сущности, но в отключенном состоянии.| |^|^|*Discover*|Когда флажок установлен, появятся кнопки, позволяющие переопределить исходные настройки прототипа элемента данных:
*Yes* - элемент данных будет добавлен.
*No* - элемент данных не будет добавлен.| |^|^|*Update interval*|Когда флажок установлен, появятся два параметра, позволяющие задать другой интервал для элемента данных:
*Delay* - интервал обновления элемента данных. Поддерживаются [user macros](/manual/config/macros/user_macros) и [time suffixes](/manual/appendix/suffixes) (например, 30s, 1m, 2h, 1d). Если используется *Custom interval*, следует установить значение 0.
*Custom interval* - нажмите ![](../../../assets/en/manual/config/add_link.png), чтобы указать гибкие интервалы или интервалы по расписанию. Подробности см. в разделе [Custom intervals](/manual/config/items/item/custom_intervals).| |^|^|*History*|Когда флажок установлен, появятся кнопки, позволяющие задать другой период хранения истории для элемента данных:
*Do not store* - если выбрано, история не будет храниться.
*Store up to* - если выбрано, справа появится поле для ввода периода хранения. Поддерживаются [user macros](/manual/config/macros/user_macros) и [LLD macros](/manual/config/macros/lld_macros).| |^|^|*Trends*|Когда флажок установлен, появятся кнопки, позволяющие задать другой период хранения трендов для элемента данных:
*Do not store* - если выбрано, тренды не будут храниться.
*Store up to* - если выбрано, справа появится поле для ввода периода хранения. Поддерживаются [user macros](/manual/config/macros/user_macros) и [LLD macros](/manual/config/macros/lld_macros).| |^|^|*Tags*|Когда флажок установлен, появится новый блок, позволяющий указать пары тег-значение.
Эти теги будут добавлены к тегам, указанным в прототипе элемента данных, даже если имена тегов совпадают.| |^|Object: *Trigger prototype*|<|<| |^| |*Create enabled*|Когда флажок установлен, появятся кнопки, позволяющие переопределить исходные настройки прототипа триггера:
*Yes* - триггер будет добавлен в включенном состоянии.
*No* - триггер будет добавлен к обнаруженной сущности, но в отключенном состоянии.| |^|^|*Discover*|Когда флажок установлен, появятся кнопки, позволяющие переопределить исходные настройки прототипа триггера:
*Yes* - триггер будет добавлен.
*No* - триггер не будет добавлен.| |^|^|*Severity*|Когда флажок установлен, появятся кнопки уровня серьезности триггера, позволяющие изменить серьезность триггера.| |^|^|*Tags*|Когда флажок установлен, появится новый блок, позволяющий указать пары тег-значение.
Эти теги будут добавлены к тегам, указанным в прототипе триггера, даже если имена тегов совпадают.| |^|Object: *Graph prototype*|<|<| |^| |*Discover*|Когда флажок установлен, появятся кнопки, позволяющие переопределить исходные настройки прототипа графика:
*Yes* - график будет добавлен.
*No* - график не будет добавлен.| |^|Object: *Host prototype*|<|<| |^| |*Create enabled*|Когда флажок установлен, появятся кнопки, позволяющие переопределить исходные настройки прототипа узла сети:
*Yes* - узел сети будет создан в включенном состоянии.
*No* - узел сети будет создан в отключенном состоянии.| |^|^|*Discover*|Когда флажок установлен, появятся кнопки, позволяющие переопределить исходные настройки прототипа узла сети:
*Yes* - узел сети будет обнаружен.
*No* - узел сети не будет обнаружен.| |^|^|*Link templates*|Когда флажок установлен, появится поле для ввода шаблонов. Начните вводить имя шаблона или нажмите *Select* рядом с полем и выберите шаблоны из списка во всплывающем окне.
Шаблоны из этого переопределения добавляются ко всем шаблонам, уже связанным с прототипом узла сети.| |^|^|*Tags*|Когда флажок установлен, появится новый блок, позволяющий указать пары тег-значение.
Эти теги будут добавлены к тегам, указанным в прототипе узла сети, даже если имена тегов совпадают.| |^|^|*Host inventory*|Когда флажок установлен, появятся кнопки, позволяющие выбрать другой [mode](/manual/config/hosts/inventory) инвентаризации для прототипа узла сети:
*Disabled* - не заполнять инвентаризацию узла сети
*Manual* - указать сведения вручную
*Automated* - автоматически заполнить данные инвентаризации узла сети на основе собранных метрик.| [comment]: # ({/59797b5c-8d616544}) [comment]: # ({3688758a-50cefaf6}) #### Кнопки диалога Кнопки в нижней части диалога позволяют выполнить несколько видов операций. | | | |--|--------| |![](../../../assets/en/manual/config/button_add.png) (Добавить)|Добавление правила обнаружения. Эта кнопка доступна только для новых правил обнаружения.| |![](../../../assets/en/manual/config/button_update.png) (Обновить)|Обновление свойств правила обнаружения. Эта кнопка доступна только для уже существующих правил обнаружения.| |![](../../../assets/en/manual/config/button_clone.png) (Клонировать)|Создание другого правила обнаружения на основе свойств текущего правила обнанужения.| |![](../../../assets/en/manual/config/button_execute.png) (Выполнить сейчас)|Выполнение немедленного обнаружения на основе правила обнаружения. Правило обнаружения должно существовать. Смотрите [более подробную](/manual/config/items/check_now) информацию.
*Обратите внимание*, что когда обнаружение выполняется немедленно, кэш конфигурации не обновляется, поэтому на результат не повлияют совсем недавние изменения настроек правила обнаружения.| |![](../../../assets/en/manual/config/button_test.png) (Тест)|Протестировать настройки правила обнаружения. Используйте эту кнопку для проверки настроек конфигурации (таких как подключение и корректность параметров) без постоянного применения каких-либо изменений.| |![](../../../assets/en/manual/config/button_delete.png) (Удалить)|Удаление правила обнаружения| |![](../../../assets/en/manual/config/button_cancel.png) (Отмена)|Отмена изменения свойств правила обнаружения.| [comment]: # ({/3688758a-50cefaf6}) [comment]: # ({5721dd55-0dea10fa}) ### Обнаруженные объекты Представленные ниже снимки экрана иллюстрируют, как выглядят уже обнаруженные элементы данных, триггеры и графики в настройках узла сети. Обнаруженные объекты имеют префикс — ссылку золотистого цвета, которая ведёт к правилу обнаружения, создавшему эти объекты. ![](../../../assets/en/manual/discovery/low_level_discovery/discovered_items1.png){width="600"} Обратите внимание, что обнаруженные объекты не будут созданы в случае, если объекты с такими же условиями уникальности уже существуют — например, элемент данных с таким же ключом или график с таким же именем. В таком случае в веб-интерфейсе отобразится сообщение об ошибке, что правило низкоуровневого обнаружения не смогло создать определённые объекты. Само правило обнаружения, тем не менее, не станет неподдерживаемым из-за того, что некоторые объекты не смогли быть созданы и были пропущены. Правило обнаружения перейдёт к созданию/обновлению других объектов. Если обнаруженный объект (узел сети, файловая система, интерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр), то объекты, созданные на его основе, могут быть автоматически деактивированы и впоследствии удалены. Потерянные ресурсы могут быть автоматически деактивированы на основе значения параметра *Удаление потерянных ресурсов (Delete lost resources)*. Это влияет на потерянные узлы сети, группы узлов сети, элементы данных, триггеры и графики. Потерянные ресурсы могут быть автоматически удалены на основе значения параметра *Деактивация потерянных ресурсов (Disable lost resources)*. Это влияет на потерянные узлы сети, элементы данных и триггеры. Когда обнаруженный объект становится «Более не обнаруживается», в списке элементов данных будет отображаться оранжевый индикатор времени жизни. Переместите курсор мыши на этот индикатор, и вы увидите сообщение с количеством дней до момента удаления элемента данных. ![](../../../assets/en/manual/discovery/low_level_discovery/not_discovered_message.png) Если объекты помечены на удаление, но не были удалены в назначенное время (деактивировано правило обнаружения или узел сети элемента данных), они удалятся при следующем выполнении правила обнаружения. Объекты, которые содержат другие объекты, которые помечены на удаление, не будут обновлены, если будут изменены на уровне правила обнаружения. Например, триггеры на основе LLD не будут обновлены, если они содержат элементы данных, которые помечены на удаление. ![](../../../assets/en/manual/discovery/low_level_discovery/discovered_triggers1.png) ![](../../../assets/en/manual/discovery/low_level_discovery/discovered_graphs1.png){width="600"} [comment]: # ({/5721dd55-0dea10fa}) [comment]: # ({ea9a0925-ab744aed}) ### Другие типы обнаружения Для получения более подробных сведений и инструкций по остальным типам доступных «из коробки» обнаружений смотрите следующие разделы: - обнаружение [сетевых интерфейсов](/manual/discovery/low_level_discovery/examples/network_interfaces); - обнаружение [CPU и ядер CPU](/manual/discovery/low_level_discovery/examples/cpu); - обнаружение [SNMP OID-ов](/manual/discovery/low_level_discovery/examples/snmp_oids); - обнаружение [объектов JMX](/manual/discovery/low_level_discovery/examples/jmx); - обнаружение с использованием [запросов ODBC SQL](/manual/discovery/low_level_discovery/examples/sql_queries); - обнаружение [служб Windows](/manual/discovery/low_level_discovery/examples/windows_services); - обнаружение [интерфейсов узлов сети](/manual/discovery/low_level_discovery/examples/host_interfaces) в Zabbix. Для получения более подробных сведений касательно JSON формата по обнаружению элементов данных и примера, каким образом реализовать своё собственное обнаружение файловых систем при помощи Perl скрипта, смотрите [создание пользовательских правил LLD](/manual/discovery/low_level_discovery/custom_rules). [comment]: # ({/ea9a0925-ab744aed})