3 Низкоуровневое обнаружение

Обзор

Низкоуровневое обнаружение (LLD) даёт возможность автоматического создания элементов данных, триггеров и графиков для различных объектов на компьютере. Например, Zabbix может автоматически начать мониторить файловые системы или сетевые интерфейсы с вашего устройства, без необходимости создания вручную элементов данных для каждой файловой системы или сетевого интерфейса. Кроме того, в Zabbix имеется возможность настроить удаление ненужных объектов, основываясь на фактических результатах периодически выполняемого обнаружения.

Пользователь имеет возможность определить свои собственные типы обнаружения, обеспечив их функционирование согласно спецификации JSON протокола.

Общая архитектура процессов обнаружения заключается в следующем.

Сначала, пользователь создает правило обнаружения в "Настройка" → "Шаблоны" → колонка "Обнаружение". Правило обнаружения состоит из (1) элемента данных, который осуществляет обнаружение необходимых объектов (например, файловые системы или сетевые интерфейсы) и (2) прототипов элементов данных, триггеров и графиков, которые должны быть созданы на основании полученных значений этого элемента данных.

Элемент данных, который осуществляет обнаружение необходимых объектов, подобен обычным элементам данных, которые видны в других местах: Zabbix сервер запрашивает у Zabbix агента (или любой другой указанный тип элемента данных) значение этого элемента данных, и агент отвечает текстовым значением. Разница в том, что значение, которое возвращает агент, должно содержать список обнаруженных объектов в специальном JSON формате. Хотя детали этого формата важны только для создателей собственных проверок обнаружения, всё же всем необходимо знать, что возвращаемое значение содержит список из пар: макрос → значение. Например, элемент данных "net.if.discovery" может вернуть две пары: "{#IFNAME}" → "lo" и "{#IFNAME}" → "eth0".

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

Когда сервер получает значение элемента данных обнаружения, он смотрит на пару макрос → значение и для каждой пары создает реальные элементы данных, триггеров и графиков, основанных на их прототипах. В приведенном выше примере с "net.if.discovery", сервер будет создавать один набор элементов данных, триггеров и графиков для локального интерфейса "lo" и другой набор для интерфейса "eth0".

Обратите внимание, что начиная с Zabbix 4.2, формат JSON, возвращаемый правилами низкоуровневого обнаружения, был изменен. Больше не ожидается, что JSON будет содержать объект "data". Низкоуровневое обнаружение теперь будет принимать обычный JSON, содержащий массив, чтобы поддерживать новые функции, такие как предобработка значения элемента данных и пользовательские пути к макросам низкоуровневого обнаружения в документе JSON.

