Низкоуровневое обнаружение (LLD)

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

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

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

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

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

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

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

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

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

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

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

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

перейти в "Настройка → Шаблоны или Узлы сети";
нажать на Обнаружение в строке с соответствующим шаблоном / узлом сети;
нажать на Создать правило обнаружения в верхнем правом углу экрана;
заполнить окно правила обнаружения необходимыми деталями.

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

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

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

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

Рисунок 148 — Вкладка "Правило обнаружения"

Описание параметров вкладки приведено в таблице 143.

История правил обнаружения не сохраняется.

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

Вкладка Предобработка позволяет задать правила преобразований, применяемых к результату обнаружения. На этом шаге возможны одно или несколько преобразований (рисунок 149). Преобразования выполняются в том порядке, в котором заданы. Вся предобработка выполняется Сервером.

Рисунок 149 — Вкладка "Предобработка"

Описание параметров вкладки приведено в таблице 144.

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

Настраиваемые макросы

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

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

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

Рисунок 150 — Вкладка "LLD макросы"

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

Описание параметров вкладки приведено в таблице 145.

Фильтры

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

Рисунок 151 — Вкладка "Фильтры"

Описание параметров вкладки приведено в таблице 146.

Ошибка или опечатка в регулярном выражении, которое используется в LLD-правиле (например, некорректное регулярное выражение "File systems for discovery"), может привести к удалению тысяч элементов конфигурации, данных истории и событий на большом количестве узлов сети.

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

Замещения

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

Замещения отображаются в виде списка, позволяющего менять порядок путём перетаскивания, и выполняются в том порядке, в котором они определены. Чтобы настроить детали нового замещения, нужно нажать на Добавить в блоке Замещения. Чтобы отредактировать существующее замещение, нажимают на его имя. Откроется вплывающее окно, позволяющее редактировать детали замещения (рисунок 152).

Рисунок 152 — Вкладка "Замещения"

Описание параметров вкладки приведено в таблице 147.

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

Рисунок 153 — Редактирование операции

Описание параметров операции приведено в таблице 148.

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

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

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

Рисунок 154 — Обнаруженные объекты

Следует обратить внимание, что обнаруженные объекты не будут созданы в случае, если объекты с такими же условиями уникальности уже существуют, например: элемент данных с таким же ключом или график с таким же именем. В таком случае в веб-интерфейсе отобразится сообщение об ошибке, что правило низкоуровневого обнаружения не смогло создать определённые объекты. Само правило обнаружения при этом не станет неподдерживаемым из-за того, что некоторые объекты не могли быть созданы и были пропущены. Правило обнаружения перейдёт к созданию/обновлению других объектов.

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

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

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

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

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

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

