Zabbix Documentation 4.4

3.04.04.45.0 (current)| In development:5.2 (devel)| Unsupported:1.82.02.22.43.23.44.2Guidelines

User Tools

Site Tools


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/07 23:34]
dotneft
ru:manual:discovery:low_level_discovery [2020/01/07 04:58] (current)
dotneft
Line 1: Line 1:
-==== - #3 Низкоуровневое обнаружение ====+==== 3 Низкоуровневое обнаружение ====
 === Обзор ===  === Обзор === 
  
 Низкоуровневое обнаружение (LLD) даёт возможность автоматического создания элементов данных,​ триггеров и графиков для различных объектов на компьютере. Например,​ Zabbix может автоматически начать мониторить файловые системы или сетевые интерфейсы с вашего устройства,​ без необходимости создания вручную элементов данных для каждой файловой системы или сетевого интерфейса. Кроме того, в Zabbix имеется возможность настроить удаление ненужных объектов,​ основываясь на фактических результатах периодически выполняемого обнаружения. Низкоуровневое обнаружение (LLD) даёт возможность автоматического создания элементов данных,​ триггеров и графиков для различных объектов на компьютере. Например,​ Zabbix может автоматически начать мониторить файловые системы или сетевые интерфейсы с вашего устройства,​ без необходимости создания вручную элементов данных для каждой файловой системы или сетевого интерфейса. Кроме того, в Zabbix имеется возможность настроить удаление ненужных объектов,​ основываясь на фактических результатах периодически выполняемого обнаружения.
- 
-В Zabbix поддерживаются три встроенных типа элементов данных для обнаружения:​ 
- 
-  * обнаружение файловых систем;​ 
-  * обнаружение сетевых интерфейсов;​ 
-  * обнаружение CPU и ядер CPU; 
-  * обнаружение SNMP OID'​ов;​ 
-  * обнаружение с использованием SQL запросов ODBC; 
-  * обнаружение Windows служб. 
  
 Пользователь имеет возможность определить свои собственные типы обнаружения,​ обеспечив их функционирование согласно спецификации JSON протокола. Пользователь имеет возможность определить свои собственные типы обнаружения,​ обеспечив их функционирование согласно спецификации JSON протокола.
Line 19: Line 10:
 Сначала,​ пользователь создает правило обнаружения в "​Настройка"​ -> "​Шаблоны"​ -> колонка "​Обнаружение"​. Правило обнаружения состоит из (1) элемента данных,​ который осуществляет обнаружение необходимых объектов (например,​ файловые системы или сетевые интерфейсы) и (2) прототипов элементов данных,​ триггеров и графиков,​ которые должны быть созданы на основании полученных значений этого элемента данных. Сначала,​ пользователь создает правило обнаружения в "​Настройка"​ -> "​Шаблоны"​ -> колонка "​Обнаружение"​. Правило обнаружения состоит из (1) элемента данных,​ который осуществляет обнаружение необходимых объектов (например,​ файловые системы или сетевые интерфейсы) и (2) прототипов элементов данных,​ триггеров и графиков,​ которые должны быть созданы на основании полученных значений этого элемента данных.
  
