Zabbix Documentation 2.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
Previous revision
ru:manual:discovery:low_level_discovery [2016/01/07 23:34]
ru:manual:discovery:low_level_discovery [2016/12/10 22:22] (current)
dotneft
Line 1: Line 1:
 +==== - #3 Низкоуровневое обнаружение ====
 +=== Обзор === 
  
 +Низкоуровневое обнаружение (LLD) даёт возможность автоматического создания элементов данных,​ триггеров и графиков для различных объектов на компьютере. Например,​ Zabbix может автоматически начать мониторить файловые системы или сетевые интерфейсы с вашего устройства,​ без необходимости создания вручную элементов данных для каждой файловой системы или сетевого интерфейса. Кроме того, в Zabbix имеется возможность настроить удаление ненужных объектов,​ основываясь на фактических результатах периодически выполняемого обнаружения.
 +
 +В Zabbix поддерживаются три встроенных типа элементов данных для обнаружения:​
 +
 +  * обнаружение файловых систем;​
 +  * обнаружение сетевых интерфейсов;​
 +  * обнаружение CPU и ядер CPU;
 +  * обнаружение SNMP OID'​ов.
 +
 +Пользователь имеет возможность определить свои собственные типы обнаружения,​ обеспечив их функционирование согласно спецификации JSON протокола.
 +
 +Общая архитектура процессов обнаружения заключается в следующем.
 +
 +Сначала,​ пользователь создает правило обнаружения в "​Настройка"​ -> "​Шаблоны"​ -> колонка "​Обнаружение"​. Правило обнаружения состоит из (1) элемента данных,​ который осуществляет обнаружение необходимых объектов (например,​ файловые системы или сетевые интерфейсы) и (2) прототипов элементов данных,​ триггеров и графиков,​ которые должны быть созданы на основании полученных значений этого элемента данных.
 +
 +Элемент данных,​ который осуществляет обнаружение необходимых объектов,​ подобен обычным элементам данных,​ которые видны в других местах:​ 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.</​note>​
 +
 +<​note>​Zabbix прокси на IBM DB2 базе данных имеет ограничение в 2048 байт на возвращаемое значение правил низкоуровневого обнаружения. Это ограничение не распространяется на Zabbix сервер,​ так как возвращаемые значения обрабатываются без предварительной записи в базу данных.</​note>​
 +
 +Эти макросы затем используются в именах,​ ключах и в других полях прототипов,​ которые являются основой для создания реальных элементов данных,​ триггеров и графиков каждому обнаруженному объекту. Смотрите полный список [[:​ru/​manual/​appendix/​macros/​supported_by_location#​макросы_используемые_в_низкоуровневых_обнаружениях|опций]] по использованию макросов в низкоуровневом обнаружении.
 +
 +Когда сервер получает значение элемента данных обнаружения,​ он смотрит на пару макрос -> значение и для каждой пары создает реальные элементы данных,​ триггеров и графиков,​ основанных на их прототипах. В приведенном выше примере с "​net.if.discovery",​ сервер будет создавать один набор элементов данных,​ триггеров и графиков для локального интерфейса "​lo"​ и другой набор для интерфейса "​eth0"​.
 +
 +Следующий раздел иллюстрирует весь процесс,​ описанный выше, в деталях и служит руководством,​ как осуществлять обнаружения файловых систем,​ сетевых интерфейсов и SNMP OID'​ов. Последний раздел описывает формат JSON элементов данных обнаружения и дает пример того, как реализовать ваш собственный скрипт для обнаружения файловых систем,​ используя Perl скрипт.
 +
 +=== - Обнаружение файловых систем ===
 +
 +Для настройки обнаружения файловых систем,​ сделайте следующее:​
 +
 +  * Перейдите в: //​Настройки//​ -> //​Шаблоны//  ​
 +  * Нажмите на //​Обнаружение//​ в строке соответствующего шаблона
 +
 +{{manual:​discovery:​low_level_discovery:​fs_templates.png?​800|Список шаблонов}}
 +
 +  * Нажмите на //​Создать правило обнаружения//​ в верхнем правом углу экрана
 +  * Заполните диалог следующими деталями
 +
 +Вкладка **Правило обнаружения** содержит общие атрибуты правила обнаружения:​
 +
 +{{manual:​discovery:​low_level_discovery:​lld_rule_fs.png?​570|}}
 +
 +^Параметр^Описание^ ​
 +|//​Имя// ​ |Имя правила обнаружения. ​ | 
 +|//​Тип// ​ |Тип проверки выполняемого обнаружения;​ должен быть //Zabbix агент//​ или //Zabbix агент (активный)//​ при обнаружении файловых систем. ​ | 
 +|//​Ключ// ​ |Элемент данных "​vfs.fs.discovery"​ уже встроен в Zabbix агент на многих платформах (для получения более детальных сведений смотрите [[ru:​manual:​appendix:​items:​supported_by_platform|список поддерживаемых ключей элементов данных]]),​ который возвращает список файловых систем,​ присутствующих в компьютере,​ и их типы в формате JSON.  | 
 +|//​Интервал обновления (в сек)// ​ |Этот фильтр задает как часто Zabbix выполняет обнаружение. В начале,​ когда вы только настраиваете обнаружение файловых систем,​ вы можете указать маленький интервал,​ но как только вы удостоверитесь что всё работает,​ вы можете установить его в 30 минут или более, потому что обычно файловые системы не меняются очень часто.\\ //​Обратите внимание//:​ Если укажите значение равное '​0',​ элемент данных не будет обрабатываться. Однако,​ если также существует переменный интервал с ненулевым значением,​ элемент данных будет обрабатываться в течении действия переменного интервала. ​ | 
 +|//​Переменные интервалы// ​ |Вы можете создать исключения из //​Интервал обновления//​. Например:​\\ Интервал:​ **0**, Период:​ **6-7,​00:​00-24:​00** - деактивирует получение данных на выходных. В противном случае будет использоваться интервал обновления по умолчанию.\\ Если переменные интервалы перекрываются,​ то будет использоваться наименьшее значение //​Интервал//​ перекрывающегося периода.\\ Смотрите страницу [[ru:​manual:​appendix:​time_period|Спецификации периодов времени]] для получения информации о формате //​Период//​.\\ //​Примечание//:​ Если указано значение равное '​0',​ элемент данных не будет обрабатываться в течении действия переменного интервала и вернется к обработке в соответствии с //​Периодом обновления//,​ как только переменный интервал завершится. ​ | 
 +|//​Период сохранения потерянных ресурсов (дней)// ​ |Это поле позволяет вам указать как много дней обнаруженный объект будет храниться (не будет удален),​ как только его состояние обнаружения станет "Не обнаруживается более"​ (макс 3650 дней). \\ //​Обратите внимание://​ Если значение равно "​0",​ объекты будут удалены сразу. Использование значения "​0"​ не рекомендуется,​ так как простое ошибочное изменение фильтра может закончится тем, что объект будет удален вместе со всеми данными истории. ​  ​| ​
 +|//​Описание// ​ |Введите описание. ​ | 
 +|//​Состояние// ​ |Если отмечено,​ правило будет обрабатываться. |
 +
 +Вкладка **Фильтры** содержит определения фильтрации правила обнаружения:​
 +
 +{{manual:​discovery:​low_level_discovery:​lld_rule_fs2.png|}}
 +
 +^Параметр^Описание^
 +|//Тип вычисления// ​ |Доступны следующие опции расчета фильтров:​\\ **И** - должны выполниться все фильтры;​\\ **Или** - достаточно выполнения одного фильтра;​\\ **И/​Или** - используется //И// для разных имен макросов и //Или// с одинаковым именем макроса;​\\ **Пользовательское выражение** - формула вычисления,​ введенная пользователем,​ для оценки условий действия. Она должна включать в себя все условия (представленные в виде прописных букв A, B, C, ...) и может включать пробелы,​ символы табуляции,​ скобки ( ), **and** (с учетом регистра),​ **or** (с учетом регистра). Ограничено 255 символами. Пользовательское вычисление такое же, как и в  [[:​ru/​manual/​config/​notifications/​action/​conditions#​тип_вычисления|условиях]] действий. ​ |
 +|//​Фильтры// ​ | Фильтр можно использовать только для генерирования реальных элементов данных,​ триггеров и графиков конкретных файловых систем. Ожидается использование [[ru:​manual:​regular_expressions|Расширенные регулярные выражения POSIX]]. Например,​ если вы заинтересованы только в файловых системах C:, D: и E:, вы можете поместить {#FSNAME} в поле "​Макрос"​ и регулярное выражение <​nowiki>"​^C|^D|^E"</​nowiki>​ в текстовые поля "​Регулярное выражение"​. Фильтрация также возможна по типам файловых систем,​ при использовании макроса {#FSTYPE} (например,​ <​nowiki>"​^ext|^reiserfs"</​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>​Определение нескольких фильтров поддерживается начиная с **2.4.0**.\\ Обратите внимание,​ что если какой-то макрос из фильтра пропущен в ответе,​ найденный объект будет игнорироваться. ​ |
 +
 +<note important>​База данных Zabbix в MySQL должна быть создана чувствительной к регистру,​ если имена файловых систем различаются только по регистру,​ чтобы обнаружение сработало корректно.</​note>​
 + 
 +<​note>​История правил обнаружения не сохраняется.</​note>​
 +
 +Как только правило будет создано,​ перейдем к элементам данных этого правила и нажмем "​Создать прототип",​ чтобы создать прототип элементов данных. Обратите внимание на то, как используется макрос {#FSNAME}, где требуется указать имя файловой системы. Когда правило будет обрабатываться,​ этот макрос будет заменен обнаруженной файловой системой.
 +
 +{{manual:​discovery:​low_level_discovery:​item_prototype_fs.png?​570|}}
 +
 +<​note>​Если прототип элемента данных создан с состоянием //​Деактивирован//,​ то он будет добавлен как обнаруженный объект,​ но в деактивированном состоянии.</​note>​
 +
 +Мы можем создать несколько прототипов элементов данных для каждой интересующей нас характеристики файловой системы:​
 +
 +{{manual:​discovery:​low_level_discovery:​item_prototypes_fs.png?​600|}}
 +
 +Теперь похожим способом мы создадим прототипы триггеров:​
 +
 +{{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png?​550|}}
 +
 +{{manual:​discovery:​low_level_discovery:​trigger_prototypes_fs.png?​600|}}
 +
 +И также прототипы графиков:​
 +
 +{{manual:​discovery:​low_level_discovery:​graph_prototype_fs.png?​600|}}
 +
 +{{manual:​discovery:​low_level_discovery:​graph_prototypes_fs.png?​600|}}
 +
 +В конце концов,​ мы создали правило обнаружения,​ которое выглядит как видно ниже. Оно имеет пять прототипов элементов данных,​ два прототипа триггеров и один прототип графика.
 +
 +{{manual:​discovery:​low_level_discovery:​lld_rules_fs.png?​600|}}
 +
 +//​Обратите внимание//:​ Для получения информации по настройке прототипов узлов сети, смотрите в разделе мониторинга виртуальных машин о настройке [[:​ru/​manual/​vm_monitoring#​прототипы_узлов_сети|прототипов узлов сети]].
 +
 +Представленные снимки экрана ниже иллюстрируют как выглядят уже обнаруженные элементы данных,​ триггера и графики в настройке узла сети. Обнаруженные объекты имеют префикс ссылку золотистого цвета, которая ведет к правилу обнаружения,​ создавшего эти объекты.
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_items.png?​600|}}
 +
 +Обратите внимание,​ что обнаруженные объекты не будут созданы в случае,​ если объекты с такими же условиями уникальности уже существуют,​ например,​ элемент данных с таким же ключем или график с таким же именем.
 +
 +Элементы данных (а также, триггеры и графики) созданные с помощью низкоуровневого правила обнаружения невозможно удалить вручную. Тем не менее, они будут удалены автоматически,​ если обнаруженный объект (файловая система,​ интерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр). В этом случае они будут удалены спустя некоторое количество дней указанное в поле //​Период сохранения потерянных ресурсов//​.
 +
 +Когда обнаруженный объект становится '​Более не обнаруживается',​ в списке элементов данных будет отображаться оранжевый индикатор времени жизни. Переместите курсор мыши на этот индикатор и вы увидите сообщение с количеством дней до момента удаления элемента данных.
 +
 +{{manual:​discovery:​1.9.9_lifetime_indicator.png|}}
 +
 +Если объекты отмечены на удаление,​ но не были удалены в назначенное время (деактивировано правило обнаружения или элемент данных узла сети), они удалятся при следующем выполнении правила обнаружения.
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_triggers.png?​600|}}
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_graphs.png?​600|}}
 +
 +=== - Обнаружение сетевых интерфейсов ===
 +
 +Обнаружение сетевых интерфейсов осуществляется таким же образом,​ как и обнаружение файловых систем,​ за исключением того, что мы используем ключ правила обнаружения "​net.if.discovery"​ вместо "​vfs.fs.discovery"​ и макрос {#IFNAME} вместо {#FSNAME} в фильтре и в прототипах элементов данных/​триггеров/​графиков.
 +
 +Примеры прототипов элементов данных,​ которые вы можете захотеть создать основываются на "​net.if.discovery":​ "​net.if.in[{#​IFNAME},​bytes]",​ "​net.if.out[{#​IFNAME},​bytes]"​.
 +
 +[[#​обнаружение_файловых_систем|Смотрите выше]] для получения информации по поводу фильтра.
 +=== - Обнаружение CPU и ядер CPU ===
 +
 +Обнаружение CPU и ядер CPU выполняется аналогично обнаружению сетевых интерфейсов за исключением того, что ключем правила обнаружения является "​system.cpu.discovery"​. Этот ключ обнаружения возвращаетс два макроса - {#​CPU.NUMBER} и {#​CPU.STATUS},​ идентифицирующие порядковый номер CPU и состояние соответственно. Отметим,​ нельзя сделать четкого различия между действительными,​ физическими процессорами,​ ядрами и hyperthread. {#​CPU.STATUS} на Linux, UNIX и BSD системах возвращают состояние процессора,​ которое может быть как "​online",​ так и "​offline"​. На Windows системах,​ этот же макрос может представлять собой третье значение - "​unknown"​ - которое указывает на то, что процессор был обнаружен,​ но информация по нему еще не собрана.
 +
 +Обнаружение CPU основано на процессе коллектора агента,​ чтобы поддерживать соответствие с данными,​ которые поставляются коллектором и сохранить ресурсы на получение данных. Такое поведение дает эффект,​ что этот ключ элемента данных не работает с флагом командой строки тестирования (-t) бинарного файла, который возвращает состояние NOT_SUPPORTED и сопутствующее сообщение о том, что процесс коллектора не запущен.
 +
 +Прототипы элементов данных,​ которые можно создать на основе обнаружения CPU включают в себя "​system.cpu.util[{#​CPU.NUMBER},​ <​тип>,​ <​режим>​]"​ и "​system.hw.cpu[{#​CPU.NUMBER},​ <​информация>​]"​.
 +
 +=== - Обнаружение SNMP OID'​ов ===
 +
 +В этом примере мы осуществим обнаружение SNMP на коммутаторе. Сначала перейдем в "​Настройка"​ -> "​Шаблоны"​.
 +
 +{{manual:​discovery:​low_level_discovery:​templates_snmp.png?​600|}}
 +
 +Для изменения правил обнаружения шаблона,​ нажмите на ссылку в колонке "​Обнаружение"​.
 +
 +Затем нажмите "​Создать правило"​ и заполните форму, как отображено на снимке экрана ниже.
 +
 +В отличие от обнаружения файловых систем и сетевых интерфейсов - этот элемент данных не требует наличия ключа "​snmp.discovery",​ достаточно указать,​ что типом элемента данных является SNMP агент.
 +
 +Также в отличие от предыдущих примеров,​ этот элемент данных обнаружения генерирует два макроса для каждого обнаруженного объекта:​ {#​SNMPINDEX} и {#​SNMPVALUE}. В случае если вы хотите отфильтровать локальные интерфейсы из полученных значений вам следует поместить "​{#​SNMPVALUE}"​ в фильтр "​Макрос"​ и регулярное выражение "​^([^l]|l$)[^o]?"​ в текстовое поле "​Регулярное выражение"​. [[#​обнаружение_файловых_систем|Смотрите выше]] для получения дополнительной информации об этом фильтре.
 +
 +В поле "SNMP OID" мы должны поместить OID, который способен сгенерировать значения,​ значимые значения этих макросов.
 +
 +Для понимания что имеется ввиду, давайте выполним 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
 +
 +Макрос {#​SNMPINDEX} возьмет свое значение из части OID, которая идет после ifDescr (в этом примере:​ 1, 2, 3). Макрос {#​SNMPVALUE} возьмет свое значение из соответствующего значения OID (в этом примере:​ WAN, LAN1, LAN2). Таким образом,​ наш элемент данных "​snmp.discovery"​ должен вернуть три набора пар макрос -> значение:​
 +
 +  {#​SNMPINDEX} -> 1   ​{#​SNMPVALUE} -> WAN
 +  {#​SNMPINDEX} -> 2   ​{#​SNMPVALUE} -> LAN1
 +  {#​SNMPINDEX} -> 3   ​{#​SNMPVALUE} -> LAN2
 +
 +{{manual:​discovery:​low_level_discovery:​lld_rule_snmp.png|}}
 +
 +Представленный снимок экрана иллюстрирует как мы можем использовать эти макросы в прототипах элементов данных:​
 +
 +{{manual:​discovery:​low_level_discovery:​item_prototype_snmp.png?​570|}}
 +
 +Опять же, создадим столько прототипов элементов данных,​ сколько необходимо:​
 +
 +{{manual:​discovery:​low_level_discovery:​item_prototypes_snmp.png?​600|}}
 +
 +Также как и прототипы триггеров:​
 +
 +{{manual:​discovery:​low_level_discovery:​trigger_prototype_snmp.png?​550|}}
 +
 +{{manual:​discovery:​low_level_discovery:​trigger_prototypes_snmp.png?​600|}}
 +
 +И прототипы графиков:​
 +
 +{{manual:​discovery:​low_level_discovery:​graph_prototype_snmp.png?​600|}}
 +
 +{{manual:​discovery:​low_level_discovery:​graph_prototypes_snmp.png?​600|}}
 +
 +Результат нашего правила обнаружения:​
 +
 +{{manual:​discovery:​low_level_discovery:​lld_rules_snmp.png?​600|}}
 +
 +Когда сервер работает,​ он создаст реальные элементы данных,​ триггеры и графики на основе значений,​ полученных от "​snmp.discovery"​. В настройках узлов сети они будут иметь префикс ссылку золотистого цвета, которая ведет к правилу обнаружения,​ их создавшего.
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_items_snmp.png?​600|}}
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_triggers_snmp.png?​600|}}
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_graphs_snmp.png?​600|}}
 +
 +=== - Создание пользовательских LLD правил ===
 +
 +Также имеется возможность создать полностью пользовательское правило низкоуровневого обнаружения,​ для обнаружения любого типа объектов - к примеру,​ баз данных на сервере баз данных.
 +
 +Чтобы это сделать,​ необходимо создать пользовательский элемент данных,​ который будет возвращать JSON, определяющий найденные объекты и опционально - некоторые свойства этих объектов. Количество макросов на объект не ограничено - в то время как встроенные правила обнаружения возвращают либо один, либо два макроса (нппример,​ два в случае обнаружения файловых систем),​ имеется возможность возвращать больше.
 +
 +Требуемый JSON формат лучше всего иллюстрируется в примере. Предположим,​ что мы оставим старый Zabbix агент версии 1.8 (который не поддерживает "​vfs.fs.discovery"​),​ но нам также нужно обнаруживать файловые системы. Вот простой Perl скрипт для Linux, который обнаруживает примонтированные файловые системы и выдает на выходе данные JSON, в которых включено и имя, и тип файловой системы. Одним из способов его использования является UserParameter с ключем "​vfs.fs.discovery_perl":​
 +
 +<code perl>
 +#​!/​usr/​bin/​perl
 +
 +$first = 1;
 +
 +print "​{\n";​
 +print "​\t\"​data\":​[\n\n";​
 +
 +for (`cat /​proc/​mounts`)
 +{
 +    ($fsname, $fstype) = m/\S+ (\S+) (\S+)/;
 +    $fsname =~ s!/!\\/!g;
 +
 +    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\t]\n";​
 +print "​}\n";​
 +</​code>​
 +
 +<note important>​Допустимыми символами в именах макросов низкоуровневых правил обнаружения являются **0-9** , **A-Z** , **_** , **.** \\ \\  Буквы в нижнем регистре в именах не поддерживаются.</​note>​
 +
 +Пример его вывода (переформатирован для наглядности) представлен ниже. JSON данные от пользовательской проверки обнаружения следуют такому же формату. ​
 +
 +  {
 +    "​data":​[
 +    ​
 +    { "​{#​FSNAME}":"​\/", ​                          "​{#​FSTYPE}":"​rootfs" ​  },
 +    { "​{#​FSNAME}":"​\/​sys", ​                       "​{#​FSTYPE}":"​sysfs" ​   },
 +    { "​{#​FSNAME}":"​\/​proc", ​                      "​{#​FSTYPE}":"​proc" ​    },
 +    { "​{#​FSNAME}":"​\/​dev", ​                       "​{#​FSTYPE}":"​devtmpfs"​ },
 +    { "​{#​FSNAME}":"​\/​dev\/​pts", ​                  "​{#​FSTYPE}":"​devpts" ​  },
 +    { "​{#​FSNAME}":"​\/", ​                          "​{#​FSTYPE}":"​ext3" ​    },
 +    { "​{#​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" ​ }
 +    ​
 +    ]
 +  }
 + 
 + 
 +Тогда, в правилах обнаружения в поле "​Фильтр"​ мы можем указать "​{#​FSTYPE}",​ как макрос,​ и "​rootfs|ext3",​ как регулярное выражение.
 +
 +<​note>​Вы не обязаны использовать имена макросов FSNAME/​FSTYPE в пользовательских правилах низкоуровневого обнаружения,​ вы можете использовать любые другие имена, которые вам нравятся.</​note>​