Documentation
Table of Contents
3 Низкоуровневое обнаружение (LLD)
Обзор
Низкоуровневое обнаружение (англ. Low-level discovery, LLD) даёт возможность автоматического создания элементов данных, триггеров и графиков для различных объектов на компьютере. Например, Zabbix может автоматически начать мониторинг файловых систем или сетевых интерфейсов на вашем устройстве, без необходимости создания вручную элементов данных для каждой файловой системы или сетевого интерфейса. Кроме того, в Zabbix имеется возможность настроить удаление ненужных объектов, основываясь на фактических результатах периодически выполняемого обнаружения.
Пользователь имеет возможность определить свои собственные типы обнаружения, обеспечив их функционирование согласно спецификации протокола JSON.
Общая архитектура процессов обнаружения заключается в следующем.
Сначала пользователь создаёт правило обнаружения в Сбор данных → Шаблоны → колонка Обнаружение. Правило обнаружения состоит из (1) элемента данных, который осуществляет обнаружение необходимых объектов (например, файловые системы или сетевые интерфейсы) и (2) прототипов элементов данных, триггеров и графиков, которые должны быть созданы на основании полученных значений этого элемента данных.
Элемент данных, который осуществляет обнаружение необходимых объектов, подобен обычным элементам данных, которые видны в других местах: сервер запрашивает у Zabbix агента (или используя любой другой указанный тип элемента данных) значение этого элемента данных, и агент отвечает текстовым значением. Разница в том, что значение, которое возвращает агент, должно содержать список обнаруженных объектов в формате JSON. Хотя детали этого формата важны только для создателей собственных проверок обнаружения, всё же необходимо знать, что возвращаемое значение содержит список из пар: макрос → значение. Например, элемент данных «net.if.discovery» может вернуть две пары: «{#IFNAME}» → «lo» и «{#IFNAME}» → «eth0».
Эти макросы затем используются в именах, ключах и других полях прототипов, где они заменяются на полученные значения для создания реальных элементов данных, триггеров, графиков и даже узлов сети для каждого обнаруженного объекта. Смотрите полный список опций по использованию LLD-макросов.
Когда сервер получает значение элемента данных обнаружения, он смотрит на пары макрос → значение и для каждой пары создаёт реальные элементы данных, триггеры и графики, основанные на их прототипах. В приведённом выше примере с «net.if.discovery» сервер будет создавать один набор элементов данных, триггеров и графиков для интерфейса обратной петли "lo" и другой набор для интерфейса «eth0».
Обратите внимание, что начиная с Zabbix 4.2 формат JSON, возвращаемого правилами низкоуровневого обнаружения, изменился. Более не ожидается, что JSON будет содержать объект "data". Чтобы поддерживать новые возможности - такие как предобработку значений элементов данных и пользовательские пути к значениям LLD-макросов в документе JSON, - правила LLD теперь будут воспринимать обычный JSON, содержащий массив.
Встроенные ключи обнаружения были обновлены, чтобы возвращать массив строк LLD на корневом уровне документа JSON. Zabbix будет автоматически извлекать макрос и значение, если массив использует синтаксис {#MACRO} как ключ. Любые новые собственные проверки обнаружения будут использовать новый синтаксис без элемента "data". При обработке значения LLD сначала находится корень (массив на уровне $. или $.data).
Хотя элемент "data" был убран из всех собственных элементов данных, относящихся к обнаружению, в целях обратной совместимости Zabbix всё ещё будет воспринимать нотацию JSON с элементом "data", хотя его использование не рекомендуется. Если JSON содержит объект только с одним элементом "data" (массивом), то будет автоматически извлекаться содержимое этого элемента, используя JSONPath $.data. Низкоуровневое обнаружение теперь воспринимает необязательные определённые пользователем LLD-макросы, с настраиваемым путём, указанным с помощью синтаксиса JSONPath.
В результате вышеуказанных изменений новые агенты более не будут способны работать с более старым сервером Zabbix.
Смотрите также: Обнаруженные объекты
Настройка низкоуровневого обнаружения
Мы проиллюстрируем низкоуровневое обнаружение на примере обнаружения файловых систем.
Для настройки обнаружения выполните следующее:
- Перейдите в: Сбор данных → Шаблоны или Узлы сети
- Нажмите на Обнаружение в строке с соответствующим шаблоном / узлом сети
- Нажмите на Создать правило обнаружения в верхнем правом углу экрана
- Заполните диалог правила обнаружения необходимыми деталями
Правило обнаружения
Диалог правила обнаружения содержит пять вкладок, представляющих (слева направо) поток обработки данных во время обнаружения:
- Правило обнаружения - самое главное, определяет встроенный элемент данных или пользовательский сценарий для получения данных обнаружения
- Предобработка - применяет какую-либо предобработку к данным обнаружения
- LLD макросы - позволяет извлечь значения некоторых макросов, чтобы использовать в обнаруженных элементах данных, триггерах и т.д.
- Фильтры - позволяет отфильтровать обнаруженные значения
- Замещения - позволяет изменить прототипы элементов данных, триггеров, графиков или узлов сети, когда они применяются к конкретным найденным объектам
Вкладка Правило обнаружения содержит ключ элемента данных, используемого для обнаружения (а также некоторые общие атрибуты правила обнаружения):
Все обязательные поля ввода отмечены красной звёздочкой.
| Параметр | Описание |
|---|---|
| Имя | Имя правила обнаружения. |
| Тип | Тип проверки выполняемого обнаружения. В данном примере мы используем тип Zabbix агент. Правило обнаружения также может являться зависимым элементом данных, зависящим от обычного элемента данных. Оно не может зависеть от другого правила обнаружения. Для зависимых элементов данных выберите соответствующий тип (Зависимый элемент данных) и укажите основной элемент данных в поле 'Основной элемент данных'. Основной элемент данных должен существовать. |
| Ключ | Введите ключ элемента данных, используемого для обнаружения (до 2048 символов). Например, вы можете использовать встроенный ключ элемента данных «vfs.fs.discovery», который возвращает JSON со списком файловых систем, присутствующих в компьютере, их типов и опций монтирования. Обратите внимание, что другой вариант обраружения файловых систем - это использовать результаты, возвращаемые ключом агента «vfs.fs.get», который поддерживается с версии Zabbix 4.4.5 (смотрите пример). |
| Интервал обновления | Это поле задаёт, как часто Zabbix выполняет обнаружение. Вначале, когда вы только настраиваете обнаружение файловых систем, вы можете указать маленький интервал; но как только вы удостоверитесь, что всё работает, вы можете установить его в 30 минут или более, потому что обычно файловые системы не меняются очень часто. Начиная с Zabbix 3.4.0, поддерживаются суффиксы времени, например 30s, 1m, 2h, 1d. Пользовательские макросы поддерживаются, начиная с Zabbix 3.4.0. Обратите внимание: интервал обновления может быть выставлен в '0', только если существует пользовательский интервал с ненулевым значением. Если укажете значение, равное '0', и пользовательский интервал (переменный или по расписанию) с ненулевым значением существует, элемент данных будет опрашиваться в течение действия пользовательского интервала. Новые правила обнаружения будут проверяться в течение 60 секунд после их создания, если для них не установлен интервал по расписанию или переменный интервал и для Интервала обновления не задано значение 0. Обратите внимание, что уже созданное правило обнаружения можно выполнить незамедлительно нажатием кнопки Выполнить сейчас. |
| Пользовательские интервалы | Вы можете создавать пользовательские правила проверки элемента данных: Переменный - создание исключений из Интервала обновления (интервал с другой частотой обновления) По расписанию - создание пользовательского расписания проверки. Для получения более подробной информации смотрите Пользовательские интервалы. Проверка по расписанию поддерживается, начиная с Zabix 3.0.0. |
| Период сохранения потерянных ресурсов | Это поле позволяет вам указать, как много дней обнаруженный объект будет храниться (не будет удалён), после того как его состояние обнаружения станет "более не обнаруживается" (от 1 часа до 25 лет; либо 0). Начиная с Zabbix 3.4.0, поддерживаются суффиксы времени, например 2h, 1d. Пользовательские макросы поддерживаются, начиная с Zabbix 3.4.0. Обратите внимание: Если значение равно «0», объекты будут удалены сразу. Использование значения «0» не рекомендуется, так как простое ошибочное изменение фильтра может закончится тем, что объект будет удалён вместе со всеми данными истории. |
| Описание | Введите описание. |
| Активировано | Если отмечено, правило будет обрабатываться. |
История правил обнаружения не сохраняется.
Фильтр правила обнаружения
Вкладка Фильтры содержит определения фильтрации правила обнаружения:
| Параметр | Описание |
|---|---|
| Тип вычисления | Доступны следующие опции расчета фильтров: И - должны выполниться все фильтры; Или - достаточно выполнения одного фильтра; И/Или - используется И для разных имен макросов и Или с одинаковым именем макроса; Пользовательское выражение - появляется возможность указать пользовательское вычисление фильтров. Формула должна включать в себя все фильтры из списка. Ограничено 255 символами. |
| Фильтры | Фильтр можно использовать только для генерирования реальных элементов данных, триггеров и графиков конкретных файловых систем. Ожидается использование Perl Compatible Regular Expression (PCRE). Например, если вы заинтересованы только в файловых системах C:, D: и E:, вы можете поместить {#FSNAME} в поле "Макрос" и регулярное выражение "^C|^D|^E" в текстовые поля "Регулярное выражение". Фильтрация также возможна по типам файловых систем, при использовании макроса {#FSTYPE} (например, "^ext|^reiserfs") и по типу диска (поддерживается только Windows агентов), используя макрос {#FSDRIVETYPE} (например, "fixed"). Вы можете ввести в поле "Регулярное выражение" регулярное выражение или ссылку на глобальное регулярное выражение. Для проверки регулярного выражения вы можете использовать "grep -E", например: for f in ext2 nfs reiserfs smbfs; do echo $f \| grep -E '^ext\|^reiserfs' \|\| echo "SKIP: $f"; doneМакрос {#FSDRIVETYPE} на Windows поддерживается начиная с Zabbix 3.0.0.Определение нескольких фильтров поддерживается начиная с 2.4.0. Обратите внимание, что если какой-то макрос из фильтра пропущен в ответе, найденный объект будет игнорироваться. Выпадающее меню в фильтре представлены два значения задать, которые можно использовать для соответствия регулярному выражению или наоборот, отсутствию соответствия. |
Чтобы обнаружение сработало корректно, база данных Zabbix в MySQL должна быть создана чувствительной к регистру, если имена файловых систем различаются только по регистру.
Ошибка или опечатка в регулярном выражении, которое используется в LLD правиле, может привести к удалению тысяч элементов конфигурации, данных истории и событий на большом количестве узлов сети. Например, некорректное регулярное выражение "File systems for discovery" может привести к удалению тысяч элементов данных, триггеров, данных истории и событий.
История правил обнаружения не сохраняется.
Кнопки диалога
Кнопки в нижней части диалога позволяют выполнить несколько видов операций.
 |
Добавление правила обнаружения. Эта кнопка доступна только для новых правил обнаружения. |
 |
Обновление свойств правила обнаружения. Эта кнопка доступна только для уже существующих правил обнаружения. |
 |
Создание другого правила обнаружения на основе свойств текущего правила обнанужения. |
 |
Выполнение немедленного обнаружения на основе правила обнаружения. Правило обнаружения должно существовать. Смотрите более подробную информацию. Обратите внимание, что когда обнаружение выполняется немедленно, кэш конфигурации не обновляется, поэтому на результат не повлияют совсем недавние изменения настроек правила обнаружения. |
 |
Удаление правила обнаружения. |
 |
тмена изменения свойств правила обнаружения. |
Прототипы элементов данных
Как только правило будет создано, перейдем к элементам данных этого правила и нажмем "Создать прототип", чтобы создать прототип элементов данных. Обратите внимание на то, как используется макрос {#FSNAME}, где требуется указать имя файловой системы. Когда правило будет обрабатываться, этот макрос будет заменен обнаруженной файловой системой.
Можно использовать макросы низкоуровневого обнаружения и пользовательские макросы в настройках прототипа элементов данных и в параметрах предварительной обработки значений элемента данных.
Контекстное экранирование макросов низкоуровневого обнаружения для безопасного их использования в регулярных выражениях и параметрах предварительной обработки XPath.
Специфичные для прототипов элементов данных атрибуты:
| Параметр | Описание |
|---|---|
| Новый прототип группы элементов данных | Вы можете задать новый прототип группы элементов данных. В свойствах группы элементов данных вы можете использовать макросы низкоуровневого обнаружения, которые, после выполнения обнаружения, будут заменены реальными значениями при создании групп элементов данных, которые специфичны для обнаруженного объекта. Смотрите также заметки по обнаружению групп элементов данных для получения более подробной информации. |
| Прототипы групп элементов данных | Выберите из существующих прототипов групп элементов данных. |
| Создать активированным | Если выбрано, элемент данных будет создан в активированном состоянии. Если не выбрано, элемент данных будет добавлен как обнаруженный объект, но в деактивированном состоянии. |
Мы можем создать несколько прототипов элементов данных для каждой интересующей нас характеристики файловой системы:
Прототипы триггеров
Мы создадим прототипы триггеров похожим способом как и прототипы элементов данных:
Специфичные для прототипов триггеров атрибуты:
| Параметр | Описание |
|---|---|
| Создать активированным | Если выбрано, триггер будет создан в активированном состоянии. Если не выбрано, триггер будет добавлен как обнаруженный объект, но в деактивированном состоянии. |
Когда будут созданы реальные триггера из их прототипов, возможно потребуется большая гибкость чем использованная константа ('20' в нашем примере) для сравнения в выражении. Смотрите каким образом пользовательские макросы с контекстом могут быть полезны для получения подобной гибкости.
Также вы можете задать зависимости между прототипами триггеров (поддерживается начиная с Zabbix 3.0). Чтобы это сделать, перейдите на вкладку Зависимости. Прототип триггеров может зависеть от другого прототипа триггеров из этого же правила низкоуровневого обнаружения (LLD) или от обычного триггера. Прототип триггеров не может зависеть от прототипа триггеров из другого правила LLD и от триггера созданного другим прототипом триггеров. Прототип триггеров узла сети не может зависеть от триггера из шаблона.
Прототипы графиков
Мы также можем создать прототипы графиков:
В конце концов, мы создали правило обнаружения, которое выглядит как видно ниже. Оно имеет пять прототипов элементов данных, два прототипа триггеров и один прототип графиков.
Обратите внимание: Для получения информации по настройке прототипов узлов сети, смотрите в разделе мониторинга виртуальных машин о настройке прототипов узлов сети.
Обнаруженные объекты
Представленные снимки экрана ниже иллюстрируют как выглядят уже обнаруженные элементы данных, триггера и графики в настройке узла сети. Обнаруженные объекты имеют префикс ссылку золотистого цвета, которая ведет к правилу обнаружения, создавшего эти объекты.
Обратите внимание, что обнаруженные объекты не будут созданы в случае, если объекты с такими же условиями уникальности уже существуют, например, элемент данных с таким же ключем или график с таким же именем.
Элементы данных (а также, триггеры и графики) созданые с помощью низкоуровневого правила обнаружения невозможно удалить вручную. Тем не менее, они будут удалены автоматически, если обнаруженный объект (файловая система, интерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр). В этом случае они будут удалены спустя некоторое количество дней указанное в поле Период сохранения потерянных ресурсов.
Когда обнаруженный объект становится 'Более не обнаруживается', в списке элементов данных будет отображаться оранжевый индикатор времени жизни. Переместите курсор мыши на этот индикатор и вы увидите сообщение с количеством дней до момента удаления элемента данных.
Если объекты помечены на удаление, но не были удалены в назначенное время (деактивировано правило обнаружения или элемент данных узла сети), они удалятся при следующем выполнении правила обнаружения.
Объекты, которые содержат другие объекты, которые помечены на удаление, не будут обновлены, если будут изменены на уровне правила обнаружения. Например, триггеры на основе LLD не будут обновлены, если они содержат элементы данных, которые помечены на удаление.
Другие типы обнаружения
Для получения более детальных сведений и инструкций по остальным типам доступных обнаружений сморите следующие разделы:
- обнаружение сетевых интерфейсов;
- обнаружение CPU и ядер CPU;
- обнаружение SNMP OID'ов;
- обнаружение JMX объектов;
- обнаружение с использованием ODBC SQL запросов;
- обнаружение Windows служб;
- обнаружение интерфейсов хостов в Zabbix.
Для получения более подробных сведений касательно JSON формата по обнаружению элементов данных и примера каким образом реализовать своё собственное обнаружение файловых систем при помощи Perl скрипта, смотрите создание пользовательских LLD правил.