Следует обратить внимание на использование макроса {#FSNAME} в имени файловой системы. Использование макросов низкоуровневого обнаружения обязательно в ключе элемента данных для обеспечения правильной обработки обнаружения. При обработке правила обнаружения вместо этого макроса будет подставлена обнаруженная файловая система (рисунок 155).

Рисунок 155 — Создание прототипа элемента данных

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

Контекстно-зависимое экранирование LLD-макросов производится для безопасного использования в регулярных выражениях и параметрах предобработки XPath.

Параметры, специфичные для прототипов элементов данных (таблица 150).

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

Рисунок 156 — Список прототипов

Чтобы открыть меню для конкретного прототипа элемента данных, нужно нажать на иконку с многоточием:

Создать прототип триггера – создать прототип триггера на базе этого прототипа элемента данных;
Прототипы триггера – увидеть список со ссылками на уже настроенные прототипы триггеров, использующие этот прототип элемента данных;
Создать зависимый элемент данных – создать зависимый элемент данных для этого прототипа элемента данных.

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

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

Прототипы триггеров создаются аналогично созданию прототипов элементов данных (рисунок 157).

Рисунок 157 — Создание прототипа триггера

Параметры, специфичные для прототипов триггеров, приведены в таблице 151.

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

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

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

Возможно создание прототипов графиков (рисунок 158).

Рисунок 158 — Прототип графика

Параметры, специфичные для прототипов графиков, приведены в таблице 152.

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

Обнаружение примонтированных файловых систем

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

элемента данных Агента vfs.fs.get в качестве основного элемента данных;
зависимых от него элемента данных для правила низкоуровневого обнаружения и прототипов элементов данных.

Для настройки основного элемента данных создают элемент данных Агента, используя ключ:

vfs.fs.get

Далее задают тип информации как "Текст", чтобы иметь возможность обрабатывать большие данные в формате JSON.

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

{
"fsname": "/",
"fstype": "rootfs",
"bytes": {
"total": 1000,
"free": 500,
"used": 500,
"pfree": 50.00,
"pused": 50.00 },
"inodes": {
"total": 1000,
"free": 500,
"used": 500,
"pfree": 50.00,
"pused": 50.00
}

Для создания зависимого правила LLD низкоуровневого обнаружения нужно выбрать тип "Зависимый элемент данных", в качестве основного элемента данных определить элемент данных vfs.fs.get, на вкладке "LLD Макросы" задать настраиваемые макросы с соответствующими путями JSONPath.

Для создания зависимого прототипа элемента данных нужно выбрать тип "Зависимый элемент данных" в качестве основного элемента данных определить элемент данных vfs.fs.get.

Следует обратить внимание на использование настраиваемых макросов в имени и ключе прототипа элемента данных:

Имя: Free disk space on {#FSNAME}, type: {#FSTYPE};
Ключ: Free{#FSNAME}.

В качестве типа информации используют:

Числовой (целое положительное) для метрик типа "free", "total", "used";
Числовой (с плавающей точной) для метрик типа "pfree", "pused" (проценты).

На вкладке "Предобработка" прототипа элемента данных выбирают JSONPath и используют следующее выражение JSONPath как параметр:

$.[?(@.fsname=="{#FSNAME}")].bytes.free.first()

При запуске обнаружения будет создано по одному элементу данных на каждую точку монтирования. Этот элемент данных вернёт для данной точки монтирования количество свободных байтов.

Обнаружение сетевых интерфейсов

Ключ элемента данных, используемый для правила обнаружения:

net.if.discovery

Можно использовать макрос {#IFNAME} в фильтре правила обнаружения и прототипах элементов данных, триггеров и графиков.

Примеры прототипов элементов данных, которые можно создать на основе "net.if.discovery":

"net.if.in{#IFNAME},bytes";
"net.if.out{#IFNAME},bytes".

Следует обратить внимание, что на платформе Windows также возвращается {#IFGUID}.

Обнаружение CPU и ядер CPU

Ключ элемента данных для использования в правиле обнаружения:

system.cpu.discovery

Этот ключ обнаружения возвращает два макроса:{#CPU.NUMBER} и {#CPU.STATUS}, определяющие порядковый номер CPU и статус соответственно. Следует обратить внимание, что фактически невозможно провести чёткое различие между физическими процессорами, ядрами и гиперпотоками. {#CPU.STATUS} в ОС Linux, UNIX и BSD возвращают статус процессора, который может быть либо "online", либо "offline". В ОС Windows этот же макрос может представлять третье значение "unknown", что указывает на то, что процессор был обнаружен, но информация о нём ещё не собрана.

Обнаружение CPU полагается на процесс сбора данных Агента, чтобы оставаться в соответствии с данными, предоставленными сборщиком, и экономить ресурсы на получение данных. Это приводит к тому, что этот ключ элемента данных не работает с флагом командной строки "test (-t)" бинарного файла Агента, который будет возвращать статус NOT_SUPPORTED и сопроводительное сообщение, указывающее, что процесс сборщика не запущен.

Прототипы элементов данных, которые могут быть созданы на основе обнаружения CPU, например, включают:

system.cpu.util{#CPU.NUMBER},<тип>,<режим>;
system.hw.cpu{#CPU.NUMBER},<инфо>.

Обнаружение SNMP OID

В отличие от обнаружения файловых систем и сетевых интерфейсов элемент данных не обязан иметь ключ "snmp.discovery" – достаточно того, что он будет иметь тип "SNMP Агент".

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

перейти к "Настройка → Шаблоны";
нажать на Обнаружение в строке с соответствующим шаблоном;
нажать на Создать правило обнаружения в правом верхнем углу экрана;
заполнить окно правила обнаружения нужными параметрами (рисунок 159).

Рисунок 159 — Окно правила обнаружения

Идентификаторы объектов (OID) для обнаружения определяются в поле "SNMP OID" в следующем формате:

discovery[{#МАКРОС1}, oid1, {#МАКРОС2}, oid2, …,]

где {#МАКРОС}, {#МАКРОС2} … – это корректные имена LLD-макросов, а oid1, oid2... – OID, способные генерировать осмысленные значения для этих макросов. Ко всем обнаруженным объектам применяется встроенный макрос {#SNMPINDEX}, содержащий индекс обнаруженных OID. Обнаруженные объекты группируются по значению макроса {#SNMPINDEX}.

Во время своей работы Сервер создаст реальные элементы данных, триггеры и графики на основе значений, которые вернёт правило SNMP-обнаружения. В настройках узла сети они будут снабжены префиксом серого цвета, который является ссылкой на породившее их правило обнаружения.

Обнаружение JMX объектов

Существует возможность обнаруживать все JMX MBean или параметры MBean, либо указывать шаблон для обнаружения этих объектов.

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

Например, существует MBean, представляющий веб-сервер. Его параметрами являются количество соединений, количество потоков, тайм-аут запроса, файловый кэш http, использование памяти и т.д.

В настройках правила обнаружения, в поле Тип выбрать "JMX Агент".

Для обнаружения JMX-объектов поддерживаются два ключа элементов данных: jmx.discovery и jmx.get, описанные в таблице 153.

Если не передано никаких параметров, из JMX запрашиваются все параметры MBean. Отсутствие параметров для JMX обнаружения или попытка получить все параметры для широкого диапазона, например =,name=*, может привести к потенциальным проблемам с производительностью.

Элемент данных jmx.discovery возвращает объект JSON с макросами низкоуровневого обнаружения, описывающими объекты MBean или их параметры. Например, при обнаружении параметров MBean attributes (отформатировано для наглядности):

[
{
"{#JMXVALUE}":"0",
"{#JMXTYPE}":"java.lang.Long",
"{#JMXOBJ}":"java.lang:type=GarbageCollector,name=PS Scavenge",
"{#JMXDESC}":"java.lang:type=GarbageCollector,name=PS Scavenge,CollectionCount",
"{#JMXATTR}":"CollectionCount"
},
{
"{#JMXVALUE}":"0",
"{#JMXTYPE}":"java.lang.Long",
"{#JMXOBJ}":"java.lang:type=GarbageCollector,name=PS Scavenge",
"{#JMXDESC}":"java.lang:type=GarbageCollector,name=PS Scavenge,CollectionTime",
"{#JMXATTR}":"CollectionTime"
},
{
"{#JMXVALUE}":"true",
"{#JMXTYPE}":"java.lang.Boolean",
"{#JMXOBJ}":"java.lang:type=GarbageCollector,name=PS Scavenge", "{#JMXDESC}":"java.lang:type=GarbageCollector,name=PS Scavenge,Valid", "{#JMXATTR}":"Valid" }, { "{#JMXVALUE}":"PS Scavenge", "{#JMXTYPE}":"java.lang.String", "{#JMXOBJ}":"java.lang:type=GarbageCollector,name=PS Scavenge", "{#JMXDESC}":"java.lang:type=GarbageCollector,name=PS Scavenge,Name", "{#JMXATTR}":"Name"
},
{
"{#JMXVALUE}":"java.lang:type=GarbageCollector,name=PS Scavenge",
"{#JMXTYPE}":"javax.management.ObjectName",
"{#JMXOBJ}":"java.lang:type=GarbageCollector,name=PS Scavenge",
"{#JMXDESC}":"java.lang:type=GarbageCollector,name=PS Scavenge,ObjectName",
"{#JMXATTR}":"ObjectName"
}
]

При обнаружении объектов MBeans (отформатировано для наглядности):

[
{
"{#JMXDOMAIN}":"java.lang",
"{#JMXTYPE}":"GarbageCollector",
"{#JMXOBJ}":"java.lang:type=GarbageCollector,name=PS Scavenge",
"{#JMXNAME}":"PS Scavenge"
}
]

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

Имеются некоторые ограничения, связанные с алгоритмом создания имён LLD-макросов из имён свойств MBean:

имена параметров приводятся к верхнему регистру;
имена параметров игнорируются (LLD-макросы не генерируются), если они состоят из символов, неподдерживаемых для имён LLD-макросов. Поддерживаемые символы могут быть описаны следующим регулярным выражением: A-Z0-9_\.;
если параметры называются "obj" или "domain", они будут проигнорированы, т.к. перекрываются со значениями зарезервированных в Подсистеме свойств {#JMXOBJ} и {#JMXDOMAIN}.

Элемент данных jmx.get похож на jmx.discovery, но он не превращает свойства объектов Java в имена макросов низкоуровневого обнаружения и поэтому может возвращать значения без ограничений, связанных с генерацией имён LLD-макросов, таких как дефисы или не-ASCII символы.

При использовании jmx.get для обнаружения макросы низкоуровневого обнаружения могут быть определены отдельно на вкладке настраиваемых LLD-макросов настроек правила обнаружения, используя JSONPath для указания на нужные значения.

Элемент данных обнаружения объектов MBean: jmx.getbeans,"com.example:type=,"

Ответ:

[
{
"object": "com.example:type=Hello,data-src=data-base,ключ=значение",
"domain": "com.example",
"properties": {
"data-src": "data-base",
"ключ": "значение",
"type": "Hello"
}
},
{
"object": "com.example:type=Atomic",
"domain": "com.example",
"properties": {
"type": "Atomic"
}
}
]

Элемент данных обнаружения параметров MBean: jmx.getattributes,"com.example:type=,"

Ответ:

[
{
"object": "com.example:type=*",
"domain": "com.example",
"properties": {
"type": "Simple"
}
},
{
"object": "com.zabbix:type=yes,domain=zabbix.com,data-source=/dev/rand,ключ=значение,obj=true",
"domain": "com.zabbix",
"properties": {
"type": "Hello",
"domain": "com.example",
"data-source": "/dev/rand",
"ключ": "значение",
"obj": true
}
}
]

Обнаружение датчиков IPMI

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

элемента данных IPMI ipmi.get в качестве основного элемента данных;
зависимых от него правила низкоуровневого обнаружения и прототипов элементов данных.

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

ipmi.get

Далее выставить тип информации в "Текст", чтобы иметь возможность обрабатывать потенциально большие данные JSON.

Для создания зависимого правила LLD используют тип "Зависимый элемент данных", при этом в качестве основного элемента данных выбирают созданный ранее элемент данных ipmi.get и на вкладке "LLD макросы" определяют настраиваемый макрос с соответствующим JSONPath.

Для создания зависимого прототипа элемента данных выбирают тип "Зависимый элемент данных", в качестве основного элемента данных для этого прототипа выбирают созданный ранее элемент данных ipmi.get.

Следует обратить внимание на использование макроса {#SENSOR_ID} в имени и ключе прототипа элемента данных:

Имя: IPMI value for sensor {#SENSOR_ID};

Ключ: ipmi_sensor{#SENSOR_ID}.

В качестве типа информации выбирают Числовой (целое положительное).

На вкладке "Предобработка" прототипа элемента данных выбирают "JSONPath" и используют следующее выражение JSONPath как параметр:

$.[?(@.id=="{#SENSOR_ID}")].value.first()

При работе обнаружения будет создан один элемент данных на каждый датчик IPMI. Этот элемент данных будет возвращать целочисленное значение для данного датчика.

Обнаружение служб systemd

Для обнаружения модулей "(units) systemd" (службы по умолчанию) с помощью Подсистемы в правиле обнаружения используют ключ элемента данных:

systemd.unit.discovery

Этот ключ элемента данных поддерживается только в Агенте-2.

Этот элемент данных возвращает JSON с информацией о модулях "(units) systemd", например:

[
{
"{#UNIT.NAME}": "mysqld.service",
"{#UNIT.DESCRIPTION}": "MySQL Server",
"{#UNIT.LOADSTATE}": "loaded",
"{#UNIT.ACTIVESTATE}": "active",
"{#UNIT.SUBSTATE}": "running",
"{#UNIT.FOLLOWED}": "",
"{#UNIT.PATH}": "/org/freedesktop/systemd1/unit/mysqld_2eservice",
"{#UNIT.JOBID}": 0,
"{#UNIT.JOBTYPE}": "",
"{#UNIT.JOBPATH}": "/",
"{#UNIT.UNITFILESTATE}": "enabled"
},
{
"{#UNIT.NAME}": "systemd-journald.socket",
"{#UNIT.DESCRIPTION}": "Journal Socket",
"{#UNIT.LOADSTATE}": "loaded",
"{#UNIT.ACTIVESTATE}": "active",
"{#UNIT.SUBSTATE}": "running",
"{#UNIT.FOLLOWED}": "",
"{#UNIT.PATH}": "/org/freedesktop/systemd1/unit/systemd_2djournald_2esocket",
"{#UNIT.JOBID}": 0,
"{#UNIT.JOBTYPE}": "",
"{#UNIT.JOBPATH}": "/",
"{#UNIT.UNITFILESTATE}": "enabled"
}
]

Кроме того, возможно также обнаруживать и деактивированные (disabled) модули systemd. В этом случае в результирующем JSON-е возвращаются три макроса:

{#UNIT.PATH};
{#UNIT.ACTIVESTATE};
{#UNIT.UNITFILESTATE}.

Чтобы из прототипов создавались элементы данных и триггеры для деактивированных модулей systemd, следует убедиться, что подправлены (или удалены) запрещающие фильтры LLD для {#UNIT.ACTIVESTATE} и {#UNIT.UNITFILESTATE}.

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

Прототипы элементов данных, которые могут быть созданы на основе обнаружения служб systemd, включают, например:

Имя элемента данных: {#UNIT.DESCRIPTION} active state info; ключ элемента данных: systemd.unit.info"{#UNIT.NAME}";
Имя элемента данных: {#UNIT.DESCRIPTION} load state info; ключ элемента данных: systemd.unit.info"{#UNIT.NAME}",LoadState.

Обнаружение служб Windows

Ключ элемента данных для использования в правиле обнаружения:

service.discovery

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

На основе обнаружения служб Windows можно создать прототипы элементов данных, например:

service.info[{#SERVICE.NAME},<параметр>]

где параметр принимает следующие значения: state, displayname, path, user, startup или description.

Например, чтобы извлечь отображаемое имя службы, можно использовать элемент данных "service.info{#SERVICE.NAME},displayname". Если значение параметра "service.info{#SERVICE.NAME}" не указано, по умолчанию используется параметр state.

Обнаружение экземпляров счётчиков производительности Windows

Для работы со счётчиками производительности с несколькими экземплярами существует возможность обнаружения экземпляров объектов счётчиков производительности Windows.

Ключ элемента данных для использования в правиле обнаружения:

perf_instance.discovery[объект]

или для указания имени объекта только на английском языке независимо от локализации ОС:

perf_instance_en.discovery[объект]

Например:

perf_instance.discovery[Processor]
perf_instance_en.discovery[Processor]

Обнаружение вернёт все экземпляры указанного объекта в поддерживаемом макросе {#INSTANCE}, который может использоваться в прототипах элементов данных perf_count и perf_count_en items.

[
{"{#INSTANCE}":"0"},
{"{#INSTANCE}":"1"},
{"{#INSTANCE}":"_Total"}
]

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

perf_instance.discovery[Processor]

то можно создать прототип элемента данных:

perf_counter["\Processor({#INSTANCE})\% Processor Time"]

Примечания:
Если указанный объект не найден или не поддерживает экземпляры переменных, то элемент данных обнаружения станет неподдерживаемым.
Если указанный объект поддерживает экземпляры переменных, но в данный момент не имеет никаких экземпляров, то будет возвращён пустой массив JSON.
В случае дублирования экземпляров они будут пропущены.

Обнаружение с использованием запросов WMI

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

Его можно использовать для обнаружения физических дисков и сбора их данных производительности, обнаружения сетевых интерфейсов, обнаружения гостевых систем Hyper-V, мониторинга служб Windows и множества других задач в ОС Windows.

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

Ключ элемента данных, используемый в правиле обнаружения:

wmi.getall[<пространство_имён>,<запрос>]

Этот элемент данных преобразует результат запроса в массив JSON, например:

select * from Win32_DiskDrive where Name like "%PHYSICALDRIVE%"

может вернуть:

[
{
"DeviceID" : "\\.\PHYSICALDRIVE0",
"BytesPerSector" : 512,
"Capabilities" : [
3,
4
],
"CapabilityDescriptions" : [
"Random Access",
"Supports Writing" ],
"Caption" : "VBOX HARDDISK ATA Device",
"ConfigManagerErrorCode" : "0",
"ConfigManagerUserConfig" : "false",
"CreationClassName" : "Win32_DiskDrive",
"Description" : "Disk drive",
"FirmwareRevision" : "1.0",
"Index" : 0,
"InterfaceType" : "IDE"
},
{
"DeviceID" : "\\.\PHYSICALDRIVE1",
"BytesPerSector" : 512,
"Capabilities" : [
3,
4
],
"CapabilityDescriptions" : [
"Random Access",
"Supports Writing"
],
"Caption" : "VBOX HARDDISK ATA Device",
"ConfigManagerErrorCode" : "0",
"ConfigManagerUserConfig" : "false",
"CreationClassName" : "Win32_DiskDrive",
"Description" : "Disk drive",
"FirmwareRevision" : "1.0",
"Index" : 1,
"InterfaceType" : "IDE"
}
]

Несмотря на то что макросы низкоуровневого обнаружения не создаются в возвращаемом JSON, эти макросы могут быть определены пользователем в дополнительном шаге с использованием функциональности настраиваемых LLD-макросов с JSONPath, которые будут указывать на обнаруженные значения в полученном JSON.

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

Обнаружение с использованием запросов ODBC SQL

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

SQL-запросы выполняются при помощи элементов данных типа "Монитор баз данных". В правилах обнаружения "Монитор баз данных" можно использовать два ключа элементов данных:

db.odbc.discovery<уникальное короткое описание>,,<строка подключения> – этот элемент данных преобразует результат SQL-запроса в массив JSON, превращает имена столбцов из результата запроса в имена макросов низкоуровневого обнаружения в парах с обнаруженными значениями полей. Эти макросы можно использовать при создании прототипов элементов данных, триггеров и т.п.;
db.odbc.get<уникальное короткое описание>,,<строка подключения> – этот элемент данных преобразует результат SQL-запроса в массив JSON, сохраняя оригинальные имена столбцов из результата запроса в качестве имён полей в JSON в сочетании с обнаруженными значениями. По сравнению с db.odbc.discovery[] этот элемент данных не создает макросы низкоуровневого обнаружения в возвращаемом JSON, поэтому не требуется проверять, могут ли имена столбцов быть корректными именами макросов. Макросы низкоуровневого обнаружения можно определить дополнительным шагом по мере необходимости, используя функционал настраиваемых макросов с JSONPath, указывающим на обнаруженные значения в полученном JSON.

Обнаружение с использованием данных Prometheus

Данные, представленные в формате строк Prometheus, могут использоваться для низкоуровневого обнаружения.

Правило низкоуровневого обнаружения должно быть создано как зависимый элемент данных от основного элемента данных HTTP, собирающего данные Prometheus.

В правиле обнаружения нужно перейти на вкладку "Предобработка" и выбрать опцию "Prometheus в JSON". Для обнаружения необходимы данные в формате JSON; опция предварительной обработки "Prometheus в JSON" отформатирует их именно таким образом со следующими параметрами:

название метрики (metric name);
значение метрики (metric value);
помощь (help; если имеется);
тип (type; если имеется);
метки (labels; если имеются);
необработанная строка (raw line).

Для сопоставления LLD-макросов нужно перейти на вкладку "LLD макросы" и настроить следующие сопоставления:

{#VOLUME}=$.labels["volume"]
{#METRIC}=$["name"]
{#HELP}=$["help"]

Обнаружение блочных устройств

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

vfs.dev.discovery

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

фильтр {#DEVNAME} совпадает sd\D$ – для обнаружения устройств с именами "sd0", "sd1", "sd2", ...;
фильтр {#DEVTYPE} совпадает disk И {#DEVNAME} не соответствует ^loop.* – для обнаружения типов дисковых устройств чьи имена не начинаются с "loop".

Этот ключ обнаружения возвращает два поддерживаемых макроса: {#DEVNAME} и {#DEVTYPE}, которые задают соответственно имя и тип блочного устройства, например:

[
{
"{#DEVNAME}":"loop1",
"{#DEVTYPE}":"disk"
},
{
"{#DEVNAME}":"dm-0",
"{#DEVTYPE}":"disk"
},
{
"{#DEVNAME}":"sda",
"{#DEVTYPE}":"disk"
},
{
"{#DEVNAME}":"sda1",
"{#DEVTYPE}":"partition"
}
]

Обнаружение блочных устройств позволяет использовать элементы данных vfs.dev.read и vfs.dev.write, чтобы создать прототипы элементов данных с использованием макроса {#DEVNAME}, например:

"vfs.dev.read[{#DEVNAME},sps]";
"vfs.dev.write[{#DEVNAME},sps]".

{#DEVTYPE} предназначен для фильтрации устройств.

Обнаружение интерфейсов узлов сети

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

zabbix[host,discovery,interfaces]

Этот элемент данных возвращает JSON с описаниями интерфейсов, включая:

IP-адрес / DNS-имя узла (в зависимости от опции "Подключение через" у узла сети);
Номер порта;
Тип интерфейса (Агент, SNMP, JMX, IPMI);
Является ли интерфейс интерфейсом по умолчанию или нет;
Активирована ли функция массового опроса – только для SNMP-интерфейсов.

Например:

[{"{#IF.CONN}":"192.168.3.1","{#IF.IP}":"192.168.3.1","{#IF.DNS}":"","{#IF.PORT}":"10050","{#IF.TYPE}":"AGENT","{#IF.DEFAULT}":1}]

При наличии нескольких интерфейсов их записи сортируются в JSON по:

типу интерфейса;
умолчанию – интерфейс по умолчанию помещается до интерфейсов не по умолчанию;
идентификатору (ID) интерфейса (в порядке возрастания).

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

Таблица 157 — Поддерживаемые макросы

Макрос	Описание
`{#IF.CONN}`	IP-адрес или DNS-имя узла интерфейса.
`{#IF.IP}`	IP-адрес интерфейса.
`{#IF.DNS}`	DNS-имя узла интерфейса.
`{#IF.PORT}`	Номер порта интерфейса.
`{#IF.TYPE}`	Тип интерфейса ("AGENT", "SNMP", "JMX" или "IPMI").
`{#IF.DEFAULT}`	Состояние умолчания у интерфейса:– 0 – не является интерфейсом по умолчанию;– 1 – интерфейс по умолчанию.
`{#IF.SNMP.BULK}`	Состояние массовой обработки SNMP у интерфейса:– 0 – деактивировано;– 1 – активировано.Этот макрос возвращается, только если типом интерфейса является "SNMP".

Пользовательские правила LLD

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

Требуемый формат JSON иллюстрируется примером: нужно иметь обнаружение файловых систем. Простой скрипт на Perl для Linux, который обнаруживает смонтированные файловые системы и выводит JSON, содержащий имя файловой системы и её тип, с определением его как UserParameter с ключом "vfs.fs.discovery_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";

Символы, разрешённые в именах LLD-макросов, – это "0-9, A-Z, _". Буквы нижнего регистра в именах макросов не поддерживаются.

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

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

В предыдущем примере требуется, чтобы ключи соответствовали LLD-макросам, используемым в прототипах; альтернатива – извлекать значения LLD-макросов с помощью JSONPath {#FSNAME} → $.fsname и {#FSTYPE} → $.fstype, то можно использовать такой скрипт:

#!/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";

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

[
{ "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" как регулярное выражение.

Не обязательно использовать имена макросов FSNAME/FSTYPE в пользовательских правилах LLD, можно выбирать любые. В случае, если используется JSONPath, строка LLD будет элементом массива, который может являться объектом, но также может быть другим массивом или значением.

Следует обратить внимание, что, если используется пользовательский параметр, возвращаемое значение ограничено 16 МБ.