Zabbix Documentation 2.4

2.23.03.23.4In development:4.0Unsupported versions:1.82.02.4

User Tools

Site Tools


Sidebar

ru:manual:discovery:low_level_discovery

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

Обзор

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

В Zabbix поддерживаются три встроенных типа элементов данных для обнаружения:

  • обнаружение файловых систем;
  • обнаружение сетевых интерфейсов;
  • обнаружение CPU и ядер CPU;
  • обнаружение SNMP OID'ов.

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

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

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

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

Элементы данных низкоуровневого обнаружения - vfs.fs.discovery, net.if.discovery поддерживаются Zabbix агентом начиная с версии 2.0.
Элемент данных низкоуровневого обнаружения “system.cpu.discovery” поддерживается Zabbix агентом начиная с версии 2.4.
Обнаружение SNMP OID'ов поддерживается Zabbix сервером и прокси начиная с версии 2.0.

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

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

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

Следующий раздел иллюстрирует весь процесс, описанный выше, в деталях и служит руководством, как осуществлять обнаружения файловых систем, сетевых интерфейсов и SNMP OID'ов. Последний раздел описывает формат JSON элементов данных обнаружения и дает пример того, как реализовать ваш собственный скрипт для обнаружения файловых систем, используя Perl скрипт.

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

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

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

Список шаблонов

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

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

ПараметрОписание
Имя Имя правила обнаружения.
Тип Тип проверки выполняемого обнаружения; должен быть Zabbix агент или Zabbix агент (активный) при обнаружении файловых систем.
Ключ Элемент данных “vfs.fs.discovery” уже встроен в Zabbix агент на многих платформах (для получения более детальных сведений смотрите список поддерживаемых ключей элементов данных), который возвращает список файловых систем, присутствующих в компьютере, и их типы в формате JSON.
Интервал обновления (в сек) Этот фильтр задает как часто Zabbix выполняет обнаружение. В начале, когда вы только настраиваете обнаружение файловых систем, вы можете указать маленький интервал, но как только вы удостоверитесь что всё работает, вы можете установить его в 30 минут или более, потому что обычно файловые системы не меняются очень часто.
Обратите внимание: Если укажите значение равное '0', элемент данных не будет обрабатываться. Однако, если также существует переменный интервал с ненулевым значением, элемент данных будет обрабатываться в течении действия переменного интервала.
Переменные интервалы Вы можете создать исключения из Интервал обновления. Например:
Интервал: 0, Период: 6-7,00:00-24:00 - деактивирует получение данных на выходных. В противном случае будет использоваться интервал обновления по умолчанию.
Если переменные интервалы перекрываются, то будет использоваться наименьшее значение Интервал перекрывающегося периода.
Смотрите страницу Спецификации периодов времени для получения информации о формате Период.
Примечание: Если указано значение равное '0', элемент данных не будет обрабатываться в течении действия переменного интервала и вернется к обработке в соответствии с Периодом обновления, как только переменный интервал завершится.
Период сохранения потерянных ресурсов (дней) Это поле позволяет вам указать как много дней обнаруженный объект будет храниться (не будет удален), как только его состояние обнаружения станет “Не обнаруживается более” (макс 3650 дней).
Обратите внимание: Если значение равно “0”, объекты будут удалены сразу. Использование значения “0” не рекомендуется, так как простое ошибочное изменение фильтра может закончится тем, что объект будет удален вместе со всеми данными истории.
Описание Введите описание.
Состояние Если отмечено, правило будет обрабатываться.

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

ПараметрОписание
Тип вычисления Доступны следующие опции расчета фильтров:
И - должны выполниться все фильтры;
Или - достаточно выполнения одного фильтра;
И/Или - используется И для разных имен макросов и Или с одинаковым именем макроса;
Пользовательское выражение - формула вычисления, введенная пользователем, для оценки условий действия. Она должна включать в себя все условия (представленные в виде прописных букв A, B, C, …) и может включать пробелы, символы табуляции, скобки ( ), and (с учетом регистра), or (с учетом регистра). Ограничено 255 символами. Пользовательское вычисление такое же, как и в условиях действий.
Фильтры Фильтр можно использовать только для генерирования реальных элементов данных, триггеров и графиков конкретных файловых систем. Ожидается использование Расширенные регулярные выражения POSIX. Например, если вы заинтересованы только в файловых системах C:, D: и E:, вы можете поместить {#FSNAME} в поле “Макрос” и регулярное выражение "^C|^D|^E" в текстовые поля “Регулярное выражение”. Фильтрация также возможна по типам файловых систем, при использовании макроса {#FSTYPE} (например, "^ext|^reiserfs").
Вы можете ввести в поле “Регулярное выражение” регулярное выражение или ссылку на глобальное регулярное выражение.
Для проверки регулярного выражения вы можете использовать “grep -E”, например:
for f in ext2 nfs reiserfs smbfs; do echo $f | grep -E '^ext|^reiserfs' || echo "SKIP: $f"; done

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

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

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

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

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

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

Теперь похожим способом мы создадим прототипы триггеров:

И также прототипы графиков:

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

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

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

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

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

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

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

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

Обнаружение сетевых интерфейсов осуществляется таким же образом, как и обнаружение файловых систем, за исключением того, что мы используем ключ правила обнаружения “net.if.discovery” вместо “vfs.fs.discovery” и макрос {#IFNAME} вместо {#FSNAME} в фильтре и в прототипах элементов данных/триггеров/графиков.

Примеры прототипов элементов данных, которые вы можете захотеть создать основываются на “net.if.discovery”: “net.if.in[{#IFNAME},bytes]”, “net.if.out[{#IFNAME},bytes]”.

Смотрите выше для получения информации по поводу фильтра.

3.3 Обнаружение 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}, <информация>]”.

3.4 Обнаружение SNMP OID'ов

В этом примере мы осуществим обнаружение SNMP на коммутаторе. Сначала перейдем в “Настройка” → “Шаблоны”.

Для изменения правил обнаружения шаблона, нажмите на ссылку в колонке “Обнаружение”.

Затем нажмите “Создать правило” и заполните форму, как отображено на снимке экрана ниже.

В отличие от обнаружения файловых систем и сетевых интерфейсов - этот элемент данных не требует наличия ключа “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

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

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

Также как и прототипы триггеров:

И прототипы графиков:

Результат нашего правила обнаружения:

Когда сервер работает, он создаст реальные элементы данных, триггеры и графики на основе значений, полученных от “snmp.discovery”. В настройках узлов сети они будут иметь префикс ссылку золотистого цвета, которая ведет к правилу обнаружения, их создавшего.

3.5 Создание пользовательских 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+)/;
    $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";

Допустимыми символами в именах макросов низкоуровневых правил обнаружения являются 0-9 , A-Z , _ , .

Буквы в нижнем регистре в именах не поддерживаются.

Пример его вывода (переформатирован для наглядности) представлен ниже. 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”, как регулярное выражение.

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