ru: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
ru:manual:discovery:low_level_discovery [2016/01/12 20:15]
dotneft
ru:manual:discovery:low_level_discovery [2020/08/05 09:02] (current)
marinagen CSV to JSON link updated
Line 1: Line 1:
-==== - #3 Низкоуровневое обнаружение ====+==== 3 Низкоуровневое обнаружение ====
 === Обзор ===  === Обзор === 
  
 Низкоуровневое обнаружение (LLD) даёт возможность автоматического создания элементов данных,​ триггеров и графиков для различных объектов на компьютере. Например,​ Zabbix может автоматически начать мониторить файловые системы или сетевые интерфейсы с вашего устройства,​ без необходимости создания вручную элементов данных для каждой файловой системы или сетевого интерфейса. Кроме того, в Zabbix имеется возможность настроить удаление ненужных объектов,​ основываясь на фактических результатах периодически выполняемого обнаружения. Низкоуровневое обнаружение (LLD) даёт возможность автоматического создания элементов данных,​ триггеров и графиков для различных объектов на компьютере. Например,​ Zabbix может автоматически начать мониторить файловые системы или сетевые интерфейсы с вашего устройства,​ без необходимости создания вручную элементов данных для каждой файловой системы или сетевого интерфейса. Кроме того, в Zabbix имеется возможность настроить удаление ненужных объектов,​ основываясь на фактических результатах периодически выполняемого обнаружения.
- 
-В Zabbix поддерживаются три встроенных типа элементов данных для обнаружения:​ 
- 
-  * обнаружение файловых систем;​ 
-  * обнаружение сетевых интерфейсов;​ 
-  * обнаружение CPU и ядер CPU; 
-  * обнаружение SNMP OID'​ов;​ 
-  * обнаружение с использованием SQL запросов ODBC; 
-  * обнаружение Windows служб. 
  
 Пользователь имеет возможность определить свои собственные типы обнаружения,​ обеспечив их функционирование согласно спецификации JSON протокола. Пользователь имеет возможность определить свои собственные типы обнаружения,​ обеспечив их функционирование согласно спецификации JSON протокола.
Line 21: Line 12:
 Элемент данных,​ который осуществляет обнаружение необходимых объектов,​ подобен обычным элементам данных,​ которые видны в других местах:​ Zabbix сервер запрашивает у Zabbix агента (или любой другой указанный тип элемента данных) значение этого элемента данных,​ и агент отвечает текстовым значением. Разница в том, что значение,​ которое возвращает агент, должно содержать список обнаруженных объектов в специальном JSON формате. Хотя детали этого формата важны только для создателей собственных проверок обнаружения,​ всё же всем необходимо знать, что возвращаемое значение содержит список из пар: макрос -> значение. Например,​ элемент данных "​net.if.discovery"​ может вернуть две пары: "​{#​IFNAME}"​ -> "​lo"​ и "​{#​IFNAME}"​ -> "​eth0"​. Элемент данных,​ который осуществляет обнаружение необходимых объектов,​ подобен обычным элементам данных,​ которые видны в других местах:​ Zabbix сервер запрашивает у Zabbix агента (или любой другой указанный тип элемента данных) значение этого элемента данных,​ и агент отвечает текстовым значением. Разница в том, что значение,​ которое возвращает агент, должно содержать список обнаруженных объектов в специальном JSON формате. Хотя детали этого формата важны только для создателей собственных проверок обнаружения,​ всё же всем необходимо знать, что возвращаемое значение содержит список из пар: макрос -> значение. Например,​ элемент данных "​net.if.discovery"​ может вернуть две пары: "​{#​IFNAME}"​ -> "​lo"​ и "​{#​IFNAME}"​ -> "​eth0"​.
  
-<​note>​Элементы данных низкоуровневого обнаружения - vfs.fs.discovery,​ net.if.discovery ​поддерживаются ​Zabbix агентом начиная с версии 2.0.\\ Элемент данных ​низкоуровневого обнаружения "​system.cpu.discovery"​ поддерживается Zabbix агентом начиная с версии 2.4.\\ Обнаружение SNMP OID'ов поддерживается Zabbix сервером и прокси начиная с версии 2.0.\\ Обнаружение с использованием SQL запросов ​ODBC поддерживается Zabbix сервером и прокси ​начиная с версии 3.0.</​note>​+Эти макросы затем используются ​в именах, ключах и в других полях прототипов, которые являются ​основой для создания ​реальных элементов данных, триггеров ​и графиков каждому обнаруженному объекту. Смотрите полный ​список [[:​ru/​manual/​config/​macros/​lld_macros|опций]] по использованию макросов ​в низкоуровневом обнаружении.
  
-<​note>​Zabbix прокси на IBM DB2 базе данных имеет ограничение ​в 2048 байт на возвращаемое значение ​правил низкоуровневого обнаружения. Это ограничение не распространяется на Zabbix ​сервертак как возвращаемые значения обрабатываются без предварительной записи в базу данных.</​note>​+Когда ​сервер получает значение элемента ​данных ​обнаружения, он смотрит на пару макрос -> значение ​и для каждой пары создает реальные элементы данных, триггеров и графиковоснованных на их прототипах. В приведенном выше примере с "​net.if.discovery", ​сервер ​будет создавать один набор элементов данных, триггеров и графиков для локального интерфейса "​lo"​ и другой набор для ​интерфейса ​"​eth0"​.
  
