Zabbix Documentation 2.2

3.04.04.45.0 (current)| In development:5.2 (devel)| Unsupported:1.82.02.22.43.23.44.2Guidelines

User Tools

Site Tools


ru:manual:discovery:low_level_discovery

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Previous revision
ru:manual:discovery:low_level_discovery [2016/01/12 20:16]
ru:manual:discovery:low_level_discovery [2018/03/08 18:45] (current)
dotneft
Line 1: Line 1:
 +==== - #3 Низкоуровневое обнаружение ====
 +=== Обзор === 
  
 +Низкоуровневое обнаружение (LLD) даёт возможность автоматического создания элементов данных,​ триггеров и графиков для различных объектов на компьютере. Например,​ Zabbix может автоматически начать мониторить файловые системы или сетевые интерфейсы с вашего устройства,​ без необходимости создания вручную элементов данных для каждой файловой системы или сетевого интерфейса. Кроме того, в Zabbix имеется возможность настроить удаление ненужных объектов,​ основываясь на фактических результатах периодически выполняемого обнаружения.
 +
 +В Zabbix поддерживаются три встроенных типа элементов данных для обнаружения:​
 +
 +  * обнаружение файловых систем;​
 +  * обнаружение сетевых интерфейсов;​
 +  * обнаружение SNMP OID'​ов.
 +
 +Пользователь имеет возможность определить свои собственные типы обнаружения,​ обеспечив их функционирование согласно спецификации JSON протокола.
 +
 +Общая архитектура процессов обнаружения заключается в следующем.
 +
 +Сначала,​ пользователь создает правило обнаружения в "​Настройка"​ -> "​Шаблоны"​ -> колонка "​Обнаружение"​. Правило обнаружения состоит из (1) элемента данных,​ который осуществляет обнаружение необходимых объектов (например,​ файловые системы или сетевые интерфейсы) и (2) прототипов элементов данных,​ триггеров и графиков,​ которые должны быть созданы на основании полученных значений этого элемента данных.
 +
 +Элемент данных,​ который осуществляет обнаружение необходимых объектов,​ подобен обычным элементам данных,​ которые видны в других местах:​ Zabbix сервер запрашивает у Zabbix агента (или любой другой указанный тип элемента данных) значение этого элемента данных,​ и агент отвечает текстовым значением. Разница в том, что значение,​ которое возвращает агент, должно содержать список обнаруженных объектов в специальном JSON формате. Хотя детали этого формата важны только для создателей собственных проверок обнаружения,​ всё же всем необходимо знать, что возвращаемое значение содержит список из пар: макрос -> значение. Например,​ элемент данных "​net.if.discovery"​ может вернуть две пары: "​{#​IFNAME}"​ -> "​lo"​ и "​{#​IFNAME}"​ -> "​eth0"​.
 +
 +<​note>​Элементы данных низкоуровневого обнаружения - vfs.fs.discovery,​ net.if.discovery поддерживаются Zabbix агентом начиная с версии 2.0.\\ Обнаружение ​ SNMP OID'​ов поддерживается Zabbix сервером и прокси начиная с версии 2.0.</​note>​
 +
 +<​note>​Zabbix прокси на IBM DB2 базе данных имеет ограничение в 2048 байт на возвращаемое значение правил низкоуровневого обнаружения. Это ограничение не распространяется на Zabbix сервер,​ так как возвращаемые значения обрабатываются без предварительной записи в базу данных.</​note>​
 +
 +Эти макросы затем используются в именах,​ ключах и в других полях прототипов,​ которые являются основой для создания реальных элементов данных,​ триггеров и графиков каждому обнаруженному объекту. Смотрите полный список [[:​ru/​manual/​appendix/​macros/​supported_by_location#​макросы_используемые_в_низкоуровневых_обнаружениях|опций]] по использованию макросов в низкоуровневом обнаружении.
 +
 +Когда сервер получает значение элемента данных обнаружения,​ он смотрит на пару макрос -> значение и для каждой пары создает реальные элементы данных,​ триггеров и графиков,​ основанных на их прототипах. В приведенном выше примере с "​net.if.discovery",​ сервер будет создавать один набор элементов данных,​ триггеров и графиков для локального интерфейса "​lo"​ и другой набор для интерфейса "​eth0"​.
 +
 +Следующий раздел иллюстрирует весь процесс,​ описанный выше, в деталях и служит руководством,​ как осуществлять обнаружения файловых систем,​ сетевых интерфейсов и SNMP OID'​ов. Последний раздел описывает формат JSON элементов данных обнаружения и дает пример того, как реализовать ваш собственный скрипт для обнаружения файловых систем,​ используя Perl скрипт.
 +
 +=== - Обнаружение файловых систем ===
 +
 +Для настройки обнаружения файловых систем,​ сделайте следующее:​
 +
 +  * Перейдите в: //​Настройки//​ -> //​Шаблоны//  ​
 +  * Нажмите на //​Обнаружение//​ в строке соответствующего шаблона
 +
 +{{fs_templates.png?​800|Список шаблонов}}
 +
 +  * Нажмите на //​Создать правило обнаружения//​ в верхнем правом углу экрана
 +  * Заполните диалог следующими деталями
 +
 +{{lld_rule_fs.png?​570|}}
 +
 +^Параметр^Описание^ ​
 +|//​Имя// ​ |Имя правила обнаружения. ​ | 
 +|//​Тип// ​ |Тип проверки выполняемого обнаружения;​ должен быть //Zabbix агент//​ или //Zabbix агент (активный)//​ при обнаружении файловых систем. ​ | 
 +|//​Ключ// ​ |Элемент данных "​vfs.fs.discovery"​ уже встроен в Zabbix агент на многих платформах (для получения более детальных сведений смотрите [[ru:​manual:​appendix:​items:​supported_by_platform|список поддерживаемых ключей элементов данных]]),​ который возвращает список файловых систем,​ присутствующих в компьютере,​ и их типы в формате JSON.  | 
 +|//​Интервал обновления (в сек)// ​ |Этот фильтр задает как часто Zabbix выполняет обнаружение. В начале,​ когда вы только настраиваете обнаружение файловых систем,​ вы можете указать маленький интервал,​ но как только вы удостоверитесь что всё работает,​ вы можете установить его в 30 минут или более, потому что обычно файловые системы не меняются очень часто.\\ //​Обратите внимание//:​ Если укажите значение равное '​0',​ элемент данных не будет обрабатываться. Однако,​ если также существует переменный интервал с ненулевым значением,​ элемент данных будет обрабатываться в течении действия переменного интервала. ​ | 
 +|//​Переменные интервалы// ​ |Вы можете создать исключения из //​Интервал обновления//​. Например:​\\ Интервал:​ **0**, Период:​ **6-7,​00:​00-24:​00** - деактивирует получение данных на выходных. В противном случае будет использоваться интервал обновления по умолчанию.\\ Если переменные интервалы перекрываются,​ то будет использоваться наименьшее значение //​Интервал//​ перекрывающегося периода.\\ Смотрите страницу [[ru:​manual:​appendix:​time_period|Спецификации периодов времени]] для получения информации о формате //​Период//​.\\ //​Примечание//:​ Если указано значение равное '​0',​ элемент данных не будет обрабатываться в течении действия переменного интервала и вернется к обработке в соответствии с //​Периодом обновления//,​ как только переменный интервал завершится. ​ | 
 +|//​Период сохранения потерянных ресурсов (дней)// ​ |Это поле позволяет вам указать как много дней обнаруженный объект будет храниться (не будет удален),​ как только его состояние обнаружения станет "Не обнаруживается более"​ (макс 3650 дней). \\ //​Обратите внимание://​ Если значение равно "​0",​ объекты будут удалены сразу. Использование значения "​0"​ не рекомендуется,​ так как простое ошибочное изменение фильтра может закончится тем, что объект будет удален вместе со всеми данными истории. ​  ​| ​
 +|//​Фильтр// ​ |Фильтр можно использовать только для генерирования реальных элементов данных,​ триггеров и графиков конкретных файловых систем. Ожидается использование [[ru:​manual:​regular_expressions|Расширенные регулярные выражения POSIX]]. Например,​ если вы заинтересованы только в файловых системах C:, D: и E:, вы можете поместить {#FSNAME} в поле "​Макрос"​ и регулярное выражение <​nowiki>"​^C|^D|^E"</​nowiki>​ в поле "​Регулярное выражение"​ (например,​ <​nowiki>"​^ext|^reiserfs"</​nowiki>​).\\ Вы можете ввести в поле "​Регулярное выражение"​ регулярное выражение или ссылку на глобальное [[ru:​manual:​regular_expressions|регулярное выражение]].\\ Для проверки регулярного выражения вы можете использовать "grep -E", например:​ <code bash>for f in ext2 nfs reiserfs smbfs; do echo $f | grep -E '​^ext|^reiserfs'​ || echo "SKIP: $f"; done</​code>​Обратите внимание,​ что если какой-то макрос из фильтра пропущен в ответе,​ найденный объект будет игнорироваться. | 
 +|//​Описание// ​ |Введите описание. ​ | 
 +|//​Состояние// ​ |**Активировано** - правило будет обрабатываться.\\ **Деактивировано** - правило не будет обрабатываться.\\ **Не поддерживается** - элемент данных не поддерживается. Этот элемент данных не будет обрабатываться,​ однако Zabbix может пытаться периодически сменить состояние элемент данных в //​Активирован//​ в соответствии с указанным интервалом для [[ru:​manual:​web_interface:​frontend_sections:​administration:​general#​остальные_параметры|обновления не поддерживаемых элементов данных]]. ​ |
 +
 +<note important>​База данных Zabbix в MySQL должна быть создана чувствительной к регистру,​ если имена файловых систем различаются только по регистру,​ чтобы обнаружение сработало корректно.</​note>​
 +
 +<note important>​Ошибка или опечатка в регулярном выражении,​ которое используется в LLD правиле,​ может привести к удалению тысяч элементов конфигурации,​ значений истории и событий по большому количеству узлов сети. Например,​ некорректное регулярное выражение "File systems for discovery"​ может привести к удалению тысяч элементов данных,​ триггеров и значений истории и событий.</​note>​
 + 
 +<​note>​История правил обнаружения не сохраняется.</​note>​
 +
 +Как только правило будет создано,​ перейдем к элементам данных этого правила и нажмем "​Создать прототип",​ чтобы создать прототип элементов данных. Обратите внимание на то, как используется макрос {#FSNAME}, где требуется указать имя файловой системы. Когда правило будет обрабатываться,​ этот макрос будет заменен обнаруженной файловой системой.
 +
 +{{item_prototype_fs.png?​570|}}
 +
 +<​note>​Если прототип элемента данных создан с состоянием //​Деактивирован//,​ то он будет добавлен как обнаруженный объект,​ но в деактивированном состоянии.</​note>​
 +
 +Мы можем создать несколько прототипов элементов данных для каждой интересующей нас характеристики файловой системы:​
 +
 +{{item_prototypes_fs.png?​600|}}
 +
 +Теперь похожим способом мы создадим прототипы триггеров:​
 +
 +{{trigger_prototype_fs.png?​550|}}
 +
 +{{trigger_prototypes_fs.png?​600|}}
 +
 +И также прототипы графиков:​
 +
 +{{graph_prototype_fs.png?​600|}}
 +
 +{{graph_prototypes_fs.png?​600|}}
 +
 +В конце концов,​ мы создали правило обнаружения,​ которое выглядит как видно ниже. Оно имеет пять прототипов элементов данных,​ два прототипа триггеров и один прототип графика.
 +
 +{{lld_rules_fs.png?​600|}}
 +
 +Обратите внимание:​ Для получения информации по настройке прототипов узлов сети, смотрите в разделе мониторинга виртуальных машин о настройке [[:​ru/​manual/​vm_monitoring#​прототипы_узлов_сети|прототипов узлов сети]].
 +
 +Представленные снимки экрана ниже иллюстрируют как выглядят уже обнаруженные элементы данных,​ триггера и графики в настройке узла сети. Обнаруженные объекты имеют префикс ссылку золотистого цвета, которая ведет к правилу обнаружения,​ создавшего эти объекты.
 +
 +{{discovered_items.png?​600|}}
 +
 +Элементы данных (а также, триггеры и графики) созданные с помощью низкоуровневого правила обнаружения невозможно удалить вручную. Тем не менее, они будут удалены автоматически,​ если обнаруженный объект (файловая система,​ интерфейс и т.д.) более не обнаруживается (или более не попадает под фильтр). В этом случае они будут удалены спустя некоторое количество дней указанное в поле //​Период сохранения потерянных ресурсов//​. Обратите внимание,​ что триггеры (до Zabbix 2.2.2) и графики (до Zabbix 2.2.3) удаляются немедленно. ​
 +
 +Когда обнаруженный объект становится '​Более не обнаруживается',​ в списке элементов данных будет отображаться оранжевый индикатор времени жизни. Переместите курсор мыши на этот индикатор и вы увидите сообщение с количеством дней до момента удаления элемента данных.
 +
 +{{lifetime_indicator.png?​400|}}
 +
 +Если объекты отменены на удаление,​ но не были удалены в назначенное время (деактивировано правило обнаружения или элемент данных узла сети), они удалятся при следующем выполнении правила обнаружения.
 +
 +{{discovered_triggers.png?​600|}}
 +
 +{{discovered_graphs.png?​600|}}
 +
 +=== - Обнаружение сетевых интерфейсов ===
 +
 +Обнаружение сетевых интерфейсов осуществляется таким же образом,​ как и обнаружение файловых систем,​ за исключением того, что мы используем ключ правила обнаружения "​net.if.discovery"​ вместо "​vfs.fs.discovery"​ и макрос {#IFNAME} вместо {#FSNAME} в фильтре и в прототипах элементов данных/​триггеров/​графиков.
 +
 +Примеры прототипов элементов данных,​ которые вы можете захотеть создать основываются на "​net.if.discovery":​ "​net.if.in[{#​IFNAME},​bytes]",​ "​net.if.out[{#​IFNAME},​bytes]"​.
 +
 +[[#​обнаружение_файловых_систем|Смотрите выше]] для получения информации по поводу фильтра.
 +=== - Обнаружение SNMP OID'​ов ===
 +
 +В этом примере мы осуществим обнаружение SNMP на коммутаторе. Сначала перейдем в "​Настройка"​ -> "​Шаблоны"​.
 +
 +{{manual:​discovery:​low_level_discovery:​templates_snmp.png?​600|}}
 +
 +Для изменения правил обнаружения шаблона,​ нажмите на ссылку в колонке "​Обнаружение"​.
 +
 +Затем нажмите "​Создать правило"​ и заполните форму, как отображено на снимке экрана ниже.
 +
 +В отличие от обнаружения файловых систем и сетевых интерфейсов - этот элемент данных не требует наличия ключа "​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
 +
 +{{manual:​discovery:​low_level_discovery:​lld_rule_snmp.png|}}
 +
 +Представленный снимок экрана иллюстрирует как мы можем использовать эти макросы в прототипах элементов данных:​
 +
 +{{manual:​discovery:​low_level_discovery:​item_prototype_snmp.png?​570|}}
 +
 +Опять же, создадим столько прототипов элементов данных,​ сколько необходимо:​
 +
 +{{manual:​discovery:​low_level_discovery:​item_prototypes_snmp.png?​600|}}
 +
 +Также как и прототипы триггеров:​
 +
 +{{manual:​discovery:​low_level_discovery:​trigger_prototype_snmp.png?​550|}}
 +
 +{{manual:​discovery:​low_level_discovery:​trigger_prototypes_snmp.png?​600|}}
 +
 +И прототипы графиков:​
 +
 +{{manual:​discovery:​low_level_discovery:​graph_prototype_snmp.png?​600|}}
 +
 +{{manual:​discovery:​low_level_discovery:​graph_prototypes_snmp.png?​600|}}
 +
 +Результат нашего правила обнаружения:​
 +
 +{{manual:​discovery:​low_level_discovery:​lld_rules_snmp.png?​600|}}
 +
 +Когда сервер работает,​ он создаст реальные элементы данных,​ триггеры и графики на основе значений,​ полученных от "​snmp.discovery"​. В настройках узлов сети они будут иметь префикс ссылку золотистого цвета, которая ведет к правилу обнаружения,​ их создавшего.
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_items_snmp.png?​600|}}
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_triggers_snmp.png?​600|}}
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_graphs_snmp.png?​600|}}
 +
 +=== - Создание пользовательских LLD правил ===
 +
 +Также имеется возможность создать полностью пользовательское правило низкоуровневого обнаружения,​ для обнаружения любого типа объектов - к примеру,​ баз данных на сервере баз данных.
 +
 +Чтобы это сделать,​ необходимо создать пользовательский элемент данных,​ который будет возвращать JSON, определяющий найденные объекты и опционально - некоторые свойства этих объектов. Количество макросов на объект не ограничено - в то время как встроенные правила обнаружения возвращают либо один, либо два макроса (нппример,​ два в случае обнаружения файловых систем),​ имеется возможность возвращать больше.
 +
 +Требуемый JSON формат лучше всего иллюстрируется в примере. Предположим,​ что мы оставим старый Zabbix агент версии 1.8 (который не поддерживает "​vfs.fs.discovery"​),​ но нам также нужно обнаруживать файловые системы. Вот простой Perl скрипт для Linux, который обнаруживает примонтированные файловые системы и выдает на выходе данные JSON, в которых включено и имя, и тип файловой системы. Одним из способов его использования является UserParameter с ключем "​vfs.fs.discovery_perl":​
 +
 +<code 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";​
 +</​code>​
 +
 +<note important>​Допустимыми символами в именах макросов низкоуровневых правил обнаружения являются **0-9** , **A-Z** , **_** , **.** \\ \\  Буквы в нижнем регистре в именах не поддерживаются.</​note>​
 +
 +Пример его вывода (переформатирован для наглядности) представлен ниже. 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",​ как регулярное выражение.
 +
 +<​note>​Вы не обязаны использовать имена макросов FSNAME/​FSTYPE в пользовательских правилах низкоуровневого обнаружения,​ вы можете использовать любые другие имена, которые вам нравятся.</​note>​