-Элемент данных,​ который осуществляет обнаружение необходимых объектов,​ подобен обычным элементам данных,​ которые видны в других местах:​ 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 ​автоматически извлечёт макрос и значение, если поле массива использует {#​МАКРОС} ключом. Любые новые встроенные проверки ​обнаружения ​будут использовать ​новый ​синтаксис без %%"​%%data%%"​%% элементов. При обработке ​значения низкоуровневого обнаружения сначала определяется корень (массив ''​$.''​ или ''​$.data''​). 
 + 
 +Хотя %%"​%%data%%"​%% элемент удален со всех встроенных элементов данных, ​которые относятся к обнаружению, для обратной совместимости Zabbix будет ещё ​принимать JSON представление с %%"​%%data%%"​%% элементов, хотя ​его использование не рекомендуетсяЕсли JSON содержит объект только ​с одним %%"​%%data%%"​%% элементом массиватогда этот массив ​будет автоматически извлечён из содержимого ​элемента с использованием JSONPath ''​$.data''​. Теперь низкоуровневое обнаружение принимает пользовательские LLD макросы с пользовательским путём, который задается в JSONPath синтаксисе
 +  
 +<note warning>​В ​результате изменений описанных выше более новые агенты не будут способны работать с более старыми версиями Zabbix сервера.</​note>​ 
 + 
 +Смотрите также: [[#​обнаруженные_объекты|Обнаруженные объекты]]
  
-Следующий раздел иллюстрирует весь процесс, описанный выше, в деталях и служит руководством, ​как осуществлять все упомянутые выше типы обнаружений. Последний ​раздел ​описывает формат JSON элементов данных обнаружения и дает пример того, как реализовать ваш собственный скрипт для ​обнаружения ​файловых систем,​ используя Perl скрипт.+=== Настройка низкоуровневого обнаружения ​===
  
-=== - Обнаружение файловых систем ​===+Мы проиллюстрируем низкоуровневое обнаружение ​на примере обнаружения ​файловых систем.
  
-Для настройки обнаружения ​файловых систем, сделайте следующее:​+Для настройки обнаружениявыполните следующее:​
  
-  * Перейдите в: //​Настройки// -> //​Шаблоны// ​  +  * Перейдите в: //​Настройка// -> //​Шаблоны//​  
-  * Нажмите на //​Обнаружение//​ в строке соответствующего ​шаблона+  * Нажмите на //​Обнаружение//​ в строке ​с соответствующим шаблоном
  
 {{manual:​discovery:​low_level_discovery:​fs_templates.png|}} {{manual:​discovery:​low_level_discovery:​fs_templates.png|}}
  
   * Нажмите на //​Создать правило обнаружения//​ в верхнем правом углу экрана   * Нажмите на //​Создать правило обнаружения//​ в верхнем правом углу экрана
-  * Заполните диалог ​следующими деталями+  * Заполните диалог ​правила обнаружение необходимыми деталями
  
-Вкладка **Правило обнаружения** содержит общие атрибуты правила обнаружения:​+=== Правило обнаружения ​===
  
-{{manual:​discovery:​low_level_discovery:​lld_rule_fs.png|}}+Диалог правила обнаружения содержит четыре вкладки,​ представляющие,​ слева направо,​ поток данных в процессе обнаружения:​ 
 + 
 +  * //​Правило обнаружения//​ - задает,​ что наиболее важно, встроенный элемент данных или пользовательский скрипт для получения данных обнаружения 
 +  * //​Предобработка//​ - применение некоторой предобработки к обнаруженным данным 
 +  * //LLD макросы//​ - позволяет извлекать некоторые значения макросов,​ чтобы использовать их в обнаруженных элементах данных,​ триггерах и т.п. 
 +  * //​Фильтры//​ - позволяет фильтровать обнаруженные значения 
 + 
 +Вкладка **Правило обнаружения** содержит ключ элемента данных,​ который используется для обнаружения (а также некоторые общие атрибуты правила обнаружения):​ 
 + 
 +{{manual:​discovery:​low_level_discovery:​lld_rule_fs0.png?600|}} 
 + 
 +Все обязательные поля ввода отмечены красной звёздочкой.
  
 ^Параметр^Описание^ ​ ^Параметр^Описание^ ​
 |//​Имя// ​ |Имя правила обнаружения. ​ |  |//​Имя// ​ |Имя правила обнаружения. ​ | 
-|//​Тип// ​ |Тип проверки выполняемого обнаружения;​ должен быть //Zabbix агент//​ или //Zabbix агент (активный)//​ при обнаружении файловых систем. ​ |  +|//​Тип// ​ |Тип проверки выполняемого обнаружения;​ должен быть //Zabbix агент//​ или //Zabbix агент (активный)//​ при обнаружении файловых систем.\\ Правило обнаружения также может быть [[:​ru/​manual/​config/​items/​itemtypes/​dependent_items|зависимым элементом данных]],​ которое зависит от обычного элемента данных. Оно не может зависеть от другого правила обнаружения. Для работы зависимым элементом данных,​ выберите соответствующий тип (//​Зависимый элемент данных//​) и укажите основной элемент данных в '​Основной элемент данных'​ поле. Основной элемент данных должен существовать.  |  
-|//​Ключ// ​ |Элемент данных "​vfs.fs.discovery"​ уже встроен в Zabbix агент ​на многих платформах (для получения более детальных сведений смотрите [[ru:​manual:​appendix:​items:​supported_by_platform|список поддерживаемых ключей элементов данных]]),​ который возвращает список файловых систем,​ присутствующих в компьютере,​ и их типы в формате JSON.  |  +|//​Ключ// ​ |Элемент данных "​vfs.fs.discovery"​ уже встроен в Zabbix агент ​для ​многих платформах (для получения более детальных сведений смотрите [[ru:​manual:​appendix:​items:​supported_by_platform|список поддерживаемых ключей элементов данных]]),​ который возвращает список файловых систем,​ присутствующих в компьютере,​ и их типы в формате JSON.  |  
-|//​Интервал обновления ​(в сек)//  |Этот фильтр ​задает как часто 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 лет; или %%"%%0%%"​%%).\\ Поддерживаются [[:​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/appendix/preprocessing/preprocessing_details|Подробная информация ​о предварительной обработке]].
  
-//​Прототип группы элементов данных//​ является опцией,​ которая указывается в свойствах прототипов элементов данных. В свойствах группы элементов данных вы можете использовать макросы низкоуровневого обнаружения,​ которые,​ после выполнения обнаружения,​ будут заменены реальными значениями при создании групп элементов данных,​ которые специфичны для обнаруженного объекта. Смотрите также [[ru:manual:​discovery:​low_level_discovery:​notes|заметки по обнаружению групп элементов данных]] для получения более подробной информации.+{{manual:​discovery:​low_level_discovery:​lld_rule_fs2b.png?​600|}}
  
-Мы можем создать несколько прототипов элементов данных для каждой интересующей нас характеристики ​файловой системы:​+^Тип^Преобразование^Описание^ 
 +|  ||| 
 +^Текст ​ ^^^ 
 +|   ​|//​Регулярное выражение// ​ |Совпадение значения с регулярным выражением <​шаблона> и замена значения в соответствии с <​выводом>​. Регулярное выражение поддерживает извлечение до 10 захваченных групп в \N последовательности.\\ Параметры:\\ **шаблон** - регулярное выражение\\ **вывод** - шаблон форматирования вывода. \N (где N=1..9) - управляющая последовательность ​заменяется N-нной совпадающей группой. Управляющая последовательность \0 заменяется совпадающим текстом\\ Если вы отметите опцию //​Другое при ошибке//,​ появится возможность задать пользовательскую опцию обработки ошибок:​ либо ​отбросить значение,​ задать ​пользовательское значение или задать пользовательское сообщение об ошибке. | 
 +^Структурированные данные ​ ^^^ 
 +|   ​|//​JSON Path// ​ |Извлечение значения или фрагмента с JSON данных с использованием [[:​ru/​manual/​appendix/​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/​appendix/​preprocessing/​csv_to_json#​обработка_csv_заголовка|Предобработка CSV в JSON]].\\ Поддерживается начиная с 4.4.0. ​ | 
 +^Пользовательские скрипты ​ ^^^ 
 +|   ​|//​Javascript// ​ |Ввод кода JavaScript в этот блок, который появляется при нажатии на поле параметра или на //​Открыть//​.\\ Обратите внимание,​ что доступная длина JavaScript зависит от [[:​ru/​manual/​config/​items/​item##​ограничения_пользовательского_скрипта|используемой базы данных]]. ​ | 
 +^Валидация ​ ^^^ 
 +|   ​|//​Не совпадает с регулярным выражением// ​ |Регулярное выражение,​ которому значение не должно соответствовать.\\ Например,​ ''​%%Error:​(.*?​)\.%%''​\\ Если вы отметите опцию //​Другое при ошибке//,​ появится возможность задать пользовательскую опцию обработки ошибок:​ либо отбросить значение,​ задать пользовательское значение или задать пользовательское сообщение об ошибке. ​ | 
 +|   ​|//​Проверка на ошибку в JSON// ​ |Проверка на наличие сообщения об ошибке на уровне приложения,​ обнаруженной в JSONpath. Остановка обработки,​ если успешно и сообщение не пустое;​ в противном случае продолжение обработки со значением,​ которое было до этого шага обработки. Обратите внимание,​ что эти ошибки внешнего сервиса сообщаются пользователю как есть, без добавления информации шага предобработки.\\ Например,​ ''​$.errors''​. Если получен примерно такой JSON ''​%%{"​errors":"​e1"​}%%'',​ следующий шаг предобработки не будет выполнен.\\ Если вы отметите опцию //​Другое при ошибке//,​ элемент данных не станет неподдерживаемым при ошибке на шаге предобработки и появится возможность задать пользовательскую опцию обработки ошибок:​ либо отбросить значение, задать пользовательское значение или задать пользовательское сообщение об ошибке. ​   | 
 +|   ​|//​Проверка на ошибку в XML//  |Проверка на наличие сообщения об ошибке на уровне приложения,​ обнаруженной в xpath. Остановка обработки,​ если успешно и сообщение не пустое; ​в противном случае продолжение обработки со значением,​ которое было до этого шага обработки. Обратите внимание,​ что эти ошибки внешнего сервиса сообщаются пользователю как есть, без добавления информации шага предобработки.\\ Ошибка не будет сообщена в случае неудачного анализа ошибочного XML.\\ Если вы отметите опцию //​Другое при ошибке//,​ элемент данных не станет неподдерживаемым при ошибке на шаге предобработки и появится возможность задать пользовательскую опцию обработки ошибок:​ либо отбросить значение,​ задать пользовательское значение или задать пользовательское сообщение об ошибке. ​ | 
 +^Троттлинг ​ ^^^ 
 +|   ​|//​Отбрасывать не изменившееся с периодическим контролем// ​ |Игнорирование значение,​ если оно не изменилось,​ в течении заданного периода времени (в секундах).\\ Поддерживаются положительные числовые значения,​ которые указывают количество секунд (минимально - 1 секунда). В этом поле можно использовать суффиксы времени (например,​ 30s, 1m, 2h, 1d). В этом поле можно использовать пользовательские макросы и макросы низкоуровневого обнаружения.\\ Для низкоуровневого обнаружения можно указать только одну опцию троттлинга.\\ Например,​ ''​1m''​. Если в это правило передается идентичный текст дважды за 60 секунд,​ этот текст будет отброшен.\\ //​Обратите внимание//:​ Изменение прототипов элементов данных не сбрасывает троттлинг. Троттлинг сбрасывается только,​ когда меняются шаги предобработки. ​ | 
 +^Prometheus ​ ^^^ 
 +|   ​|//​Prometheus в JSON// ​ |Конвертация необходимых Prometheus метрик в JSON.\\ Смотрите [[:ru/​manual/​config/​items/​itemtypes/​prometheus|проверки Prometheus]] для получения более подробных сведений. ​ |
  
-{{manual:​discovery:​low_level_discovery:​item_prototypes_fs.png|}}+Обратите внимание,​ если правило обнаружения применено к узлу сети через шаблон,​ тогда содержимое этой вкладки будет доступно только для чтения.
  
-Теперь похожим способом мы создадим прототипы триггеров:​+== Пользовательские макросы ==
  
-{{manual:discovery:​low_level_discovery:​trigger_prototype_fs.png|}}+Использование пользовательского пути для извлечения значений макросов опционально. Zabbix автоматически извлечёт макрос и значение,​ если поле массива в JSON использует ​{#​МАКРОС} синтаксис ключом,​ как при использовании встроенных элементов данных обнаружения,​ например,​ ''​vfs.fs.discovery''​.
  
-Также вы можете задать ​[[:​ru/​manual/​config/​triggers/​dependencies|зависимости]] между прототипами триггеров (поддерживается ​начиная с Zabbix 3.0). Чтобы это сделать, перейдите на вкладку //Зависимости//. Прототип триггеров может ​зависеть от другого прототипа триггеров из этого же правила низкоуровневого обнаружения ​(LLD) или от обычного ​триггера. ​Прототип триггеров не может зависеть от прототипа триггеров из другого правила LLD и от триггера созданного другим прототипом ​триггеров. Прототип триггеров узла сети ​не может зависеть от триггера из шаблона.+Вкладка **LLD макросы** позволяет указать ​пользовательские макросы низкоуровневого обнаружения ​и создать ​карту соответствий этих макросов к значениям, извлеченным ​с результата обнаружения с использованием JSONPath. Извлеченные значения ​можно ​использовать в обнаруженных элементах данных, ​триггерах и т.п. Обратите внимание, это действие применяется к результату обнаружения ​и предварительной обработке примененной на данный момент (см. ​выше).
  
-{{manual:​discovery:​low_level_discovery:​trigger_prototypes_fs.png|}}+{{manual:​discovery:​low_level_discovery:​lld_rule_fs0c.png|}}
  
-И также прототипы графиков:+^Параметр^Описание^ 
 +|//LLD макрос// ​ |Имя макроса низкоуровневого обнаружения, используется следующий синтаксис:​ {#​МАКРОС}. ​ | 
 +|//​JSONPath// ​ |Путь, который используется для извлечения значения LLD макроса из LLD записи,​ с использованием JSONPath синтаксиса.\\ Например, ''​$.foo''​ извлечёт %%"​%%bar%%"​%% и %%"​%%baz%%"​%% из этого JSON: ''​[{%%"​%%foo%%"​%%:​%%"​%%bar%%"​%%},​ {%%"​%%foo%%"​%%:​%%"​%%baz%%"​%%}]''​\\ Значения,​ извлеченные с полученного JSON, используются для замены LLD макросов в полях прототипов элементов данных, триггеров и т.п.\\ JSONPath можно указывать с использованием представления в виде точек или в представлении со скобками. Представление со скобками необходимо использовать при наличии каких-либо специальных символов и Юникода,​ например,​ ''​$['​юникод + спец. символы #​1'​]['​юнидод + спец.символы #​2'​]''​. ​ |
  
-{{manual:​discovery:​low_level_discovery:​graph_prototype_fs.png|}}+== Фильтр ==
  
-{{manual:discovery:​low_level_discovery:​graph_prototypes_fs.png|}}+Вкладка **Фильтры** содержит определения фильтрации правила обнаружения,​ позволяя фильтровать значения обнаружения:
  
-В конце концов,​ мы создали правило обнаружения,​ которое выглядит как видно ниже. Оно имеет пять прототипов элементов данных,​ два прототипа триггеров и один прототип графика.+{{manual:​discovery:​low_level_discovery:​lld_rule_fs0d.png?600|}}
  
-{{manual:discovery:low_level_discovery:lld_rules_fs.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**.\\ Обратите внимание,​ что если какой-то макрос из фильтра пропущен в ответе,​ найденный объект будет игнорироваться.\\ Выпадающее меню в фильтре представлены два значения задать,​ которые можно использовать для соответствия регулярному выражению или наоборот,​ отсутствию соответствия.  ​|
  
-//Обратите внимание//: Для получения ​информации ​по настройке прототипов узлов сети, смотрите в разделе мониторинга ​виртуальных машин о настройке [[:​ru/​manual/​vm_monitoring#​прототипы_узлов_сети|прототипов узлов сети]].+<note warning>Ошибка или опечатка ​в регулярном выражении, которое используется в LLD правиле, может привести к удалению тысяч элементов конфигурации, данных истории и событий на большом количестве узлов сети. Например, некорректное регулярное выражение %%"​%%File systems for discovery%%"​%% ​может привести к удалению тысяч элементов данных, ​триггеров, данных ​истории и событий.</​note>​
  
-Представленные снимки экрана ниже иллюстрируют ​как выглядят уже ​обнаруженные элементы данных, ​триггера и графики в настройке узла сети. Обнаруженные ​объекты имеют префикс ссылку ​золотистого цвета, ​которая ведет к правилу обнаружения, создавшего эти объекты.+<note important>​Чтобы обнаружение сработало корректнобаза данных Zabbix в MySQL должна быть создана чувствительной к регистру, если имена ​файловых систем различаются только по регистру.</​note>​ 
 +  
 +== Кнопки диалога ==
  
-{{manual:​discovery:​low_level_discovery:​discovered_items.png|}}+Кнопки в нижней части диалога позволяют выполнить несколько видов операций.
  
-Обратите внимание, что обнаруженные объекты ​не будут созданы в случае, если объекты с такими же условиями ​уникальности ​уже существуют,​ например, элемент данных с таким же ключем или график с таким же именем.+|{{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|}} ​ |Отмена изменения свойств правила обнаружения |
  
-Элементы данных (а также, триггеры и графики) созданые с помощью низкоуровневого правила обнаружения невозможно удалить вручную. Тем не менее, ​они будут удалены автоматически, если обнаруженный объект (файловая система, интерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр). В этом случае они будут удалены спустя некоторое количество дней указанное в поле //​Период сохранения потерянных ​ресурсов//​.+=== Прототипы элементов данных ​===
  
-Когда обнаруженный объект становится 'Более не обнаруживается'в списке элементов данных ​будет отображаться оранжевый ​индикатор времени жизниПереместите ​курсор ​мыши на этот индикатор и вы увидите сообщение с количеством дней до момента удаления элемента данных.+Как только правило будет создано, перейдем к элементам данных ​этого правила и нажмем "​Создать ​прототип", чтобы создать прототип элементов данныхОбратите ​внимание на токак используется макрос {#FSNAME}, где требуется указать имя файловой системы. Когда правило будет обрабатываться,​ этот макрос будет заменен ​обнаруженной файловой системой.
  
-{{:​manual:​discovery:​low_level_discovery:​not_discovered_message.png|}} 
  
-Если объекты отмечены на удаление,​ но не были удалены в назначенное время (деактивировано правило обнаружения или элемент данных узла сети), они удалятся при следующем выполнении правила обнаружения.+{{manual:​discovery:​low_level_discovery:​item_prototype_fs1.png|}}
  
-{{manual:discovery:low_level_discovery:​discovered_triggers.png|}}+Можно использовать [[:ru/manual/​config/​macros/​lld_macros|макросы]] низкоуровневого обнаружения и пользовательские [[:ru/​manual/​appendix/​macros/​supported_by_location_user|макросы]] в настройках прототипа элементов данных и в [[:ru/​manual/​config/​items/​item#​предобработка_значений_элемента_данных|параметрах]] предварительной обработки значений элемента данных. Обратите внимание,​ что при использовании в интервалах обновления,​ один макрос должен заполнять значение целиком. Запись нескольких макросов в значении или смешение макросов с текстом не поддерживается.
  
-{{manual:​discovery:​low_level_discovery:​discovered_graphs.png|}}+<​note>​Контекстное экранирование макросов низкоуровневого обнаружения для безопасного их использования в регулярных выражениях и параметрах предварительной обработки XPath.</​note>​
  
-=== - Обнаружение ​сетевых ​интерфейсов ===+Специфичные для прототипов элементов данных атрибуты:
  
-Обнаружение ​сетевых ​интерфейсов осуществляется таким же образом, как и обнаружение ​файловых систем, за исключением тогочто мы используем ключ правила обнаружения "​net.if.discovery"​ вместо "​vfs.fs.discovery" ​и макрос {#IFNAME} вместо {#​FSNAME} ​в фильтре и в прототипах элементов данных/​триггеров/графиков.+араметр^Описание
 +|//​Новый прототип группы элементов данных//  |Вы можете задать новый прототип группы элементов данных.\\ В свойствах группы элементов данных вы можете использовать ​макросы низкоуровневого ​обнаружения, которые, после ​выполнения обнаружениябудут ​заменены реальными значениями при создании групп элементов данныхкоторые специфичны для обнаруженного объекта. Смотрите также [[ru:​manual:​discovery:​low_level_discovery:​notes|заметки по обнаружению групп элементов данных]] для получения более подробной информации. ​ | 
 +|//Прототипы групп элементов ​данных// ​ |Выберите из существующих ​прототипов групп ​элементов данных.  | 
 +|//​Создать активированным//  |Если выбрано, элемент данных будет создан в активированном состоянии.\\ Если не выбрано,​ элемент данных будет добавлен как обнаруженный объект,​ но в деактивированном состоянии |
  
-Примеры прототипов элементов данныхкоторые вы можете захотеть создать основываются на "​net.if.discovery"​"​net.if.in[{#​IFNAME},​bytes]",​ "​net.if.out[{#​IFNAME},​bytes]"​.+Мы можем создать несколько ​прототипов элементов данных ​для ​каждой интересующей нас характеристики файловой системы:
  
-[[#​обнаружение_файловых_систем|Смотрите выше]] для получения информации по поводу фильтра. +{{manual:​discovery:​low_level_discovery:​item_prototypes_fs.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/​items/​itemupdate#​использование_массового_обновленияассового обновления]]// ​на случай, если вы захотите обновить свойства нескольких ​прототипов элементов ​данных за раз.
  
-Обнаружение CPU основано на процессе коллектора агента, чтобы ​поддерживать соответствие с данными, которые поставляются коллектором ​и сохранить ресурсы на получение данных. Такое поведение дает эффект,​ что этот ключ элемента данных не работает с флагом командой строки тестирования (-t) бинарного файла, который возвращает состояние NOT_SUPPORTED и сопутствующее сообщение о том, что процесс коллектора не запущен.+=== Прототипы триггеров ​===
  
-Прототипы ​элементов ​данных, которые ​можно ​создать на основе обнаружения CPU включают в себя "​system.cpu.load[{#​CPU.NUMBER},​ <​режим>​]",​ "​system.cpu.util[{#​CPU.NUMBER},​ <тип>, <режим>]" и другие.+Мы создадим прототипы триггеров похожим способом как и прототипы элементов ​данных:
  
-=== - Обнаружение SNMP OID'​ов ===+{{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png|}}
  
-В этом ​примере мы осуществим ​обнаружение SNMP на коммутаторе. Сначала перейдем ​в астройка"​ -> "Шаблоны".+Специфичные для прототипов триггеров атрибуты:
  
-{{manual:​discovery:​low_level_discovery:​templates_snmp.png|}}+^Параметр^Описание^ 
 +|//​Создать активированным// ​ |Если выбрано,​ триггер будет создан в активированном состоянии.\\ Если не выбрано,​ триггер будет добавлен как обнаруженный объект,​ но в деактивированном состоянии |
  
-Для изменения правил обнаружения шаблонанажмите на ссылку в колонке "​Обнаружение".+Когда будут созданы реальные триггера из их прототипов,​ возможно потребуется большая гибкость чем использованная константа ('​20'​ в нашем примере) для сравнения в выражении. Смотрите ​каким образом [[:​ru/​manual/​discovery/​low_level_discovery#​использование_макросов_lld_в_контекстах_пользовательских_макросов|пользовательские макросы с контекстом]] могут быть полезны для получения подобной гибкости.
  
-Затем нажмите ​оздать правило" ​и заполните ​форму, как отображено на снимке экрана ​ниже.+Также вы можете задать [[:​ru/​manual/​config/​triggers/​dependencies|зависимости]] между прототипами триггеров (поддерживается начиная с Zabbix 3.0). Чтобы это сделатьперейдите на вкладку //​Зависимости//. Прототип триггеров может ​зависеть от другого ​прототипа триггеров из этого же правила низкоуровневого ​обнаружения (LLD) или ​от обычного триггера. Прототип триггеров не может зависеть от прототипа триггеров из другого правила LLD и от триггера созданного другим прототипом триггеров. Прототип триггеров узла сети ​не может зависеть от триггера из шаблона.
  
-В отличие от обнаружения файловых систем и сетевых интерфейсов - этот элемент данных не требует наличия ключа "snmp.discovery", достаточно указать,​ что типом элемента данных является SNMP агент.+{{manual:discovery:​low_level_discovery:​trigger_prototypes_fs.png|}}
  
-OID'ы для обнаружения добавляются в поле SNMP OID в следующем формате:​ ''​discovery[{#​МАКРОС1},​ oid1, {#​МАКРОС2},​ oid2, …,​]''​+=== Прототипы графиков ===
  
-где //{#МАКРОС1}//,​ //​{#​МАКРОС2}//​ …  допустимые имена низкоуровневых ​макросов и //oid1//, //oid2//... являются OID'ами способными сгенерировать ​   ​осмысленные значения для этих макросов. Встроенный макрос //​{#​SNMPINDEX}//​ содержит индекс обнаруженного OID, который ​применяется к обнаруженным объектам. Обнаруженные объекты группируются по значению макроса //​{#​SNMPINDEX}//​.+Мы также можем создать ​прототипы графиков:
  
-Для понимания того, что мы имеем в виду, давайте выполним несколько раз snmpwalk на нашем коммутаторе: +{{manual:discovery:low_level_discovery:graph_prototype_fs.png|}}
-  $ 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]''​+{{manual:discovery:​low_level_discovery:​graph_prototypes_fs.png|}}
  
-Теперь это правило ​будет ​обнаруживать объекты с макросом {#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:lld_rules_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|}}+//​Обратите внимание//​Для получения информации по настройке прототипов узлов сети, смотрите в разделе мониторинга виртуальных машин о настройке [[:ru/​manual/​vm_monitoring#​прототипы_узлов_сети|прототипов узлов сети]].
  
-Представленный снимок экрана иллюстрирует как мы можем использовать эти макросы в прототипах элементов данных:+=== Обнаруженные объекты ​===
  
-{{manual:​discovery:​low_level_discovery:​item_prototype_snmp.png|}}+Представленные снимки экрана ниже иллюстрируют как выглядят уже обнаруженные элементы данных,​ триггера и графики в настройке узла сети. Обнаруженные объекты имеют префикс ссылку золотистого цвета, которая ведет к правилу обнаружения,​ создавшего эти объекты.
  
-Опять же, создадим столько прототипов элементов данных,​ сколько необходимо:+{{manual:discovery:​low_level_discovery:​discovered_items1.png|}}
  
-{{manual:​discovery:​low_level_discovery:​item_prototypes_snmp.png|}}+Обратите внимание,​ что обнаруженные объекты не будут созданы в случае,​ если объекты с такими же условиями уникальности уже существуют,​ например,​ элемент данных с таким же ключом или график с таким же именем. В этом случае в веб-интерфейсе отобразится сообщений об ошибке,​ о том что правило обнаружения не смогло создать конкретные объекты. Однако,​ само правило обнаружение не станет неподдерживаемым поскольку не удалось создать некоторый объект и его пришлось пропустить. Правило обнаружения продолжит создавать/​обновлять другие объекты.
  
-Также ​как и прототипы триггеров:+Элементы данных (а также, триггеры и графики) созданые с помощью низкоуровневого правила обнаружения невозможно удалить вручную. Тем не менее, ​они будут удалены автоматически, если обнаруженный объект (файловая система,​ интерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр). В этом случае они будут удалены спустя некоторое количество дней указанное в поле //​Период сохранения потерянных ресурсов//.
  
-{{manual:​discovery:​low_level_discovery:​trigger_prototype_snmp.png|}}+Когда обнаруженный объект становится '​Более не обнаруживается',​ в списке элементов данных будет отображаться оранжевый индикатор времени жизни. Переместите курсор мыши на этот индикатор и вы увидите сообщение с количеством дней до момента удаления элемента данных.
  
-{{manual:​discovery:​low_level_discovery:​trigger_prototypes_snmp.png|}}+{{:manual:​discovery:​low_level_discovery:​not_discovered_message.png|}}
  
-И прототипы ​графиков:+Если объекты ​помечены на удаление,​ но не были удалены в назначенное время (деактивировано правило обнаружения или элемент данных узла сети), они удалятся ​при следующем выполнении правила обнаружения.
  
-{{manual:​discovery:​low_level_discovery:​graph_prototype_snmp.png|}}+Объекты,​ которые содержат другие объекты,​ которые помечены на удаление,​ не будут обновлены,​ если будут изменены на уровне правила обнаружения. Например,​ триггеры на основе LLD не будут обновлены,​ если они содержат элементы данных,​ которые помечены на удаление.
  
-{{manual:​discovery:​low_level_discovery:​graph_prototypes_snmp.png|}}+{{manual:​discovery:​low_level_discovery:​discovered_triggers1.png|}}
  
-Результат нашего правила обнаружения:+{{manual:discovery:​low_level_discovery:​discovered_graphs1.png|}}
  
-{{manual:​discovery:​low_level_discovery:​lld_rules_snmp.png|}}+=== Другие типы обнаружения ===
  
-Когда сервер работает, он создаст реальные ​элементы данных, ​триггеры и графики на основе значений, полученных ​от SNMP правила ​обнаружения. В настройках узлов ​сети ​они будут иметь префикс ссылку оранжевого цвета, которая ведет к правилу обнаружения,​ их создавшего.+Для получения ​более детальных сведений и инструкций по остальным типам доступных обнаружений сморите следующие разделы:
  
-{{manual:​discovery:​low_level_discovery:​discovered_items_snmp.png?​600|}}+  * обнаружение [[: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.
  
-{{manual:​discovery:​low_level_discovery:​discovered_triggers_snmp.png?​600|}}+Для получения более подробных сведений касательно JSON формата по обнаружению элементов данных и примера каким образом реализовать своё собственное обнаружение файловых систем при помощи Perl скрипта,​ смотрите [[#​создание_пользовательских_lld_правил|создание пользовательских LLD правил]].
  
-{{manual:​discovery:​low_level_discovery:​discovered_graphs_snmp.png?​600|}}+== Ограничения данных для возвращаемых значений ==
  
-=== - Обнаружение с использованием ​SQL запросов ​ODBC ===+Ограничения для JSON данных низкоуровневого правила обнаружения отсутствуют, ​если эти данные получены напрямую Zabbix ​сервером,​ так как полученные значения обрабатываются без сохранения в базу данных. Также ограничения отсутствуют и для ​пользовательских правил ​низкоуровневого обнаружения,​ однако,​ если предполагается получение пользовательских LLD данных при помощи пользовательского ​параметра,​ тогда накладывается ограничение по размеру значения (512 КБ) на сам пользовательский параметр.
  
-Этот тип обнаружения осуществляется с использованием SQL запросов, полученные результаты которых автоматически преобразуются в объект JSON, пригодный для низкоуровневого обнаружения. SQL запросы выполняются при помощи элементов данных типа "​Монитор ​баз данных"Так что, большая ​часть указаний ​со страницы ​[[:​ru/​manual/​config/​items/​itemtypes/​odbc_checks|ODBC мониторинга]] применима к получению работающего "​Монитора баз ​данных" правила обнаруженияединственная разница лишь в том, что необходимо использовать ключ "​db.odbc.discovery[<​описание>,<​dsn>​]"​ вместо "​db.odbc.select[<​описание>,<​dsn>​]"​.+Если ​данные поступают от Zabbix прокси, этот прокси вынужден сначала ​записать их в базу данных. ​В таком случае накладываются  ​[[:​ru/​manual/​config/​items/​item#ограничения_текстовых_данных|ограничения ​к базе данных]], ​например2048 байт для Zabbix прокси, который работает с IBM DB2 базой данных.
  
-В качестве практического примераиллюстрирующего как SQL запрос трансформируется в JSON, рассмотрим низкоуровневое обнаружения Zabbix прокси,​ выполнив ODBC запрос в Zabbix базу данных. Он может быть полезен для автоматического создания [[:​ru/​manual/​config/​items/​itemtypes/​internal|внутренних ​элементов данных]] "​zabbix[proxy,<​имя>,​lastaccess]",​ чтобы наблюдать какие прокси живы.+=== Несколько LLD правил по одному и тому же элементу данных ​===
  
-Давайте начнем с настройки правила обнаружения:+Начиная с Zabbix агента версии 3.2, имеется возможность задать несколько правил ​низкоуровневого обнаружения по одному и тому же элементу данных ​обнаружения
  
-{{manual:discovery:​low_level_discovery:​discovery_rule_odbc.png}}+Чтобы это сделать,​ вам необходио указать [[ru/manual/​appendix/​config/​zabbix_agentd|параметр]] агента Alias, разрешив использование измененных ключей элемента данных обнаружения в разных правилах обнаружения,​ например ''​vfs.fs.discovery[foo]'',​ ''​vfs.fs.discovery[bar]''​ и так далее.
  
-Здесь используется следующий прямой запрос в базу данных Zabbix для выборки всех Zabbix прокси вместе с количеством узлов сети, за которыми эти прокси наблюдают. Количество узлов сети можно использовать,​ например,​ для фильтрации пустых прокси:​ 
- 
-<​code>​ 
-mysql> SELECT h1.host, COUNT(h2.host) AS count FROM hosts h1 LEFT JOIN hosts h2 ON h1.hostid = h2.proxy_hostid WHERE h1.status IN (5, 6) 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: 
- 
-<code js> 
-{ 
-    "​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 сервера:​ 
- 
-<​code>​ 
-$ grep db.odbc.discovery /​tmp/​zabbix_server.log 
- ... 
- ​23876:​20150114:​153410.856 In db_odbc_discovery() query:'​SELECT h1.host, COUNT(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}} 
- 
-Как только обнаружение будет выполнено,​ элемент данных будет создан по каждому прокси:​ 
- 
-{{manual:​discovery:​low_level_discovery:​discovered_items_odbc.png}} 
- 
-=== - Обнаружение служб Windows === 
- 
-Обнаружение служб 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// по умолчанию. 
- 
-Макросы {#​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 352: Line 242:
 Чтобы это сделать,​ необходимо создать пользовательский элемент данных,​ который будет возвращать JSON, определяющий найденные объекты и опционально - некоторые свойства этих объектов. Количество макросов на объект не ограничено - в то время как встроенные правила обнаружения возвращают либо один, либо два макроса (нппример,​ два в случае обнаружения файловых систем),​ имеется возможность возвращать больше. Чтобы это сделать,​ необходимо создать пользовательский элемент данных,​ который будет возвращать JSON, определяющий найденные объекты и опционально - некоторые свойства этих объектов. Количество макросов на объект не ограничено - в то время как встроенные правила обнаружения возвращают либо один, либо два макроса (нппример,​ два в случае обнаружения файловых систем),​ имеется возможность возвращать больше.
  
-Требуемый JSON формат лучше всего иллюстрируется в примере. Предположим,​ что мы оставим старый Zabbix агент версии 1.8 (который не поддерживает "​vfs.fs.discovery"​),​ но нам также нужно обнаруживать файловые системы. Вот простой Perl скрипт для Linux, который обнаруживает примонтированные файловые системы и выдает на выходе данные JSON, в которых включено и имя, и тип файловой системы. Одним из способов его использования является UserParameter с ключем "​vfs.fs.discovery_perl":​+Требуемый JSON формат лучше всего иллюстрируется в примере. Предположим,​ что мы оставим старый Zabbix агент версии 1.8 (который не поддерживает "​vfs.fs.discovery"​),​ но нам также нужно обнаруживать файловые системы. Вот простой Perl скрипт для Linux, который обнаруживает примонтированные файловые системы и выдает на выходе данные JSON, в которых включено и имя, и тип файловой системы. Одним из способов его использования является UserParameter с ключом "​vfs.fs.discovery_perl":​
  
 <code perl> <code perl>
Line 359: Line 249:
 $first = 1; $first = 1;
  
-print "{\n";​ +print "​[\n";​
-print "​\t\"​data\":​[\n\n";+
  
 for (`cat /​proc/​mounts`) for (`cat /​proc/​mounts`)
 { {
-    ​($fsname, $fstype) = m/\S+ (\S+) (\S+)/+ ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
-    $fsname =~ s!/!\\/!g;+
  
-    ​print "​\t,​\n"​ if not $first; + print "​\t,​\n"​ if not $first; 
-    $first = 0;+ $first = 0;
  
-    ​print "​\t{\n";​ + print "​\t{\n";​ 
-    print "​\t\t\"​{#​FSNAME}\":​\"​$fsname\",​\n";​ + print "​\t\t\"​{#​FSNAME}\":​\"​$fsname\",​\n";​ 
-    print "​\t\t\"​{#​FSTYPE}\":​\"​$fstype\"​\n";​ + print "​\t\t\"​{#​FSTYPE}\":​\"​$fstype\"​\n";​ 
-    print "​\t}\n";​+ print "​\t}\n";​
 } }
  
-print "\n\t]\n"; +print "​]\n";​
-print "}\n";+
 </​code>​ </​code>​
  
Line 384: Line 271:
 Пример его вывода (переформатирован для наглядности) представлен ниже. JSON данные от пользовательской проверки обнаружения следуют такому же формату. ​ Пример его вывода (переформатирован для наглядности) представлен ниже. JSON данные от пользовательской проверки обнаружения следуют такому же формату. ​
  
-  { +<code javascript>​ 
-    "​data":​+
-     + { "​{#​FSNAME}":"/", ​                          "​{#​FSTYPE}":"​rootfs" ​  }, 
-    ​{ "​{#​FSNAME}":"​\/", ​                          "​{#​FSTYPE}":"​rootfs" ​  }, + { "​{#​FSNAME}":"/​sys", ​                       "​{#​FSTYPE}":"​sysfs" ​   }, 
-    { "​{#​FSNAME}":"​\/​sys", ​                       "​{#​FSTYPE}":"​sysfs" ​   }, + { "​{#​FSNAME}":"/​proc", ​                      "​{#​FSTYPE}":"​proc" ​    }, 
-    { "​{#​FSNAME}":"​\/​proc", ​                      "​{#​FSTYPE}":"​proc" ​    }, + { "​{#​FSNAME}":"/​dev", ​                       "​{#​FSTYPE}":"​devtmpfs"​ }, 
-    { "​{#​FSNAME}":"​\/​dev", ​                       "​{#​FSTYPE}":"​devtmpfs"​ }, + { "​{#​FSNAME}":"/​dev/​pts", ​                   "​{#​FSTYPE}":"​devpts" ​  }, 
-    { "​{#​FSNAME}":"​\/dev\/​pts", ​                  ​"​{#​FSTYPE}":"​devpts" ​  }, + { "​{#​FSNAME}":"/​lib/​init/​rw", ​               "​{#​FSTYPE}":"​tmpfs" ​   }, 
-    { "​{#​FSNAME}":"​\/", ​                          "​{#​FSTYPE}":"​ext3" ​    }, + { "​{#​FSNAME}":"/​dev/​shm", ​                   "​{#​FSTYPE}":"​tmpfs" ​   }, 
-    { "​{#​FSNAME}":"​\/lib\/init\/​rw", ​             "​{#​FSTYPE}":"​tmpfs" ​   }, + { "​{#​FSNAME}":"/​home", ​                      "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/dev\/​shm", ​                  ​"​{#​FSTYPE}":"​tmpfs" ​   }, + { "​{#​FSNAME}":"/​tmp", ​                       "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​home", ​                      "​{#​FSTYPE}":"​ext3" ​    }, + { "​{#​FSNAME}":"/​usr", ​                       "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​tmp", ​                       "​{#​FSTYPE}":"​ext3" ​    }, + { "​{#​FSNAME}":"/​var", ​                       "​{#​FSTYPE}":"​ext3" ​    }, 
-    { "​{#​FSNAME}":"​\/​usr", ​                       "​{#​FSTYPE}":"​ext3" ​    }, + { "​{#​FSNAME}":"/​sys/​fs/​fuse/​connections", ​   "​{#​FSTYPE}":"​fusectl" ​ } 
-    { "​{#​FSNAME}":"​\/​var", ​                       "​{#​FSTYPE}":"​ext3" ​    }, +
-    { "​{#​FSNAME}":"​\/sys\/fs\/fuse\/​connections",​ "​{#​FSTYPE}":"​fusectl" ​ } +</​code>​ 
-     + 
-    ​+В предыдущем примере требуется,​ чтобы ключи совпадали с именами LLD макросов,​ которые используются в прототипах,​ другой способ заключается в извлечении значений LLD макросов с использованием JSONPath ''​{#​FSNAME}''​ -> ''​$.fsname''​ и ''​{#​FSTYPE}''​ -> ''​$.fstype'',​ тем самым можно использовать следующий скрипт:​ 
-  }+ 
 +<code perl> 
 +#​!/​usr/​bin/​perl
    
 +$first = 1;
    
 +print "​[\n";​
 + 
 +for (`cat /​proc/​mounts`)
 +{
 + ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
 + 
 + print "​\t,​\n"​ if not $first;
 + $first = 0;
 + 
 + print "​\t{\n";​
 + print "​\t\t\"​fsname\":​\"​$fsname\",​\n";​
 + print "​\t\t\"​fstype\":​\"​$fstype\"​\n";​
 + print "​\t}\n";​
 +}
 + 
 +print "​]\n";​
 +</​code>​
 +
 +
 +Пример его вывода (переформатирован для наглядности) представлен ниже. JSON данные от пользовательской проверки обнаружения следуют такому же формату. ​
 +<code javascript>​
 +[
 + { "​fsname":"/", ​                          "​fstype":"​rootfs" ​  },
 + { "​fsname":"/​sys", ​                       "​fstype":"​sysfs" ​   },
 + { "​fsname":"/​proc", ​                      "​fstype":"​proc" ​    },
 + { "​fsname":"/​dev", ​                       "​fstype":"​devtmpfs"​ },
 + { "​fsname":"/​dev/​pts", ​                   "​fstype":"​devpts" ​  },
 + { "​fsname":"/​lib/​init/​rw", ​               "​fstype":"​tmpfs" ​   },
 + { "​fsname":"/​dev/​shm", ​                   "​fstype":"​tmpfs" ​   },
 + { "​fsname":"/​home", ​                      "​fstype":"​ext3" ​    },
 + { "​fsname":"/​tmp", ​                       "​fstype":"​ext3" ​    },
 + { "​fsname":"/​usr", ​                       "​fstype":"​ext3" ​    },
 + { "​fsname":"/​var", ​                       "​fstype":"​ext3" ​    },
 + { "​fsname":"/​sys/​fs/​fuse/​connections", ​   "​fstype":"​fusectl" ​ }
 +]
 +</​code>​
 +
 Тогда, в правилах обнаружения в поле "​Фильтр"​ мы можем указать "​{#​FSTYPE}",​ как макрос,​ и "​rootfs|ext3",​ как регулярное выражение. Тогда, в правилах обнаружения в поле "​Фильтр"​ мы можем указать "​{#​FSTYPE}",​ как макрос,​ и "​rootfs|ext3",​ как регулярное выражение.
  
-<​note>​Вы не обязаны использовать имена макросов FSNAME/​FSTYPE в пользовательских правилах низкоуровневого обнаружения,​ вы можете использовать любые другие имена, которые вам нравятся.</​note>​+<​note>​Вы не обязаны использовать имена макросов FSNAME/​FSTYPE в пользовательских правилах низкоуровневого обнаружения,​ вы можете использовать любые другие имена, которые вам нравятся. Когда используется JSONPath, тогда LLD записью будет элемент массива,​ который может быть объектом,​ но он может быть также и другим массивом или значением.</​note>​ 
 + 
 +Обратите внимание на то, что при использовании пользовательского параметра,​ возвращаемые данные ограничены 512 КБ. Для получения более подробных сведений смотрите [[:​ru/​manual/​discovery/​low_level_discovery#​ограничения_данных_для_возвращаемых_значений|ограничения данных для возвращаемых значений LLD]]. 
 + 
 +=== - Использование макросов LLD в контекстах пользовательских макросов === 
 + 
 +Пользовательские макросы [[:​ru/​manual/​config/​macros/​usermacros#​контекст_пользовательских_макросов|с контекстом]] можно использовать для получения более гибких порогов в выражениях триггеров. Разные пороги можно задать на уровне пользовательского макроса и затем их можно использовать в константах триггеров,​ в зависимости от обнаруженного контекста. Обнаруженный контекст появляется,​ когда используемые [[:​ru/​manual/​config/​macros/​lld_macros|макросы низкоуровневого обнаружения]] в макросах раскрываются в реальные значения. 
 + 
 +Для иллюстрации мы можем использовать данные из приведенного примера выше, предположим,​ что будут обнаружены следующие файловые системы:​ ''/'',​ ''/​home'',​ ''/​tmp'',​ ''/​usr'', ​ ''/​var''​. 
 + 
 +Мы можем задать узлу сети прототип триггера на свободное место на диске, где порог выражается при помощи пользовательского макроса с контекстом:​ 
 + 
 +''​{host:​vfs.fs.size[{#​FSNAME},​pfree].last()}<​**{$LOW_SPACE_LIMIT:<​nowiki>"</​nowiki>​{#​FSNAME}<​nowiki>"</​nowiki>​}**''​ 
 + 
 +Затем добавим пользовательские макросы:​ 
 +  * ''​{$LOW_SPACE_LIMIT}''​ **10** 
 +  * ''​{$LOW_SPACE_LIMIT:/​home}''​ **20** 
 +  * ''​{$LOW_SPACE_LIMIT:/​tmp}''​ **50** 
 + 
 +Тогда события сгенерируются,​ когда на файловых системах ''/'',​ ''/​usr''​ и ''/​var''​ станет свободного места на диске меньше чем **10**%, файловой системе ''/​tmp''​ станет свободного места на диске менее чем **50**% или на файловой системе ''/​home''​ станет свободного места на диске менее чем **20**%.