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

Site Tools

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

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

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

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

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

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

User Tools

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

Чтобы настроить правило обнаружения сети используемое в Zabbix для обнаружения узлов сети и сервисов:

Аттрибуты правил

Сценарий из реальной жизни

Допустим, мы хотим настроить обнаружение для локальной сети с IP диапазоном 192.168.1.1-192.168.1.255.

В нашем случае мы хотим получить:

Установим правило обнаружения в сети для нашего диапазона IP адресов.

Zabbix будет пытаться обнаружить узлы сети в диапазоне IP адресов 192.168.1.1-192.168.1.255, пытаясь подключиться к Zabbix агенту и получить значение ключа system.uname. Полученное значение от агента может быть использовано для создания различных действий для разных операционных систем. Например, присоединить шаблон Windows_Template к Windows серверам, шаблон Linux_Template к Linux серверам.

Правило будет выполняться каждые 10 минут (600 секунд).

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

Определим действие для добавления новых обнаруженных Linux серверов в соответвующие группы/шаблоны.

Это действие выполняется если:

Это действие будет выполнять следующие операции:

Определим действие для добавления новых обнаруженных Windows серверов в соответвующие группы/шаблоны.

Определим действия для удаления потерянных серверов.

Сервер будет удален из мониторинга, если сервис “Zabbix агент” будет ‘Недоступен’ на протяжении более 24 часов (86400 секунд).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Обнаружение CPU и ядер CPU выполняется аналогично обнаружению сетевых интерфейсов за исключением того, что ключем правила обнаружения является “system.cpu.discovery”. Этот ключ обнаружения возвращаетс два макроса — <#CPU.NUMBER>и <#CPU.STATUS>, идентифицирующие порядковый номер CPU и состояние соответственно. Отметим, нельзя сделать четкого различия между действительными, физическими процессорами, ядрами и hyperthread. <#CPU.STATUS>на Linux, UNIX и BSD системах возвращают состояние процессора, которое может быть как “online”, так и “offline”. На Windows системах, этот же макрос может представлять собой третье значение — “unknown” — которое указывает на то, что процессор был обнаружен, но информация по нему еще не собрана.

Прототипы элементов данных, которые можно создать на основе обнаружения CPU включают в себя, например, “system.cpu.util[<#CPU.NUMBER>, , ]” и “system.hw.cpu[<#CPU.NUMBER>, ]”.

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

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

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

И зададим SNMP OID равным: discovery[<#IFDESCR>, ifDescr, <#IFPHYSADDRESS>, ifPhysAddress]

Тогда, в случае SNMP обнаружения discovery[<#IFDESCR>, ifDescr, <#IFALIAS>, ifAlias] вернется следующая структура:

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

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

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

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

Этот тип обнаружения осуществляется с использованием SQL запросов, полученные результаты которых автоматически преобразуются в объект JSON, пригодный для низкоуровневого обнаружения. SQL запросы выполняются при помощи элементов данных типа “Монитор баз данных”. Так что, большая часть указаний со страницы ODBC мониторинга применима к получению работающего “Монитора баз данных” правила обнаружения, единственная разница лишь в том, что необходимо использовать ключ “db.odbc.discovery[ , ]” вместо “db.odbc.select[ , ]”.

В качестве практического примера, иллюстрирующего как SQL запрос трансформируется в JSON, рассмотрим низкоуровневое обнаружения Zabbix прокси, выполнив ODBC запрос в Zabbix базу данных. Он может быть полезен для автоматического создания внутренних элементов данных “zabbix[proxy, ,lastaccess]”, чтобы наблюдать какие прокси живы.

Теперь, когда мы понимаем как SQL запрос трансформируется в JSON объект, мы можем использовать макрос <#HOST>в прототипах элементов данных:

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

Макросы <#SERVICE.STATE>и <#SERVICE.STATENAME>возвращают одинаковое содержимое, однако, <#SERVICE.STATE>возвращает числовое значение (0-7), тогда как <#SERVICE.STATENAME>возвращает текст (running, paused, start pending, pause pending, continue pending, stop pending, stopped или unknown). То же самое относится и к <#SERVICE.STARTUP>и <#SERVICE.STARTUPNAME>, где первый возвращает числовое значение (0-4), тогда как второй — текст (automatic, automatic delayed, manual, disabled, unknown).

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

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

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

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

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

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

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

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

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

Table of Contents

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

OID’ы для обнаружения добавляются в поле SNMP OID в следующем формате: discovery[<#МАКРОС1>, oid1, <#МАКРОС2>, oid2, …,]

где , … допустимые имена низкоуровневых макросов и oid1, oid2… являются OID’ами способными сгенерировать осмысленные значения для этих макросов. Встроенный макрос содержит индекс обнаруженного OID, который применяется к обнаруженным объектам. Обнаруженные объекты группируются по значению макроса .

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

Теперь это правило будет обнаруживать объекты с макросом <#IFDESCR>равным WAN, LAN1 и LAN2, макросом <#IFPHYSADDRESS>равным 8:0:27:90:7a:75, 8:0:27:90:7a:76, и 8:0:27:2b:af:9e, макросом <#SNMPINDEX>равным индексам обнаруженных OID 1, 2 и 3:

Если обнаруженный объект не имеет указанный OID, тогда по этому объекту соответстующий макрос пропускается. Например, если у нас есть следующие данные:

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

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

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

Давайте начнем с настройки правила обнаружения:

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

Благодаря внутреннему механизму обработки элемента данных “db.odbc.discovery[]”, результат этого запроса автоматически преобразуется в следующий JSON:

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

В случае, если имя колонки не удается сконвертировать в допустимое имя макроса, правило обнаружения становится неподдерживаемым с детальным сообщением об ошибке какой номер колонки не удалось преобразовать. Если желательна дополнительная помощь, полученные имена колонки отражаются при DebugLevel=4 в файле журнала Zabbix сервера:

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

Обнаружение служб Windows осуществляется тем же самым способом, что и обнаружение файловых систем. Используемым ключем в правиле обнаружения является “service.discovery” и поддерживаются следующие макросы для применения их в фильтре и прототипах элементов данных/триггерах/графиков:

На основе обнаружения служб Windows вы можете создать прототип элементов данных вроде “service.info[<#SERVICE.NAME>, ]”, где парам принимает следующие значения: state, displayname, path, user, startup или description. Например, чтобы получить отображаемое имя службы вам необходимо использовать элемент данных “service.info[<#SERVICE.NAME>,displayname]”. Если значение парам не указано (“service.info[<#SERVICE.NAME>]”), будет использоваться параметр state по умолчанию.

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

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

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

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

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

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

www.zabbix.com