-Эти макросы затем используются в именахключах и в других полях прототипов, которые являются основой для создания реальных элементов данных, триггеров и графиков ​каждому обнаруженному объекту. Смотрите полный ​список [[:​ru/​manual/​appendix/​macros/​supported_by_location#​макросы_используемые_в_низкоуровневых_обнаружениях|опций]] по использованию макросов в низкоуровневом обнаружении.+Обратите внимание, что начиная с **Zabbix 4.2**, формат JSON, возвращаемый правилами ​низкоуровневого обнаружения, был изменен. Больше не ожидаетсячто JSON будет содержать объект %%"​%%data%%"​%%. Низкоуровневое обнаружение теперь будет принимать обычный ​JSON, содержащий ​массив, чтобы ​поддерживать новые функции, такие как предобработка значения ​элемента данных и пользовательские пути к макросам низкоуровневого обнаружения в документе JSON.
  
-Когда ​сервер получает значение элемента данных ​обнаруженияон смотрит на пару макрос ​-> значение и для каждой пары создает реальные элементы данных, триггеров и графиков, основанных на их прототипах. В приведенном выше примере с "​net.if.discovery",​ сервер будет создавать один набор элементов ​данных,​ триггеров и графиков для локального ​интерфейса "​lo"​ и другой ​набор для ​интерфейса "​eth0"​.+Встроенные ключи ​обнаружения ​были ​обновлены, чтобы возвращать массив строк LLD в корне документа JSON. Zabbix ​автоматически извлечет ​макрос ​и значение, если поле массива использует синтаксис {#MACRO} в качестве ключа. Любые ​новые нативные проверки обнаружения ​будут использовать ​новый синтаксис ​без элементов ​%%"​%%data%%"​%%. При обработке значения низкоуровневого ​обнаружения сначала ​определяется корень (массив в «$.» Или «$.data»).
  
-Следующий раздел иллюстрирует весь процесс, описанный выше, в деталях и служит руководством, как осуществлять все упомянутые выше типы обнаружений. Последний раздел ​описывает формат JSON элементов ​данных ​обнаружения и дает пример того, как реализовать ​ваш собственный скрипт для обнаружения файловых ​систем, ​используя Perl скрипт.+Хотя элемент %%"​%%data%%"​%% был ​удален из всех родных элементов данных, связанных с обнаружением, для ​обеспечения обратной совместимости Zabbix по-прежнему будет принимать нотацию JSON с элементом %%"​%%data%%"​%%,​ хотя его использование не рекомендуется. Если JSON содержит объект только с одним элементом массива %%"​%%data%%"​%%,​ то он автоматически извлечет содержимое элемента, используя JSONPath ''​$.data''​. Низкоуровневое ​обнаружение теперь принимает необязательные пользовательские макросы ​LLD с пользовательским путем, указанным в синтаксисе JSONPath.
  
-=== - Обнаружение ​файловых систем ​===+<note warning> В результате вышеуказанных ​изменений более новые агенты больше не смогут работать со старым Zabbix-сервером. </​note>​ 
 +См. также: [[#​обнаруженные_объекты|Обнаруженные объекты]]
  
-Для настройки обнаружения ​файловых систем,​ сделайте следующее:​+=== Настройка низкоуровневого ​обнаружения ​===
  
-  ​* Перейдите в: //​Настройки// -> //​Шаблоны// ​  +Мы проиллюстрируем низкоуровневое обнаружение на примере обнаружения файловых систем. 
-  * Нажмите на //​Обнаружение//​ в строке соответствующего ​шаблона+ 
 +Для настройки обнаружения,​ выполните следующее:​ 
 + 
 +  ​* Перейдите в: //​Настройка// -> //​Шаблоны//​  
 +  * Нажмите на //​Обнаружение//​ в строке ​с соответствующим шаблоном
  
 {{manual:​discovery:​low_level_discovery:​fs_templates.png|}} {{manual:​discovery:​low_level_discovery:​fs_templates.png|}}
  
   * Нажмите на //​Создать правило обнаружения//​ в верхнем правом углу экрана   * Нажмите на //​Создать правило обнаружения//​ в верхнем правом углу экрана
-  * Заполните диалог ​следующими деталями+  * Заполните диалог ​правила обнаружения необходимыми деталями 
 + 
 +=== Правило обнаружения === 
 + 
 +Форма правила обнаружения содержит пять вкладок,​ представляющих, слева направо,​ поток данных во время обнаружения: 
 + 
 +  * Правило обнаружения - указывает,​ что наиболее важно: встроенный элемент или пользовательский сценарий ​для извлечения данных обнаружения 
 +  * Предварительная обработка - применяет некоторую предварительную обработку к обнаруженным данным 
 +  * Макросы LLD - позволяют извлечь некоторые значения макросов для ​использования в обнаруженных элементах,​ триггерах и т. д. 
 +  * Фильтры - позволяет фильтровать обнаруженные значения 
 +  * Переопределения - позволяет изменять элементы,​ триггеры,​ графики или прототипы хоста при применении к определенным обнаруженным объектам.
  
 Вкладка **Правило обнаружения** содержит общие атрибуты правила обнаружения:​ Вкладка **Правило обнаружения** содержит общие атрибуты правила обнаружения:​
  
-{{manual:​discovery:​low_level_discovery:​lld_rule_fs.png|}}+{{:manual:​discovery:​low_level_discovery:​lld_rule_fs0a.png?600|}} 
 + 
 +Все обязательные поля ввода отмечены красной звёздочкой.
  
 ^Параметр^Описание^ ​ ^Параметр^Описание^ ​
 |//​Имя// ​ |Имя правила обнаружения. ​ |  |//​Имя// ​ |Имя правила обнаружения. ​ | 
-|//​Тип// ​ |Тип проверки выполняемого обнаружения; должен быть //Zabbix агент// или //Zabbix агент ​(активный)//​ при обнаружении файловых систем.  |  +|//​Тип// ​ |Тип проверки выполняемого обнаружения. \\ В этом примере мы используем ключ элемента данных ​Zabbix агента. Правило обнаружения также может быть [[:ru/manual/config/items/itemtypes/​dependent_items|зависимым элементом данных]], зависящим от обычного элемента ​данных (но не от другого правила обнаружения).  Для зависимого элемента данных выберите соответствующий тип (Зависимый элемент данных) и укажите ​основной элемент в поле «Основной элемент ​даных». Основной элемент должен существовать.  |  
-|//Ключ//  |Элемент данных ​"​vfs.fs.discovery"​ уже ​встроен в Zabbix агент ​на многих платформах (для получения ​более ​детальных ​сведений смотрите ​[[ru:​manual:​appendix:​items:​supported_by_platform|список поддерживаемых ​ключей элементов данных]]), который возвращает список файловых систем, ​присутствующих ​в компьютере,​ и их типы в формате ​JSON |  +|//​Ключ// ​ |Введите ключ элемента обнаружения (до 2048 символов). \\ Напримервы можете использовать встроенный ключ элемента «vfs.fs.discovery» для ​возврата JSON со списком файловых систем,​ имеющихся на компьютере,​ и их типами. \\ Обратите ​внимание,​ что другой опцией для обнаружения ​файловой системы является использование ​результатов обнаружения ключом агента «vfs.fs.get»,​ поддерживаемым начиная с Zabbix 4.4.5 (см. [[:​manual/​discovery/​low_level_discovery/​mounted_filesystems|пример]]) ​|  
-|//​Интервал обновления ​(в сек)//  |Этот фильтр ​задает как часто Zabbix выполняет обнаружение. В начале,​ когда вы только настраиваете обнаружение файловых систем,​ вы можете указать маленький интервал,​ но как только вы удостоверитесь что всё работает,​ вы можете установить его в 30 минут или более, потому что обычно файловые системы не меняются очень часто.\\ //​Обратите внимание//:​ Если укажите значение равное '​0',​ элемент данных не будет обрабатываться. Однако,​ если также существует переменный интервал с ненулевым значением,​ элемент данных будет обрабатываться в течении действия переменного интервала. ​ | +|//​Интервал обновления// ​ |Это ​поле задает как часто Zabbix выполняет обнаружение. В начале,​ когда вы только настраиваете обнаружение файловых систем,​ вы можете указать маленький интервал,​ но как только вы удостоверитесь что всё работает,​ вы можете установить его в 30 минут или более, потому что обычно файловые системы не меняются очень часто.\\ Поддерживаются [[:​ru/​manual/​appendix/​suffixes|суффиксы времени]],​ например 30s, 1m, 2h, 1d, начиная с Zabbix 3.4.0.\\ [[:​ru/​manual/​config/​macros/​usermacros|Пользовательские макросы]] поддерживаются начиная с Zabbix 3.4.0.\\ //​Обратите внимание//:​ Если укажите значение равное '​0',​ элемент данных не будет обрабатываться. Однако,​ если также существует переменный интервал с ненулевым значением,​ элемент данных будет обрабатываться в течении действия переменного интервала.\\  //​Обратите внимание//,​ что уже созданное правило обнаружение можно выполнить незамедлительно нажатием [[#​кнопки_диалога|кнопки]] //​Проверить сейчас// ​.  | 
 |//​Пользовательские интервалы// ​ |Вы можете создавать пользовательские правила проверки элемента данных:​\\ **Гибкий** - создание исключений из Интервала обновления (интервал с другой частотой обновления)\\ **По расписанию** - создание пользовательского расписания проверки.\\ Для получения более подробной информации смотрите [[ru:​manual:​config:​items:​item:​custom_intervals|Пользовательские интервалы]]. Проверка по расписанию поддерживается начиная с Zabix 3.0.0. ​ |  |//​Пользовательские интервалы// ​ |Вы можете создавать пользовательские правила проверки элемента данных:​\\ **Гибкий** - создание исключений из Интервала обновления (интервал с другой частотой обновления)\\ **По расписанию** - создание пользовательского расписания проверки.\\ Для получения более подробной информации смотрите [[ru:​manual:​config:​items:​item:​custom_intervals|Пользовательские интервалы]]. Проверка по расписанию поддерживается начиная с Zabix 3.0.0. ​ | 
-|//​Период сохранения потерянных ресурсов ​(дней)//  |Это поле позволяет вам указать как много дней обнаруженный объект будет храниться (не будет удален),​ как только его состояние обнаружения станет "Не обнаруживается более"​ (макс ​3650 дней). \\ //​Обратите внимание://​ Если значение равно "​0",​ объекты будут удалены сразу. Использование значения "​0"​ не рекомендуется,​ так как простое ошибочное изменение фильтра может закончится тем, что объект будет удален вместе со всеми данными истории. ​  ​| ​+|//​Период сохранения потерянных ресурсов// ​ |Это поле позволяет вам указать как много дней обнаруженный объект будет храниться (не будет удален),​ как только его состояние обнаружения станет "Не обнаруживается более"​ (мин 1 час, ​макс ​25 лет).\\ Поддерживаются [[:​ru/​manual/​appendix/​suffixes|суффиксы времени]], например 30s, 1m, 2h, 1d, начиная с Zabbix 3.4.0.\\ [[:​ru/​manual/​config/​macros/​usermacros|Пользовательские макросы]] поддерживаются начиная с Zabbix 3.4.0.\\ //​Обратите внимание://​ Если значение равно "​0",​ объекты будут удалены сразу. Использование значения "​0"​ не рекомендуется,​ так как простое ошибочное изменение фильтра может закончится тем, что объект будет удален вместе со всеми данными истории. ​  ​| ​
 |//​Описание// ​ |Введите описание. ​ |  |//​Описание// ​ |Введите описание. ​ | 
 |//​Состояние// ​ |Если отмечено,​ правило будет обрабатываться. | |//​Состояние// ​ |Если отмечено,​ правило будет обрабатываться. |
  
-Вкладка **Фильтры** содержит определения фильтрации правила обнаружения:​ 
- 
-{{manual:​discovery:​low_level_discovery:​lld_rule_fs2.png|}} 
- 
-^Параметр^Описание^ 
-|//Тип вычисления// ​ |Доступны следующие опции расчета фильтров:​\\ **И** - должны выполниться все фильтры;​\\ **Или** - достаточно выполнения одного фильтра;​\\ **И/​Или** - используется //И// для разных имен макросов и //Или// с одинаковым именем макроса;​\\ **Пользовательское выражение** - появляется возможность указать пользовательское вычисление фильтров. Формула должна включать в себя все фильтры из списка.\\ Ограничено 255 символами. ​ | 
-|//​Фильтры// ​ | Фильтр можно использовать только для генерирования реальных элементов данных,​ триггеров и графиков конкретных файловых систем. Ожидается использование [[ru:​manual:​regular_expressions|Расширенные регулярные выражения POSIX]]. Например,​ если вы заинтересованы только в файловых системах C:, D: и E:, вы можете поместить {#FSNAME} в поле "​Макрос"​ и регулярное выражение <​nowiki>"​^C|^D|^E"</​nowiki>​ в текстовые поля "​Регулярное выражение"​. Фильтрация также возможна по типам файловых систем,​ при использовании макроса {#FSTYPE} (например,​ <​nowiki>"​^ext|^reiserfs"</​nowiki>​) и по типу диска (поддерживается только Windows агентов),​ используя макрос {#​FSDRIVETYPE} ​ (например,​ <​nowiki>"​fixed"</​nowiki>​).\\ Вы можете ввести в поле "​Регулярное выражение"​ регулярное выражение или ссылку на глобальное [[ru:​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>​Макрос {#​FSDRIVETYPE} на Windows поддерживается начиная с Zabbix **3.0.0**.\\ Определение нескольких фильтров поддерживается начиная с **2.4.0**.\\ Обратите внимание,​ что если какой-то макрос из фильтра пропущен в ответе,​ найденный объект будет игнорироваться. ​ | 
- 
-<note important>​База данных Zabbix в MySQL должна быть создана чувствительной к регистру,​ если имена файловых систем различаются только по регистру,​ чтобы обнаружение сработало корректно.</​note>​ 
-  
 <​note>​История правил обнаружения не сохраняется.</​note>​ <​note>​История правил обнаружения не сохраняется.</​note>​
  
-Как только правило будет создано, перейдем к элементам данных этого правила и нажмем "​Создать прототип",​ чтобы создать прототип элементов данных. Обратите внимание на то, как используется макрос {#FSNAME}, где требуется указать имя файловой системы. Когда правило будет обрабатываться,​ этот макрос будет заменен обнаруженной файловой системой.+== Предобработка ​==
  
-{{manual:​discovery:​low_level_discovery:​item_prototype_fs.png|}}+Вкладка **Предобработка** позволяет определить правила преобразования,​ применяемые к результату обнаружения. На этом этапе возможно одно или несколько преобразований. Преобразования выполняются в том порядке,​ в котором они определены. Вся предварительная обработка выполняется Zabbix сервером.
  
-<​note>​Если прототип элемента данных создан с состоянием //Деактивирован//,​ то он будет добавлен как обнаруженный объект,​ но в деактивированном состоянии.</​note>​+Смтакже
  
-//Прототип группы элементов данных// является опцией,​ которая указывается в свойствах прототипов элементов данных. В свойствах группы элементов ​данных вы можете использовать макросы низкоуровневого ​обнаружения,​ которые,​ после выполнения обнаружения, ​будут заменены реальными значениями при создании групп элементов данных, ​которые специфичны для обнаруженного объекта. Смотрите также ​[[ru:manual:​discovery:​low_level_discovery:​notes|заметки по обнаружению групп элементов данных]] для получения более подробной информации.+  * [[:ru/manual/config/items/preprocessing/​preprocessing_details|Детали предобработки]] 
 +  * [[:ru/manual/​config/​items/​preprocessing#​testing|Тестирование ​предобработки]]
  
-Мы можем создать несколько прототипов элементов данных для каждой интересующей нас характеристики файловой системы:+{{:manual:​discovery:​low_level_discovery:​lld_rule_fs_2ba.png|}}
  
-{{manual:discovery:low_level_discovery:item_prototypes_fs.png|}}+^Тип^Преобразование^Описание^ 
 +|  ||| 
 +^Текст ​ ^^^ 
 +|   ​|//​Регулярное выражение// ​ | Полученное значение сопоставляется с регулярным выражением <​pattern>​ и заменяется извлеченным <​output>​. Регулярное выражение поддерживает извлечение максимум 10 групп захвата с помощью последовательности \N. \\ Параметры:​ \\ **шаблон** - регулярное выражение \\ **вывод** - шаблон форматирования вывода. Управлящая последовательность \N (где N = 1… 9) заменяется N-нной совпадающей группой. Экранирующая последовательность \0 заменяется соответствующим текстом. \\ Если вы установите флажок //​Другое при ошибке//,​ появится возможность указать пользовательские параметры обработки ошибок:​ либо сбросить значение,​ либо задать указанное значение,​ либо установить указанное сообщение об ошибке. ​ | 
 +|:::​|//​Замена// ​ |Найти строку поиска и заменить ее другой (или пустотой). Все совпадающие строки поиска будут заменены. \\ Параметры:​ \\ **строка поиска** - строка для поиска и замены,​ с учетом регистра (обязательно) \\ **замена** - строка для замены строки поиска. Строка замены также может быть пустой,​ что позволяет эффективно удалять строку поиска при ее обнаружении. \\ Можно использовать управляющие последовательности для поиска или замены разрывов строк, возврата каретки,​ табуляции и пробелов %% "\ n \ r \ t \ s "%%; обратную косую черту можно экранировать как %%"​\\"​%%,​ а управляющие последовательности можно экранировать как %% "​\\n"​ %%. Экранирование разрывов строк, возврата каретки,​ вкладок выполняется автоматически при низкоуровневом обнаружении. \\ Поддерживается с 5.0.0. | 
 +^Составные данные ​ ^^^ 
 +|   ​|//​JSONPath// ​ |Будет извлечено значение или фрагмент из данных JSON с помощью [[:ru/manual/​config/​items/​preprocessing/​jsonpath_functionality|функциональности JSONPath]]. \\ Если вы установите флажок //​Другое при ошибке//,​ элемент не станет неподдерживаемым в случае ошибки этапа предобработки,​ вместо этого появится возможность указать пользовательские параметры обработки ошибоклибо сбросить значение,​ либо задать указанное значение,​ либо задать указанное сообщение об ошибке. ​ | 
 +|   ​|//​XML XPath// ​ |Извлечение значения или фрагмента из XML-данных с использованием функций XPath. \\ Для работы этой опции Zabbix сервер должен быть скомпилирован с поддержкой libxml.\\ Примеры:\\ ''​number(/​document/​item/​value)''​ извлечет ''​10''​ из ''<​document><​item><​value>​10</​value></​item></​document>''​\\ ''​number(/​document/​item/​@attribute)''​ извлечет ''​10''​ из ''<​nowiki><​document><​item attribute="​10"></​item></​document></​nowiki>''​\\ ''/​document/​item''​извлечет ''<​item><​value>​10</​value></​item>''​ из ''<​document><​item><​value>​10</​value></​item></​document>''​\\ Обратите внимание,​ что пространства имен не поддерживаются. \\ Поддерживается начиная с 4.4.0. \\ Если вы установите флажок //​Другое при ошибке//,​ появится возможность указать пользовательские параметры обработки ошибоклибо сбросить значение,​ либо задать указанное значение,​ либо задать указанное сообщение об ошибке  ​| 
 +|   ​|//​CSV в JSON// ​ |Данные файла CSV конвертируются в формат JSON. \\ Для получения дополнительной информации см. : [[:​ru/​manual/​config/​items/​preprocessing/​csv_to_json#​csv_header_processing|Преобразование CSV в JSON]].\\ Поддерживается с 4.4.0. ​ | 
 +^Пользовательские скрипты ​ ^^^ 
 +|   ​|//​JavaScript// ​ |Введите код JavaScript в блок, который появляется при нажатии в поле параметра или на иконку карандаша. \\ Обратите внимание,​ что доступная длина JavaScript зависит от [[:​ru/​manual/​config/​items/​item#​custom_script_limit|используемой базы данных]].\\ Для получения дополнительной информации см. : [[:​manual/​config/​items/​preprocessing/​javascript|Предобработка Javascript]] (страница доступна только на английском языке) ​ | 
 +^Валидация ​ ^^^ 
 +|   ​|//​Не совпадает с регулярным выражением// ​ |Укажите регулярное выражение,​ которому значение не должно соответствовать. \\ Например. ''​%%Error:​(.*?​)\.%%''​ \\ Если вы установите флажок //​Другое при ошибке//,​ этого появится возможность указать пользовательские параметры обработки ошибок:​ либо сбросить значение,​ либо задать указанное значение,​ либо задать указанное сообщение об ошибке. ​  | 
 +|:::​|//​Проверьте на ошибку в JSON// ​ | Проверяется,​ нет ли сообщения об ошибке на уровне приложения в JSONpath. Обработка будет остановлена в случае положительного результата (сообщение присутствует);​ в противном случае обработка будет продолжена со значением,​ подготовленным до этого этапа предварительной обработки. Обратите внимание,​ что эти внешние сервисные ошибки сообщаются пользователю напрямую,​ без добавления информации о шаге предварительной обработки.\\ Например,​ ''​$.errors''​. Если получен JSON-подобный ''​%%{"​errors":"​e1"​}%%'',​ следующий шаг предобработки не будет выполнен.\\ ​ Если вы установите флажок //​Другое при ошибке//,​ этого появится возможность указать пользовательские параметры обработки ошибок:​ либо сбросить значение,​ либо задать указанное значение,​ либо задать указанное сообщение об ошибке. ​  | 
 +|:::​|//​Проверьте на наличие ошибок в XML//  |Проверяется,​ нет ли сообщения об ошибке на уровне приложения в JSONpath. Обработка будет остановлена в случае положительного результата (сообщение присутствует);​ в противном случае обработка будет продолжена со значением,​ подготовленным до этого этапа предварительной обработки. Обратите внимание,​ что эти внешние сервисные ошибки сообщаются пользователю напрямую,​ без добавления информации о шаге предварительной обработки.\\ Например,​ ''​$.errors''​. Если получен JSON-подобный ''​%%{"​errors":"​e1"​}%%'',​ следующий шаг предобработки не будет выполнен.\\ ​ Если вы установите флажок //​Другое при ошибке//,​ этого появится возможность указать пользовательские параметры обработки ошибок:​ либо сбросить значение,​ либо задать указанное значение,​ либо задать указанное сообщение об ошибке. ​ | 
 +^Троттлинг ​ ^^^ 
 +|   ​|//​Отбрасывать не изменившееся с периодическим контролем// ​ |Отбросить зачение,​ если оно не изменилось в течние определенного периода (в секундах).\\ Поддерживаются положительные целые значения для указания секунд (минимум - 1 секунда). В этом поле можно использовать суффиксы времени (например,​ 30 с, 1 м, 2 ч, 1 д). В этом поле можно использовать пользовательские макросы и макросы низкоуровневого обнаружения. \\ Для элемента данных обнаружения можно указать только один параметр троттлинга. \\ Например,​ ''​1m''​. Если идентичный текст будет передан в это правило дважды в течение 60 секунд,​ он будет отброшен. \\ //​Примечание//:​ Изменение прототипов элементов данных не приводит к сбросу троттлинга. Троттлинг сбрасывается только при изменении шагов предварительной обработки. | 
 +^Prometheus ​ ^^^ 
 +|   ​|//​Prometheus в JSON// ​ |Преобразуйте необходимые метрики Prometheus в JSON. \\ См. [[:​manual/​config/​items/​itemtypes/​prometheus|Проверки Prometheus]] (страница доступна только на английском языке) для получения более подробной информации. ​ |
  
-Теперь похожим способом мы создадим ​прототипы триггеров:+Обратите внимание, что если ​правило обнаружения было ​применено к хосту через шаблон, то содержимое этой вкладки доступно только для чтения.
  
-{{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png|}}+== Пользовательские макросы ==
  
-Также вы можете ​задать ​[[:​ru/​manual/​config/​triggers/​dependencies|зависимости]] между ​прототипами триггеров (поддерживается начиная с Zabbix 3.0). Чтобы это сделать, перейдите на вкладку //​Зависимости//​. Прототип триггеров может зависеть от другого прототипа триггеров из этого же правила ​низкоуровневого обнаружения ​(LLD) или от обычного триггера. Прототип триггеров не может зависеть от прототипа триггеров из другого правила LLD и от триггера созданного другим прототипом триггеров. Прототип триггеров узла сети не может зависеть от триггера из шаблона.+На вкладке **LLD макросы ** можно указать пользовательские макросы низкоуровневого обнаружения.
  
-{{manual:discovery:​low_level_discovery:​trigger_prototypes_fs.png|}}+Пользовательские макросы полезны в тех случаях,​ когда возвращаемый JSON не имеет уже определенных макросов,​ которые необходимы. Так, например:
  
-И также прототипы графиков:​+  * Родной ключ ''​vfs.fs.discovery''​ для обнаружения файловой системы возвращает JSON с некоторыми предопределенными макросами LLD, такими как {#FSNAME}, {#FSTYPE}. Эти макросы можно использовать непосредственно в элементах данных, ​прототипах триггеров (см. следующие разделы страницы);​ в этом случае задавать пользовательские макросы не требуется;​ 
 +  * Элемент данных агента ''​[[:​ru/​manual/​discovery/​low_level_discovery/​mounted_filesystems|vfs.fs.get]]''​ также возвращает JSON с данными ​файловой системы, но без ​каких-либо предопределенных макросов LLD. В этом случае вы можете определить макросы самостоятельно и сопоставить их со значениями в JSON, используя JSONPath:
  
-{{manual:​discovery:​low_level_discovery:​graph_prototype_fs.png|}}+{{manual:​discovery:​low_level_discovery:​fs_get_lld_ba.png|}}
  
-{{manual:​discovery:​low_level_discovery:​graph_prototypes_fs.png|}}+Извлеченные значения могут использоваться в обнаруженных элементах,​ триггерах и т. Д. Обратите внимание,​ что значения будут извлечены из результата обнаружения и любых шагов предобработки,​ выполненных до этого момента.
  
-В конце концов, мы создали правило обнаружения, ​которое выглядит как видно ниже. Оно имеет пять прототипов элементов данных, ​два прототипа триггеров и один прототип графика.+^Параметр^Описание
 +|//Макрос LLD//  |Имя макроса низкоуровневого обнаружения, ​используя следующий синтаксис: {#MACRO}. | 
 +|//​JSONPath// ​ |Путь, используемый для извлечения значения макроса LLD из строки LLD с использованием синтаксиса JSONPath. \\ Например,​ ''​$.foo''​ будет извлекать %%"​%%bar%%"​%% и %%"​%%baz%%"​%% из этого JSON: ''​[{%%"​%%foo%%"​%%:​%%"​%%bar%%"​%%},​ {%%"​%%foo%%"​%%:​%%"​%%baz%%"​%%}]''​ \\ Значения, извлеченные из возвращенного JSON, используются для замены макросов LLD в полях прототипов элементов данных, ​триггеров, и т. д. \\ JSONPath можно указать с помощью ​точечной или скобочной нотации. Обозначение в скобках следует ​использовать в случае любых специальных символов и Unicode, например ''​$['​unicode + special chars #​1'​]['​unicode + special chars #​2'​]''​|
  
-{{manual:​discovery:​low_level_discovery:​lld_rules_fs.png|}}+=== Фильтр правила обнаружения ===
  
-//Обратите внимание//: Для получения информации по настройке прототипов узлов сети, смотрите в разделе ​мониторинга виртуальных машин ​о настройке [[:​ru/​manual/​vm_monitoring#​прототипы_узлов_сети|прототипов узлов сети]].+Вкладка **Фильтры** содержит определения фильтрации правила обнаружения:
  
-Представленные снимки экрана ниже иллюстрируют как выглядят уже обнаруженные элементы данных,​ триггера и графики в настройке узла сети. Обнаруженные объекты имеют префикс ссылку золотистого цвета, которая ведет к правилу обнаружения,​ создавшего эти объекты.+{{manual:​discovery:​low_level_discovery:​lld_rule_fs0da.png|}}
  
-{{manual:discovery:low_level_discovery:discovered_items.png|}}+^Параметр^Описание^ 
 +|//Тип вычисления// ​ |Доступны следующие опции расчета фильтров:​\\ **И** - должны выполниться все фильтры;​\\ **Или** - достаточно выполнения одного фильтра;​\\ **И/​Или** - используется //И// для разных имен макросов и //Или// с одинаковым именем макроса;​\\ **Пользовательское выражение** - появляется возможность указать пользовательское вычисление фильтров. Формула должна включать в себя все фильтры из списка.\\ Ограничено 255 символами. ​ | 
 +|//​Фильтры// ​ | Фильтр можно использовать только для генерирования реальных элементов данных,​ триггеров и графиков конкретных файловых систем. Ожидается использование [[https://​ru.wikipedia.org/​wiki/​PCRE|Perl Compatible Regular Expression]] (PCRE). Например,​ если вы заинтересованы только в файловых системах C:, D: и E:, вы можете поместить ​{#FSNAME} в поле "​Макрос"​ и регулярное выражение <​nowiki>"​^C|^D|^E"</​nowiki>​ в текстовые поля "​Регулярное выражение"​. Фильтрация также возможна по типам файловых систем,​ при использовании макроса ​{#FSTYPE} (например,​ <​nowiki>"​^ext|^reiserfs"</​nowiki>​) и по типу диска (поддерживается только Windows агентов),​ используя макрос {#​FSDRIVETYPE} ​ (например,​ <​nowiki>"​fixed"</​nowiki>​).\\ Вы можете ввести в поле "​Регулярное выражение"​ регулярное выражение или ссылку на глобальное [[ru: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>​Макрос {#​FSDRIVETYPE} на Windows поддерживается начиная с Zabbix **3.0.0**.\\ Определение нескольких фильтров поддерживается начиная с **2.4.0**.\\ Обратите внимание,​ что если какой-то макрос из фильтра отсутствует в ответе,​ найденный объект будет проигнорирован.\\ Две опции выпадающего меню в фильтре позволяют выбрать,​ должен ли макрос соответствовать указанному регулярному выражению или наоборот,​ не соответствовать ему.  ​|
  
-Обратите внимание,​ что обнаруженные объекты не будут созданы в случае, если объекты с такими же условиями уникальности уже существуютнапример, элемент данных с таким же ключем или график ​с таким же именем.+<note important>​Чтобы обнаружение сработало корректно, база данных Zabbix ​в MySQL должна быть создана чувствительной к регистру, если имена ​файловых систем ​различаются только по регистру.</​note>​
  
-Элементы данных (а также, триггеры ​и графики) созданые с помощью низкоуровневого ​правила обнаружения невозможно ​удалить вручную. Тем не менее, они ​будут ​удалены автоматически, если обнаруженный ​объект (файловая системаинтерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр). В этом случае они будут ​удалены спустя некоторое количество дней указанное в поле //Период сохранения потерянных ​ресурсов//.+<note important>​Ошибка или опечатка в регулярном выражениикоторое используется ​в LLD правиле, может привести к удалению тысяч элементов конфигурации, ​данных истории и событий ​на большом ​количестве узлов сети. Например, ​некорректное регулярное выражение "File systems for discovery"​ может привести к удалению тысяч элементов данных, триггеров, данных ​истории и событий.</​note>​
  
-Когда обнаруженный ​объект становится '​Более не обнаруживается', в списке элементов данных ​будет отображаться ​оранжевый индикатор времени жизни. Переместите курсор мыши на этот ​индикатор и вы увидите сообщение с количеством дней до момента удаления ​элемента данных.+== Замещения == 
 +Вкладка **Замещения** позволяет устанавливать правила для изменения списка прототипов ​элементов данныхтриггеров, графиков и узлов сети или их атрибутовесли обнаруженный объект соответствует заданным критериям.
  
-{{:manual:​discovery:​low_level_discovery:​not_discovered_message.png|}}+{{manual:​discovery:​low_level_discovery:​lld_override0.png|}}
  
-Если объекты отмечены ​на удаление, но не были удалены в назначенное время (деактивировано ​правило обнаружения или элемент ​данных ​узла сети)они удалятся ​при ​следующем выполнении правила обнаружения.+Замещения отображаются и выполняются в том порядке, в котором они определены. При необходимости этот порядок можно изменить, перетаскивая строчки из списка с помощью мышки.  
 +Чтобы настроить детали нового замещения, нажмите //​Добавить//​. ​ Чтобы изменить существующее ​замещение, нажмите на его название. Откроется ​всплывающее окно, ​позволяющее редактировать заданные настройки.
  
-{{manual:​discovery:​low_level_discovery:​discovered_triggers.png|}}+{{manual:​discovery:​low_level_discovery:​lld_override1.png|}}
  
-{{manual:​discovery:​low_level_discovery:​discovered_graphs.png|}}+Все обязательные параметры отмечены красными звездочками.
  
-=== - Обнаружение сетевых интерфейсов ​===+^Параметр ​ ^Описание ​ ^  
 +|//​Имя// ​ |Уникальное (для каждого правила низкоуровневого обнаружения) имя замещения. | 
 +|//Если фильтр соответствует// ​ |Следует ли обрабатывать следующие замещения при выполнении условий фильтра:​ \\ **Продолжить замещения** ​будут обработаны последующие замещения. \\ **Остановить обработку** - будут выполнены предшествующие операции (если есть), и текущее замещение,​ последующие замещения будут проигнорированы. | 
 +|//​Фильтры// ​ | Определяет,​ к каким обнаруженным объектам следует применить замещение. Фильтры замещения обрабатываются после [[low_level_discovery#​фильтр|фильтров]] правила обнаружения и имеют ту же функциональность. | 
 +|//​Операции// ​ | Операции замещения отображаются со следующими подробностями:​ \\ **Условие** - тип объекта (прототип элемента данных/​прототип триггеров/​прототип графиков/​прототип узлов сети) и условие,​ которое должно быть выполнено (равно/​не равно/​содержит/​не содержит/​совпадает/​не соответствует) \\ **Действие** - отображаются ссылки для редактирования и удаления операции.. ​ |
  
-Обнаружение ​сетевых интерфейсов осуществляется таким же образом,​ как и обнаружение файловых систем,​ за исключением того, что мы используем ключ правила обнаружения "​net.if.discovery"​ вместо "​vfs.fs.discovery"​ и макрос {#IFNAME} вместо {#FSNAME} в фильтре и в прототипах элементов данных/​триггеров/​графиков.+**Настройка операций**
  
-Примеры прототипов элементов ​данных, которые вы можете ​захотеть создать основываются на "​net.if.discovery":​ "​net.if.in[{#​IFNAME},​bytes]",​ "​net.if.out[{#​IFNAME},​bytes]"​.+Чтобы настроить детали новой операции, нажмите Добавить в блоке операций. Чтобы редактировать существующую операцию,​ нажмите Изменить рядом с операцией. Откроется всплывающее окнов котором вы можете ​редактировать детали операции.
  
-[[#​обнаружение_файловых_систем|Смотрите выше]] для получения информации по поводу фильтра. +{{manual:​discovery:​low_level_discovery:​lld_override_op.png|}}
-=== - Обнаружение CPU и ядер CPU ===+
  
-Обнаружение ​CPU и ядер CPU выполняется аналогично обнаружению сетевых интерфейсов за исключением того, что ключем правила обнаружения является "​system.cpu.discovery"​. Этот ключ обнаружения возвращаетс ​два макроса ​- {#CPU.NUMBER} ​и {#CPU.STATUS}, ​идентифицирующие порядковый номер CPU и состояние соответственно. Отметимнельзя сделать ​четкого различия между действительнымифизическими ​процессорами, ядрами и hyperthread{#​CPU.STATUS} ​на Linux, UNIX и BSD системах возвращают состояние процессоракоторое может ​быть как ​"​online", ​так и "​offline"​. На Windows ​системах, этот же макрос может представлять собой третье значение - "​unknown"​ - которое указывает на то, что процессор был обнаружен, но информация по нему еще не собрана.+^Параметр ​ ^^^^Описание ​ ^  
 +|//Объект// ​ |||| Доступны четыре типа объектов:​ \\ Прототип элемента данных \\ Прототип триггеров \\ Прототип графиков \\ Прототип узлов сети ​  | 
 +|//​Условие// ​ ||||Позволяет фильтровать объекты, к которым должна применяться операция. | 
 +^ |Опция ​ ||| Поддерживаются ​следующие опции:​\\ **равно** - применить к этому прототипу \\ **не равно** - применить ко всем прототипам,​ кроме этого \\ **содержит** - имя прототипа содержит этот шаблон \\ **не содержит** - имя прототипа не содержит этот шаблон \\ **совпадает** - имя прототипа совпадает с этим шаблоном \\ **не соответствует** - имя прототипа не соответствует этому шаблону \\ | 
 +|:::​|Шаблон ​ ||| Шаблон для соответствия имени элемента, триггера, графика или хоста ​в зависимости от выбранного объекта. | 
 +|  ||||| 
 +|  ^Объект:​ //​Прототип элемента данных// ​ |||| 
 +|:::​|//​Создать активированным//  ||| При установке флажка появятся кнопки, позволяющие переопределить исходные параметры объекта:​ \\ //Да// - объект будет добавлен в активированном состоянии\\ //Нет// - объект будет добавлен к обнаруженному объекту,​ но в деактивированном состоянии. | 
 +|:::​|//​Обнаружить// ​ |||При установке флажка появятся кнопки,​ позволяющие переопределить настройки прототипа исходного объекта:​ \\ //Да// - объект будет добавлен\\ //Нет// - объект не будет добавлен
 +|:::|//Интервал ​обновления// ​ |||При установке флажка появятся две опции, позволяющие изменить интервал ​обновления для элемента данных:​ \\ //Задержка// - интервал обновления ​элемента данных. Поддерживаются [[ru/​manual/​config/​macros/​usermacros|пользовательские макросы]] и [[:​ru:​manual/​appendix/​suffixes|суффиксы времени]] (например,​ 30s, 1m, 2h, 1d). Должен быть равен 0, если используются //​Пользовательские интервалы//​. \\ //​Пользовательские интервалы//​ - нажмите Добавить, чтобы указать переменный интервал или итервал по расписаниюСм. также [[ru:​manual:​config:​items:​item:​custom_intervals|пользовательские интервалы]]
 +|:::​|//​Период хранения истории//  |||При установке флажка появятся кнопки,​ позволяющие ​установить другой ​период хранения истории ​для элемента данных:​ \\ //Не хранить историю// - если ​выбрано, данные не будут сохраняться. \\ //Период хранения//​ - если выбраносправа появится поле ввода для указания периода хранения. Поддерживаются [[ru/​manual/​config/​macros/​usermacros|пользовательские макросы]] и [[manual/​config/​macros/​lld_macros|макросы низкоуровневого обнаружения]]. | 
 +|:::​|//​Период хранения динамики изменений// ​ |||При установке флажка появятся кнопки, позволяющие установить другой период хранения динамики изменений для элемента данных:​ \\ //Не хранить динамику изменений//​ - если выбрано, ​данные не будут сохраняться. \\ //Период хранения//​ - если выбрано,​ справа появится поле ввода для ​указания периода хранения. Поддерживаются [[ru/​manual/​config/​macros/​usermacros|пользовательские макросы]] и [[manual/​config/​macros/​lld_macros|макросы низкоуровневого обнаружения]]. | 
 +|  ||||| 
 +|   ​^Объект: //​Прототип триггеров// ​ |||| 
 +|:::​|//​Создать активированным//  ||| При установке ​флажка появятся кнопки, позволяющие переопределить исходные параметры объекта: \\ //Да// - объект будет добавлен в активированном состоянии\\ //Нет// - объект будет добавлен к обнаруженному объекту, но в деактивированном ​состоянии. | 
 +|:::​|//​Обнаружить// ​ |||При установке флажка появятся кнопки, позволяющие переопределить настройки прототипа исходного объекта:​ \\ //Да// - объект будет добавлен\\ //Нет// - объект ​не будет добавлен. | 
 +|:::​|//​Важность// ​ |||При установке флажка появятся кнопки уровней важности триггера, позволяющие изменить ​важность триггера. | 
 +|:::​|//​Теги// ​ |||При установке флажка появится новый блок, позволяющий указать пары тег-значение. \\ Все теги прототипа триггера будут заменены тегами из этого переопределения. | 
 +|  ||||| 
 +|   ​^Объект:​ //​Прототип графиков// ​ |||| 
 +|:::​|//​Обнаружить// ​ |||При установке флажка появятся кнопки, позволяющие переопределить исходные настройки прототипа графиков: \\ //Да// - график будет добавлен. \\ //Нет// - график не будет добавлен. | 
 +|  ||||| 
 +|   ​^Объект:​ //​Прототип узлов сети// ​ |||| 
 +|:::​|//​Создать активированным//  ||| При установке флажка появятся кнопки,​ позволяющие переопределить исходные параметры объекта: \\ //Да// - объект будет добавлен в активированном ​состоянии\\ //Нет// - объект будет добавлен к обнаруженному объекту,​ но в деактивированном состоянии. | 
 +|:::​|//​Обнаружить//  |||При установке флажка появятся кнопки, позволяющие переопределить настройки прототипа исходного объекта:​ \\ //Да// - объект будет добавлен. \\ //Нет// объект не будет добавлен. | 
 +|:::​|//​Присоединить шаблоны// ​ |||При установке флажка появится поле ввода для ​указания шаблонов. Начните вводить имя шаблона или нажмите //​Выбрать// рядом с полем и выберите шаблоны из списка во всплывающем ​окне. ​ \\ Все шаблоны, связанные с прототипом ​узлов сетибудут заменены шаблонами из этого замещения. | 
 +|:::​|//​Инвентарные данные узла сети// ​ |||При установке ​флажка появятся кнопки,​ позволяющие выбрать другой [[:​ru/​manual/​config/​hosts/​inventory|режим заполнения]] инвентарных данных для прототипа узла сети: \\ //​Деактивировано//​ - не заполнять инвентарные данные узла сети \\ //​Вручную//​ - возможность предоставить данные вручную \\ //​Автоматически// - автоматически заполнять данные инвентаризации узла сети на основе собранных метрик|
  
-Обнаружение CPU основано на процессе коллектора агента,​ чтобы поддерживать соответствие с данными,​ которые поставляются коллектором и сохранить ресурсы на получение данных. Такое поведение дает эффект,​ что этот ключ элемента данных не работает с флагом командой строки тестирования (-t) бинарного файла, который возвращает состояние NOT_SUPPORTED и сопутствующее сообщение о том, что процесс коллектора не запущен. 
  
-Прототипы элементов данных, ​которые можно создать на основе обнаружения CPU включают в себя "​system.cpu.load[{#​CPU.NUMBER},​ <​режим>​]",​ "​system.cpu.util[{#​CPU.NUMBER},​ <​тип>,​ <​режим>​]"​ и другие.+== Кнопки диалога ==
  
-=== - Обнаружение ​SNMP OID'ов ===+Кнопки в нижней части диалога позволяют выполнить несколько видов операций.
  
-В этом примере ​мы осуществим обнаружение ​SNMP на коммутаторе. ​Сначала перейдем в астройка" -> "Шаблоны".+|{{manual:​config:​button_add.png|}} ​ |Добавление правила обнаружения. Эта кнопка доступна только для новых ​правил обнаружения. ​ | 
 +|{{manual:​config:​button_update.png|}} ​ |Обновление свойств правила обнаружения. Эта кнопка доступна только для уже ​существующих правил ​обнаружения. ​ | 
 +|{{manual:​config:​button_clone.png|}} ​ |Создание ​другого правила обнаружения на основе свойств текущего правила обнанужения. ​ | 
 +|{{manual:​config:​button_check_now.png|}} ​ |Выполнение немедленного обнаружения на основе правила обнаружения. Правило обнаружения должно существовать. Смотрите [[:​ru/​manual/​config/​items/​check_now|более подробную]] информацию.\\ //​Обратите внимание//, ​что когда обнаружение выполняется немедленно, кэш конфигурации не обновляется,​ поэтому на результат не повлияют совсем недавние изменения настроек правила обнаружения. | 
 +|{{manual:​config:​button_delete.png|}} ​ |Удаление правила ​обнаружения. ​ | 
 +|{{manual:​config:​button_cancel.png|}} ​ |тмена изменения свойств правила обнаружения |
  
-{{manual:​discovery:​low_level_discovery:​templates_snmp.png|}}+=== Прототипы элементов данных ===
  
-Для изменения правил обнаружения шаблона, нажмите ​на ссылку в колонке бнаружение".+Как только правило будет создано, перейдем к элементам данных этого ​правила и нажмем "​Создать прототип",​ чтобы создать прототип элементов данных. Обратите внимание ​на токак используется макрос {#FSNAME}, где требуется указать имя файловой ​системы. Когда правило будет обрабатываться, этот макрос будет заменен обнаруженной файловой системой.
  
-Затем нажмите "​Создать правило"​ и заполните форму, как отображено на снимке экрана ниже. 
  
-В отличие от обнаружения файловых систем и сетевых интерфейсов - этот элемент данных не требует наличия ключа "snmp.discovery", достаточно указать,​ что типом элемента данных является SNMP агент.+{{manual:discovery:​low_level_discovery:​item_prototype_fs1.png|}}
  
-OID'ы для обнаружения ​добавляются в поле ​SNMP OID в следующем формате: ''​discovery[{#​МАКРОС1},​ oid1, {#​МАКРОС2},​ oid2, …,​]''​+Можно использовать [[:​ru/​manual/​config/​macros/​lld_macros|макросы]] низкоуровневого ​обнаружения ​и пользовательские [[:​ru/​manual/​appendix/​macros/​supported_by_location_user|макросы]] ​в настройках ​прототипа элементов данных и в [[:​ru/​manual/​config/​items/​item#​предобработка_значений_элемента_данных|параметрах]] предварительной обработки значений элемента данных.
  
-где //{#МАКРОС1}//, //​{#​МАКРОС2}//​ …  допустимые имена низкоуровневых ​макросов и //oid1//, //oid2//... являются OID'​ами способными сгенерировать ​   ​осмысленные значения для ​этих макросов. Встроенный макрос //​{#​SNMPINDEX}//​ содержит индекс обнаруженного OID, который применяется к обнаруженным объектам. Обнаруженные ​объекты группируются по значению макроса ​//​{#​SNMPINDEX}//​.+<​note>​Контекстное экранирование макросов ​низкоуровневого обнаружения для ​безопасного их использования в регулярных выражениях и параметрах предварительной обработки XPath.</note>
  
-Для понимания ​того, что мы имеем в виду, давайте выполним несколько раз snmpwalk ​на нашем коммутаторе:​ +Специфичные для прототипов элементов данных атрибуты:
-  $ snmpwalk -v 2c -c public 192.168.1.1 IF-MIB::​ifDescr +
-  IF-MIB::​ifDescr.1 = STRING: WAN +
-  IF-MIB::​ifDescr.2 = STRING: LAN1 +
-  IF-MIB::​ifDescr.3 = STRING: LAN2 +
-   +
-  $ snmpwalk -v 2c -c public 192.168.1.1 IF-MIB::​ifPhysAddress +
-  IF-MIB::​ifPhysAddress.1 = STRING: 8:​0:​27:​90:​7a:​75 +
-  IF-MIB::​ifPhysAddress.2 = STRING: 8:​0:​27:​90:​7a:​76 +
-  IF-MIB::​ifPhysAddress.3 = STRING: 8:​0:​27:​2b:​af:9e+
  
-И зададим ​SNMP OID равным: ​''​discovery[{#IFDESCR}ifDescr{#​IFPHYSADDRESS}ifPhysAddress]''​+^Параметр^Описание^ 
 +|//​Новый прототип группы элементов данных// ​ |Вы можете ​задать новый прототип группы элементов ​данных.\\ В свойствах группы элементов данных вы можете ​использовать ​макросы низкоуровневого обнаружения,​ которые,​ после ​выполнения обнаружения,​ будут заменены реальными значениями при создании групп элементов данных,​ которые специфичны для обнаруженного объекта. Смотрите также [[ru:manual:discovery:​low_level_discovery:​notes|заметки по обнаружению групп элементов данных]] для получения более подробной информации. ​ | 
 +|//​Прототипы групп элементов данных// ​ |Выберите из существующих прототипов групп элементов данных. ​ | 
 +|//​Создать активированным// ​ |Если выбраноэлемент данных будет создан в активированном состоянии.\\ Если не выбраноэлемент данных будет добавлен как обнаруженный объектно в деактивированном состоянии. ​ |
  
-Теперь это правило будет обнаруживать объекты ​с макросом {#​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**: +Мы можем создать несколько прототипов элементов данных для каждой ​интересующей нас характеристики файловой ​системы:
-  { +
-      "​data":​ [ +
-          { +
-              "​{#​SNMPINDEX}":​ "​1",​ +
-              "​{#​IFDESCR}":​ "​WAN",​ +
-              "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​90:​7a:​75"​ +
-          }, +
-          { +
-              "​{#​SNMPINDEX}":​ "​2",​ +
-              "​{#​IFDESCR}":​ "​LAN1",​ +
-              "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​90:​7a:​75"​ +
-          }, +
-          { +
-              "​{#​SNMPINDEX}":​ "​3",​ +
-              "​{#​IFDESCR}":​ "​LAN2",​ +
-              "​{#​IFPHYSADDRESS}":​ "​8:​0:​27:​2b:​af:9e" +
-          } +
-      ] +
-  }+
  
-Если обнаруженный объект не имеет указанный OID, тогда по этому объекту соответстующий макрос пропускается. Например,​ если у нас есть следующие данные:​ +{{manual:discovery:low_level_discovery:item_prototypes_fs.png|}}
-  ifDescr.1 "​Interface #1" +
-  ifDescr.2 "​Interface #2" +
-  ifDescr.4 "​Interface #4" +
-   +
-  ifAlias.1 "​eth0"​ +
-  ifAlias.2 "​eth1"​ +
-  ifAlias.3 "​eth2"​ +
-  ifAlias.5 "​eth4"​ +
-  +
-Тогда, в случае SNMP обнаружения ''​discovery[{#IFDESCR}, ifDescr, ​{#IFALIAS}, ifAlias]''​ вернется следующая структура: +
-  { +
-      "​data"​+
-          { +
-              "​{#​SNMPINDEX}"​1, +
-              "​{#​IFDESCR}":​ "​Interface #1", +
-              "​{#​IFALIAS}":​ "​eth0"​ +
-          }, +
-          { +
-              "​{#​SNMPINDEX}":​ 2, +
-              "​{#​IFDESCR}":​ "​Interface #2", +
-              "​{#​IFALIAS}":​ "​eth1"​ +
-          }, +
-          { +
-              "​{#​SNMPINDEX}":​ 3, +
-              "​{#​IFALIAS}":​ "​eth2"​ +
-          }, +
-          { +
-              "​{#​SNMPINDEX}":​ 4, +
-              "​{#​IFDESCR}":​ "​Interface #4" +
-          }, +
-          { +
-              "​{#​SNMPINDEX}":​ 5, +
-              "​{#​IFALIAS}":​ "​eth4"​ +
-          ​} +
-      ] +
-  ​ +
  
-{{manual:​discovery:​low_level_discovery:​lld_rule_snmp.png|}}+=== Прототипы триггеров ===
  
-Представленный снимок экрана ​иллюстрирует как мы можем использовать эти ​макросы в прототипах элементов данных:​+Мы создадим прототипы триггеров похожим способом как и прототипы элементов данных:​
  
-{{manual:​discovery:​low_level_discovery:​item_prototype_snmp.png|}}+{{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png|}}
  
-Опять же, создадим столько ​прототипов ​элементов данных, сколько необходимо:+Специфичные ​для прототипов ​триггеров атрибуты:
  
-{{manual:​discovery:​low_level_discovery:​item_prototypes_snmp.png|}}+^Параметр^Описание^ 
 +|//​Создать активированным// ​ |Если выбрано,​ триггер будет создан в активированном состоянии.\\ Если не выбрано,​ триггер будет добавлен как обнаруженный объект,​ но в деактивированном состоянии |
  
-Также как и прототипы триггеров:+Когда будут созданы реальные триггера из их прототипов,​ возможно потребуется большая гибкость чем использованная константа ('​20'​ в нашем примере) для сравнения в выражении. Смотрите каким образом [[:​manual/​discovery/​low_level_discovery#​использование_макросов_lld_в_контекстах_пользовательских_макросов|пользовательские макросы с контекстом]] могут быть полезны для получения подобной гибкости.
  
-{{manual:discovery:​low_level_discovery:​trigger_prototype_snmp.png|}}+Также вы можете задать [[:ru/​manual/​config/​triggers/​dependencies|зависимости]] между прототипами триггеров (поддерживается начиная с Zabbix 3.0). Чтобы это сделать,​ перейдите на вкладку //​Зависимости//​. Прототип триггеров может зависеть от другого прототипа триггеров из этого же правила низкоуровневого обнаружения (LLD) или от обычного триггера. Прототип триггеров не может зависеть от прототипа триггеров из другого правила LLD и от триггера созданного другим прототипом триггеров. Прототип триггеров узла сети не может зависеть от триггера из шаблона.
  
-{{manual:​discovery:​low_level_discovery:​trigger_prototypes_snmp.png|}}+{{manual:​discovery:​low_level_discovery:​trigger_prototypes_fs.png|}}
  
-И прототипы графиков:+=== Прототипы графиков ​===
  
-{{manual:discovery:​low_level_discovery:​graph_prototype_snmp.png|}}+Мы также можем создать прототипы графиков:
  
-{{manual:​discovery:​low_level_discovery:​graph_prototypes_snmp.png|}}+{{manual:​discovery:​low_level_discovery:​graph_prototype_fs.png|}}
  
-Результат нашего правила обнаружения:+{{manual:discovery:​low_level_discovery:​graph_prototypes_fs.png|}}
  
-{{manual:​discovery:​low_level_discovery:​lld_rules_snmp.png|}}+В конце концов,​ мы создали правило обнаружения,​ которое выглядит как видно ниже. Оно имеет пять прототипов элементов данных,​ два прототипа триггеров и один прототип графиков.
  
-Когда сервер работает,​ он создаст реальные элементы данных,​ триггеры и графики на основе значений,​ полученных от SNMP правила обнаружения. В настройках узлов сети они будут иметь префикс ссылку оранжевого цвета, которая ведет к правилу обнаружения,​ их создавшего.+{{manual:​discovery:​low_level_discovery:​lld_rules_fs.png|}}
  
-{{manual:discovery:low_level_discovery:​discovered_items_snmp.png?600|}}+//​Обратите внимание//​Для получения информации по настройке прототипов узлов сети, смотрите в разделе мониторинга виртуальных машин о настройке [[:ru/​manual/​vm_monitoring#​прототипы_узлов_сети|прототипов узлов сети]].
  
-{{manual:​discovery:​low_level_discovery:​discovered_triggers_snmp.png?​600|}}+=== Обнаруженные объекты ===
  
-{{manual:​discovery:​low_level_discovery:​discovered_graphs_snmp.png?600|}}+Представленные снимки экрана ниже иллюстрируют как выглядят уже обнаруженные элементы данных,​ триггера и графики в настройке узла сети. Обнаруженные объекты имеют префикс ссылку золотистого цвета, которая ведет к правилу обнаружения,​ создавшего эти объекты.
  
-=== - Обнаружение с использованием SQL запросов ODBC ===+{{manual:​discovery:​low_level_discovery:​discovered_items1.png|}}
  
-Этот тип обнаружения осуществляется с использованием SQL запросов, полученные результаты ​которых автоматически преобразуются в объект JSON, пригодный для низкоуровневого обнаружения. SQL запросы выполняются при ​помощи ​элементов данных типа "​Монитор баз данных"​. Так что, большая часть указаний со страницы [[:​ru/​manual/​config/​items/​itemtypes/​odbc_checks|ODBC мониторинга]] применима ​к получению работающего "​Монитора баз данных"​ правила обнаружения,​ единственная разница лишь в том, что необходимо использовать ключ "​db.odbc.discovery[<​описание>,<​dsn>​]"​ вместо "​db.odbc.select[<​описание>,<​dsn>​]"​.+Обратите внимание, что ​обнаруженные ​объекты не будут созданы в случаеесли объекты ​с такими же условиями уникальности ​уже существуют, например, элемент данных ​с таким ​же ключем или график с таким же именем.
  
-В качестве практического примераиллюстрирующего как SQL запрос трансформируется в JSON, рассмотрим ​низкоуровневое обнаружения ​Zabbix прокси,​ выполнив ODBC запрос в Zabbix базу данныхОн может быть полезен для автоматического ​создания [[:​ru/​manual/​config/​items/​itemtypes/​internal|внутренних элементов данных]] "​zabbix[proxy,<​имя>,​lastaccess]", ​чтобы наблюдать какие прокси живы.+Элементы данных (а также, триггеры и графики) созданые с помощью ​низкоуровневого правила ​обнаружения невозможно ​удалить вручнуюТем ​не менее, они будут удалены ​автоматически, если обнаруженный объект (файловая система,​ интерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр). В этом случае они будут удалены спустя некоторое ​количество дней указанное в поле //Период сохранения потерянных ресурсов//​.
  
-Давайте начнем с настройки ​правила обнаружения:+Когда обнаруженный объект становится '​Более не обнаруживается', в списке элементов данных будет отображаться ​оранжевый индикатор времени жизни. Переместите курсор мыши на этот ​индикатор и вы увидите сообщение с количеством дней до момента удаления ​элемента данных.
  
-{{manual:​discovery:​low_level_discovery:​discovery_rule_odbc.png}}+{{:manual:​discovery:​low_level_discovery:​not_discovered_message.png|}}
  
-Здесь используется следующий ​прямой запрос в базу данных Zabbix ​для выборки ​всех Zabbix прокси ​вместе с количеством узлов сети, за которыми эти прокси наблюдают. Количество ​узлов сети ​можно использовать, например, для фильтрации пустых ​прокси:+Если объекты помечены на удаление, но не были удалены в назначенное время (деактивировано правило обнаружения или элемент ​данных ​узла сети), они ​удалятся при ​следующем выполнении правила ​обнаружения.
  
-<​code>​ +Объектыкоторые содержат другие объектыкоторые помечены на удаление,​ не будут обновлены,​ если будут изменены на уровне правила обнаруженияНапример,​ триггеры на основе LLD не будут обновлены,​ если они содержат элементы данных,​ которые помечены на удаление.
-mysql> SELECT h1.hostCOUNT(h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (56) GROUP BY h1.host; +
-+---------+-------+ +
-| host    | count | +
-+---------+-------+ +
-| Japan 1 |     5 | +
-| Japan 2 |    12 | +
-| Latvia ​ |     3 | +
-+---------+-------+ +
-3 rows in set (0.01 sec) +
-</​code>​+
  
-Благодаря внутреннему механизму обработки элемента данных "​db.odbc.discovery[]", результат этого запроса автоматически преобразуется в следующий JSON:+{{manual:discovery:low_level_discovery:​discovered_triggers1.png|}}
  
-<code js> +{{manual:discovery:low_level_discovery:discovered_graphs1.png|}}
-{ +
-    "​data":​ [ +
-        ​{ +
-            "​{#​HOST}"​"Japan 1", +
-            "​{#​COUNT}"​"​5"​ +
-        }, +
-        { +
-            "​{#​HOST}":​ "Japan 2", +
-            "​{#​COUNT}":​ "​12"​ +
-        }, +
-        { +
-            "​{#​HOST}":​ "​Latvia",​ +
-            "​{#​COUNT}"​"​3"​ +
-        ​} +
-    ] +
-} +
-</​code>​+
  
-Видно, что имена колонок становятся ​именами макросов и выбранные строки становятся значениями этих макросов.+=== Другие типы обнаружения ​===
  
-<​note>​ +Для получения ​более детальных сведений и инструкций по остальным типам доступных обнаружений сморите следующие разделы:
-Если результат преобразования ​имени колонки в имя макроса неочевиден, предлагается использовать алиасы к именам колонок, так же как "​COUNT(h2.host) AS count" в примере ​выше.+
  
-В случае, если имя колонки не удается сконвертировать в допустимое имя макроса, правило ​обнаружения становится неподдерживаемым с детальным сообщением об ошибке какой номер колонки не удалось преобразовать. Если желательна дополнительная помощь, полученные ​имена колонки отражаются при  DebugLevel=4 в файле журнала Zabbix ​сервера:+  * обнаружение ​[[:​ru/​manual/​discovery/​low_level_discovery/​network_interfaces|сетевых интерфейсов]]; 
 +  * обнаружение [[:​ru/​manual/​discovery/​low_level_discovery/​cpu|CPU ​и ядер ​CPU]]; 
 +  * обнаружение [[:​ru/​manual/​discovery/​low_level_discovery/​snmp_oids|SNMP OID'ов]]; 
 +  * обнаружение ​[[:​ru/​manual/​discovery/​low_level_discovery/​jmx|JMX ​объектов]]; 
 +  * обнаружение с использованием [[:​ru/​manual/​discovery/​low_level_discovery/​sql_queries|ODBC SQL запросов]]; 
 +  * обнаружение ​[[:​ru/​manual/​discovery/​low_level_discovery/​windows_services|Windows служб]]; 
 +  * обнаружение [[:​ru/​manual/​discovery/​low_level_discovery/​host_interfaces|интерфейсов хостов]] в Zabbix.
  
-<​code>​ +Для получения более подробных сведений касательно JSON формата по обнаружению элементов данных и примера каким образом реализовать своё собственное обнаружение файловых систем при помощи Perl скриптасмотрите ​[[#​создание_пользовательских_lld_правил|создание пользовательских LLD правил]].
-$ grep db.odbc.discovery /​tmp/​zabbix_server.log +
- ... +
- ​23876:​20150114:​153410.856 In db_odbc_discovery() query:'​SELECT h1.hostCOUNT(h2.host) FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) GROUP BY h1.host;'​ +
- ​23876:​20150114:​153410.860 db_odbc_discovery() column[1]:'​host'​ +
- ​23876:​20150114:​153410.860 db_odbc_discovery() column[2]:'​COUNT(h2.host)'​ +
- ​23876:​20150114:​153410.860 End of db_odbc_discovery():​NOTSUPPORTED +
- ​23876:​20150114:​153410.860 Item [Zabbix server:​db.odbc.discovery[proxies,​{$DSN}]] error: Cannot convert column #2 name to macro. +
-</​code>​ +
-</​note>​+
  
-Теперь, когда мы понимаем как SQL запрос трансформируется в JSON объект,​ мы можем использовать макрос {#​HOST} ​в прототипах элементов данных:+== Ограничения ​данных для возвращаемых значений ==
  
-{{manual:​discovery:​low_level_discovery:​item_prototype_odbc.png}}+Ограничения для JSON данных низкоуровневого правила обнаружения отсутствуют,​ если эти данные получены напрямую Zabbix сервером,​ так как полученные значения обрабатываются без сохранения в базу данных. Также ограничения отсутствуют и для пользовательских правил низкоуровневого обнаружения,​ однако,​ если предполагается получение пользовательских LLD данных при помощи пользовательского параметра,​ тогда накладывается ограничение по размеру значения (512 КБ) на сам пользовательский параметр.
  
-Как только обнаружение будет выполнено, элемент данных ​будет создан по каждому ​прокси:+Если данные поступают от Zabbix прокси, этот прокси вынужден сначала записать их в базу данных. В таком случае накладываются ​ [[:​ru/​manual/​config/​items/​item#​ограничения_текстовых_данных|ограничения к базе данных]], например, 2048 байт для Zabbix ​прокси, который работает с IBM DB2 базой данных.
  
-{{manual:​discovery:​low_level_discovery:​discovered_items_odbc.png}}+=== Несколько LLD правил по одному и тому же элементу данных ===
  
-=== - Обнаружение служб Windows === +Начиная с Zabbix агента версии 3.2, имеется ​возможность задать несколько правил низкоуровневого ​обнаружения по одному ​и тому же элементу данных ​обнаружения
- +
-Обнаружение служб Windows осуществляется ​тем же самым способом, что и обнаружение файловых систем. Используемым ​ключем в правиле обнаружения является "​service.discovery"​ и поддерживаются следующие макросы для применения их в [[#обнаружение_файловых_систем|фильтре]] и прототипах ​элементов данныхриггерах/​графиков: +
- +
-<​code>​ +
-{#​SERVICE.NAME} +
-{#​SERVICE.DISPLAYNAME} +
-{#​SERVICE.DESCRIPTION} +
-{#​SERVICE.STATE} +
-{#​SERVICE.STATENAME} +
-{#​SERVICE.PATH} +
-{#​SERVICE.USER} +
-{#​SERVICE.STARTUP} +
-{#SERVICE.STARTUPNAME} +
-</​code>​+
  
-На основе ​обнаружения служб Windows вы можете ​создать ​прототип элементов данных вроде "​service.info[{#​SERVICE.NAME},<​парам>​]",​ где ​//​парам// принимает ​следующие значения: //state////​displayname//,​ //path//, //user//, //startup// или //​description//​. Например, чтобы ​получить отображаемое имя службы вам ​необходимо использовать ​элемент данных ​"​service.info[{#​SERVICE.NAME},​displayname]"​. Если значение //парам// не указано ("​service.info[{#​SERVICE.NAME}]"​), ​будет использоваться ​параметр //state// по умолчанию.+Чтобы ​это сделать, вам необходио указать [[ru/​manual/​appendix/config/zabbix_agentd|параметр]] агента Aliasразрешив использование измененных ключей ​элемента данных ​обнаружения в разных правилах обнаружения, например ​''​vfs.fs.discovery[foo]'',​ ''​vfs.fs.discovery[bar]'' ​и так далее.
  
-Макросы {#​SERVICE.STATE} и {#​SERVICE.STATENAME} возвращают одинаковое содержимое,​ однако,​ {#​SERVICE.STATE} возвращает числовое значение (0-7), тогда как {#​SERVICE.STATENAME} возвращает текст (//​running//,​ //paused//, //start pending//, //pause pending//, //continue pending//, //stop pending//, //stopped// или //​unknown//​). То же самое относится и к {#​SERVICE.STARTUP} и {#​SERVICE.STARTUPNAME},​ где первый возвращает числовое значение (0-4), тогда как второй - текст (//​automatic//,​ //automatic delayed//, //manual//, //​disabled//,​ //​unknown//​). 
 === - Создание пользовательских LLD правил === === - Создание пользовательских LLD правил ===
  
Line 401: Line 351:
     ]     ]
   }   }
-  +
- +
 Тогда, в правилах обнаружения в поле "​Фильтр"​ мы можем указать "​{#​FSTYPE}",​ как макрос,​ и "​rootfs|ext3",​ как регулярное выражение. Тогда, в правилах обнаружения в поле "​Фильтр"​ мы можем указать "​{#​FSTYPE}",​ как макрос,​ и "​rootfs|ext3",​ как регулярное выражение.
  
 <​note>​Вы не обязаны использовать имена макросов FSNAME/​FSTYPE в пользовательских правилах низкоуровневого обнаружения,​ вы можете использовать любые другие имена, которые вам нравятся.</​note>​ <​note>​Вы не обязаны использовать имена макросов FSNAME/​FSTYPE в пользовательских правилах низкоуровневого обнаружения,​ вы можете использовать любые другие имена, которые вам нравятся.</​note>​
 +
 +Обратите внимание на то, что при использовании пользовательского параметра,​ возвращаемые данные ограничены 512 КБ. Для получения более подробных сведений смотрите [[:​ru/​manual/​discovery/​low_level_discovery#​ограничения_данных_для_возвращаемых_значений|ограничения данных для возвращаемых значений LLD]].
  
 === - Использование макросов LLD в контекстах пользовательских макросов === === - Использование макросов LLD в контекстах пользовательских макросов ===
  
-Мы будем использовать ​данные из последнего примера для ​иллюстрации использования макроса LLD в контекстах [[ru:​manual:​config:​macros:​usermacros#​macro_context |пользовательских макросов]]. Исходя из примерабудут обнаружены следующие файловые системы: ​''​/'',​ ''​/home'',​ ''/​tmp'',​ ''​/usr'' ​и ''/​var''​.+Пользовательские макросы [[:​ru/​manual/​config/​macros/​usermacros#​контекст_пользовательских_макросов|с контекстом]] можно ​использовать для ​получения более гибких ​порогов в выражениях триггеров. Разные пороги можно задать на уровне пользовательского ​макроса и затем их можно использовать в константах триггеровв зависимости от обнаруженного контекста. Обнаруженный контекст появляется, когда ​используемые [[:manual/config/macros/lld_macros|макросы низкоуровневого обнаружения]] в макросах раскрываются в реальные значения.
  
-Добавьте прототип ​триггера ​свободного места на диске к узлу сети:+Для иллюстрации мы можем использовать данные ​из приведенного примера выше, предположим, что будут обнаружены ​следующие файловые системы''/'',​ ''/​home'',​ ''/​tmp'',​ ''/​usr'', ​ ''/​var''​.
  
-''​{host:​vfs.fs.size[{#​FSNAME},pfree].last()}<​{$LOW_SPACE_LIMIT:{#​FSNAME}}''​+Мы можем задать узлу сети прототип триггера на свободное место на дискегде порог выражается при помощи пользовательского макроса с контекстом:
  
-И добавьте макросы:​+''​{host:​vfs.fs.size[{#​FSNAME},​pfree].last()}<​**{$LOW_SPACE_LIMIT:<​nowiki>"</​nowiki>​{#​FSNAME}<​nowiki>"</​nowiki>​}**''​ 
 + 
 +Затем ​добавим пользовательские макросы:​
   * ''​{$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**
  
-Тогда события сгенерируются,​ когда на файловых системах ''/'',​ ''/​usr''​ и ''/​var''​ станет ​меньше ​свободного места на диске ​более чем ​на **10**%, файловой системе ''/​tmp''​ станет ​меньше ​свободного места на диске ​более чем ​на **50**% или на файловой системе ''/​home''​ станет ​меньше ​свободного места на диске ​более чем ​на **20**%. +Тогда события сгенерируются,​ когда на файловых системах ''/'',​ ''/​usr''​ и ''/​var''​ станет свободного места на диске ​меньше чем **10**%, файловой системе ''/​tmp''​ станет свободного места на диске ​менее чем **50**% или на файловой системе ''/​home''​ станет свободного места на диске ​менее чем **20**%.
- +