Встроенные ключи обнаружения были обновлены, чтобы возвращать массив строк LLD в корне документа JSON. Zabbix автоматически извлечет макрос и значение, если поле массива использует синтаксис {#MACRO} в качестве ключа. Любые новые нативные проверки обнаружения будут использовать новый синтаксис без элементов "data". При обработке значения низкоуровневого обнаружения сначала определяется корень (массив в «$.» Или «$.data»).

Хотя элемент "data" был удален из всех родных элементов данных, связанных с обнаружением, для обеспечения обратной совместимости Zabbix по-прежнему будет принимать нотацию JSON с элементом "data", хотя его использование не рекомендуется. Если JSON содержит объект только с одним элементом массива "data", то он автоматически извлечет содержимое элемента, используя JSONPath $.data. Низкоуровневое обнаружение теперь принимает необязательные пользовательские макросы LLD с пользовательским путем, указанным в синтаксисе JSONPath.

::: notewarning В результате вышеуказанных изменений более новые агенты больше не смогут работать со старым Zabbix-сервером.

::: См. также: Обнаруженные объекты

Настройка низкоуровневого обнаружения

Мы проиллюстрируем низкоуровневое обнаружение на примере обнаружения файловых систем.

Для настройки обнаружения, выполните следующее:

• Перейдите в: Настройка → Шаблоны
• Нажмите на Обнаружение в строке с соответствующим шаблоном

• Нажмите на Создать правило обнаружения в верхнем правом углу экрана
• Заполните диалог правила обнаружения необходимыми деталями

Правило обнаружения

Форма правила обнаружения содержит пять вкладок, представляющих, слева направо, поток данных во время обнаружения:

• Правило обнаружения - указывает, что наиболее важно: встроенный элемент или пользовательский сценарий для извлечения данных обнаружения
• Предварительная обработка - применяет некоторую предварительную обработку к обнаруженным данным
• Макросы LLD - позволяют извлечь некоторые значения макросов для использования в обнаруженных элементах, триггерах и т. д.
• Фильтры - позволяет фильтровать обнаруженные значения
• Переопределения - позволяет изменять элементы, триггеры, графики или прототипы хоста при применении к определенным обнаруженным объектам.

Вкладка Правило обнаружения содержит общие атрибуты правила обнаружения:

Все обязательные поля ввода отмечены красной звёздочкой.

Предобработка

Вкладка Предобработка позволяет определить правила преобразования, применяемые к результату обнаружения. На этом этапе возможно одно или несколько преобразований. Преобразования выполняются в том порядке, в котором они определены. Вся предварительная обработка выполняется Zabbix сервером.

См. также:

• Детали предобработки
• Тестирование предобработки

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

Пользовательские макросы

На вкладке **LLD макросы ** можно указать пользовательские макросы низкоуровневого обнаружения.

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

• Родной ключ vfs.fs.discovery для обнаружения файловой системы возвращает JSON с некоторыми предопределенными макросами LLD, такими как {#FSNAME}, {#FSTYPE}. Эти макросы можно использовать непосредственно в элементах данных, прототипах триггеров (см. следующие разделы страницы); в этом случае задавать пользовательские макросы не требуется;
• Элемент данных агента vfs.fs.get также возвращает JSON с данными файловой системы, но без каких-либо предопределенных макросов LLD. В этом случае вы можете определить макросы самостоятельно и сопоставить их со значениями в JSON, используя JSONPath:

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

Фильтр правила обнаружения

Вкладка Фильтры содержит определения фильтрации правила обнаружения:

Замещения

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

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

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

Настройка операций

Чтобы настроить детали новой операции, нажмите Добавить в блоке операций. Чтобы редактировать существующую операцию, нажмите Изменить рядом с операцией. Откроется всплывающее окно, в котором вы можете редактировать детали операции.

Кнопки диалога

Кнопки в нижней части диалога позволяют выполнить несколько видов операций.

	Добавление правила обнаружения. Эта кнопка доступна только для новых правил обнаружения.
	Обновление свойств правила обнаружения. Эта кнопка доступна только для уже существующих правил обнаружения.
	Создание другого правила обнаружения на основе свойств текущего правила обнанужения.
	Выполнение немедленного обнаружения на основе правила обнаружения. Правило обнаружения должно существовать. Смотрите более подробную информацию. Обратите внимание, что когда обнаружение выполняется немедленно, кэш конфигурации не обновляется, поэтому на результат не повлияют совсем недавние изменения настроек правила обнаружения.
	Удаление правила обнаружения.
	тмена изменения свойств правила обнаружения.

Прототипы элементов данных

Как только правило будет создано, перейдем к элементам данных этого правила и нажмем "Создать прототип", чтобы создать прототип элементов данных. Обратите внимание на то, как используется макрос {#FSNAME}, где требуется указать имя файловой системы. Когда правило будет обрабатываться, этот макрос будет заменен обнаруженной файловой системой.

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

Специфичные для прототипов элементов данных атрибуты:

Мы можем создать несколько прототипов элементов данных для каждой интересующей нас характеристики файловой системы:

Прототипы триггеров

Мы создадим прототипы триггеров похожим способом как и прототипы элементов данных:

Специфичные для прототипов триггеров атрибуты:

Когда будут созданы реальные триггера из их прототипов, возможно потребуется большая гибкость чем использованная константа ('20' в нашем примере) для сравнения в выражении. Смотрите каким образом пользовательские макросы с контекстом могут быть полезны для получения подобной гибкости.

Также вы можете задать зависимости между прототипами триггеров (поддерживается начиная с Zabbix 3.0). Чтобы это сделать, перейдите на вкладку Зависимости. Прототип триггеров может зависеть от другого прототипа триггеров из этого же правила низкоуровневого обнаружения (LLD) или от обычного триггера. Прототип триггеров не может зависеть от прототипа триггеров из другого правила LLD и от триггера созданного другим прототипом триггеров. Прототип триггеров узла сети не может зависеть от триггера из шаблона.

Прототипы графиков

Мы также можем создать прототипы графиков:

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

Обратите внимание: Для получения информации по настройке прототипов узлов сети, смотрите в разделе мониторинга виртуальных машин о настройке прототипов узлов сети.

Обнаруженные объекты

Представленные снимки экрана ниже иллюстрируют как выглядят уже обнаруженные элементы данных, триггера и графики в настройке узла сети. Обнаруженные объекты имеют префикс ссылку золотистого цвета, которая ведет к правилу обнаружения, создавшего эти объекты.

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

Элементы данных (а также, триггеры и графики) созданые с помощью низкоуровневого правила обнаружения невозможно удалить вручную. Тем не менее, они будут удалены автоматически, если обнаруженный объект (файловая система, интерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр). В этом случае они будут удалены спустя некоторое количество дней указанное в поле Период сохранения потерянных ресурсов.

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

Если объекты помечены на удаление, но не были удалены в назначенное время (деактивировано правило обнаружения или элемент данных узла сети), они удалятся при следующем выполнении правила обнаружения.

Объекты, которые содержат другие объекты, которые помечены на удаление, не будут обновлены, если будут изменены на уровне правила обнаружения. Например, триггеры на основе LLD не будут обновлены, если они содержат элементы данных, которые помечены на удаление.

Другие типы обнаружения

Для получения более детальных сведений и инструкций по остальным типам доступных обнаружений сморите следующие разделы:

• обнаружение сетевых интерфейсов;
• обнаружение CPU и ядер CPU;
• обнаружение SNMP OID'ов;
• обнаружение JMX объектов;
• обнаружение с использованием ODBC SQL запросов;
• обнаружение Windows служб;
• обнаружение интерфейсов хостов в Zabbix.

Для получения более подробных сведений касательно JSON формата по обнаружению элементов данных и примера каким образом реализовать своё собственное обнаружение файловых систем при помощи Perl скрипта, смотрите создание пользовательских LLD правил.

Ограничения данных для возвращаемых значений

Ограничения для JSON данных низкоуровневого правила обнаружения отсутствуют, если эти данные получены напрямую Zabbix сервером, так как полученные значения обрабатываются без сохранения в базу данных. Также ограничения отсутствуют и для пользовательских правил низкоуровневого обнаружения, однако, если предполагается получение пользовательских LLD данных при помощи пользовательского параметра, тогда накладывается ограничение по размеру значения (512 КБ) на сам пользовательский параметр.

Если данные поступают от Zabbix прокси, этот прокси вынужден сначала записать их в базу данных. В таком случае накладываются ограничения к базе данных, например, 2048 байт для Zabbix прокси, который работает с IBM DB2 базой данных.

Несколько LLD правил по одному и тому же элементу данных

Начиная с Zabbix агента версии 3.2, имеется возможность задать несколько правил низкоуровневого обнаружения по одному и тому же элементу данных обнаружения.

Чтобы это сделать, вам необходио указать параметр агента Alias, разрешив использование измененных ключей элемента данных обнаружения в разных правилах обнаружения, например vfs.fs.discovery[foo], vfs.fs.discovery[bar] и так далее.

1 Создание пользовательских LLD правил

Также имеется возможность создать полностью пользовательское правило низкоуровневого обнаружения, для обнаружения любого типа объектов - к примеру, баз данных на сервере баз данных.

Чтобы это сделать, необходимо создать пользовательский элемент данных, который будет возвращать JSON, определяющий найденные объекты и опционально - некоторые свойства этих объектов. Количество макросов на объект не ограничено - в то время как встроенные правила обнаружения возвращают либо один, либо два макроса (нппример, два в случае обнаружения файловых систем), имеется возможность возвращать больше.

Требуемый JSON формат лучше всего иллюстрируется в примере. Предположим, что мы оставим старый Zabbix агент версии 1.8 (который не поддерживает "vfs.fs.discovery"), но нам также нужно обнаруживать файловые системы. Вот простой Perl скрипт для Linux, который обнаруживает примонтированные файловые системы и выдает на выходе данные JSON, в которых включено и имя, и тип файловой системы. Одним из способов его использования является UserParameter с ключем "vfs.fs.discovery_perl":

#!/usr/bin/perl
       
       $first = 1;
       
       print "{\n";
       print "\t\"data\":[\n\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\t]\n";
       print "}\n";

Пример его вывода (переформатирован для наглядности) представлен ниже. JSON данные от пользовательской проверки обнаружения следуют такому же формату.

{
         "data":[
         
         { "{#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"  }
         
         ]
       }

Тогда, в правилах обнаружения в поле "Фильтр" мы можем указать "{#FSTYPE}", как макрос, и "rootfs|ext3", как регулярное выражение.

Обратите внимание на то, что при использовании пользовательского параметра, возвращаемые данные ограничены 512 КБ. Для получения более подробных сведений смотрите ограничения данных для возвращаемых значений LLD.

2 Использование макросов LLD в контекстах пользовательских макросов

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

Для иллюстрации мы можем использовать данные из приведенного примера выше, предположим, что будут обнаружены следующие файловые системы: /, /home, /tmp, /usr, /var.

Мы можем задать узлу сети прототип триггера на свободное место на диске, где порог выражается при помощи пользовательского макроса с контекстом:

{host:vfs.fs.size[{#FSNAME},pfree].last()}<{$LOW_SPACE_LIMIT:"{#FSNAME}"}

Затем добавим пользовательские макросы:

• {$LOW_SPACE_LIMIT} 10
• {$LOW_SPACE_LIMIT:/home} 20
• {$LOW_SPACE_LIMIT:/tmp} 50

Тогда события сгенерируются, когда на файловых системах /, /usr и /var станет свободного места на диске меньше чем 10%, файловой системе /tmp станет свободного места на диске менее чем 50% или на файловой системе /home станет свободного места на диске менее чем 20%.