Zabbix Documentation 2.0

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

ru:manual:discovery:low_level_discovery [2016/01/07 23:34]
ru:manual:discovery:low_level_discovery [2014/09/26 11:36] (current)
sasha Links adapted because of a move operation
Line 1: Line 1:
 +==== 3 Низкоуровневое обнаружение ====
 +=== Обзор === 
 +
 +Низкоуровневое обнаружение предоставляет возможность автоматического создания элементов данных,​ триггеров и графиков для разных ресурсов на компьютере. Например,​ Zabbix может автоматически начать мониторить файловые системы или сетевые интерфейсы на вашем устройстве,​ без необходимости создания вручную элементов данных для каждой файловой системы или сетевого интерфейса. Кроме того, в Zabbix имеется возможность настроить удаление ненужных объектов,​ основываясь на фактических результатах периодически выполняемого обнаружения.
 +
 +В Zabbix 2.0, поддерживаются три встроенных типа элементов данных для обнаружения:​
 +
 +  * обнаружение файловых систем;​
 +  * обнаружение сетевых интерфейсов;​
 +  * обнаружение нескольких 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.</​note>​
 +
 +<​note>​В Zabbix прокси максимальное возвращаемое значение для правила низкоуровневого обнаружения составляет 4000 символов для Oracle DB и 2048 символов для IBM DB2.</​note>​
 +
 +Эти макросы потом используются в именах,​ ключах и в других полях прототипов при создании элементов данных,​ триггеров и графиков для каждого обнаруженного объекта. Для элементах данных,​ эти макросы могут быть использованы в именах,​ ключах,​ SNMP OID, в выражениях вычисляемых элементов данных,​ в SSH и Telnet скриптах,​ в параметрах мониторинга баз данных. Для триггеров,​ в именах и в выражениях. Для графиков,​ только в поле имени.
 +
 +Когда сервер получает значение для обнаруживаемого элемента данных,​ он смотрит на пару макрос -> значение и для каждой пары генерирует реальные элементы данных,​ триггера и графики,​ основываясь на их прототипах. В приведенном выше примере с "​net.if.discovery",​ сервер будет генерировать один набор элементов данных,​ триггеров и графиков для интерфейса "​lo"​ и другой набор для интерфейса "​eth0"​.
 +
 +Следующий раздел иллюстрирует в деталях процесс,​ описанный выше, и служит руководством к действию как осуществлять обнаружения файловых систем,​ сетевых интерфейсов и нескольких SNMP OID. Последний раздел описывает формат JSON для элементов данных обнаружения и дает пример того, как внедрить ваш собственный обнаружитель файловых систем в виде Perl скрипта.
 +
 +=== - Обнаружение файловых систем ===
 +
 +Для настройки обнаружения файловых систем,​ сделайте следующее:​
 +
 +  * Перейдите в: //​Настройки//​ -> //​Шаблоны//  ​
 +  * Нажмите на //​Обнаружение//​ в строке соответствующего шаблона
 +
 +{{ru:​manual:​discovery:​low_level_discovery:​discovery_overview.png?​800|Список шаблонов}}
 +
 +  * Нажмите на //​Создать правило обнаружения//​ в верхнем правом углу экрана
 +  * Заполните форму следующими деталями
 +
 +{{manual:​discovery:​low_level_discovery:​lld_rule_fs.png?​570|}}
 +
 +^Параметр^Описание^ ​
 +|//​Имя// ​ |Имя правила обнаружения. ​ | 
 +|//​Тип// ​ |Тип проверки выполняемого обнаружения;​ должен быть //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>​). Фильтрация также возможна по типам файловых систем при использовании макроса {#​FSTYPE}.\\ Вы можете ввести в поле "​Регулярное выражение"​ регулярное выражение или ссылку на глобальное [[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>​История правила обнаружения не сохраняется</​note>​
 +
 +Как только правило будет создано,​ переходим к элементам данных для этого правила и нажимаем "​Создать прототип"​ для создания прототипа элементов данных. Обратите внимание как макрос {#FSNAME} используется в месте, где нужно вписывать имя файловой системы. Когда правило будет обрабатываться,​ этот макрос будет замещен обнаруженной файловой системой.
 +
 +{{manual:​discovery:​low_level_discovery:​item_prototype_fs.png?​570|}}
 +
 +<​note>​Если прототип элемента данных создан с состоянием //​Деактивирован//,​ то он будет добавлен как обнаруженный объект,​ но в отключенном состоянии.</​note>​
 +
 +Мы можем создать несколько прототипов элемента данных для каждой интересующей нас характеристики файловой системы:​
 +
 +{{manual:​discovery:​low_level_discovery:​item_prototypes_fs.png?​600|}}
 +
 +Теперь похожим способом мы создадим прототипы триггеров:​
 +
 +{{manual:​discovery:​low_level_discovery:​trigger_prototype_fs.png?​550|}}
 +
 +{{manual:​discovery:​low_level_discovery:​trigger_prototypes_fs.png?​600|}}
 +
 +И также прототипы графиков:​
 +
 +{{manual:​discovery:​low_level_discovery:​graph_prototype_fs.png?​600|}}
 +
 +{{manual:​discovery:​low_level_discovery:​graph_prototypes_fs.png?​600|}}
 +
 +В конце концов,​ мы создали правило обнаружения,​ которое выглядит как показано ниже. Оно имеет пять прототипов элементов данных,​ два прототипа триггеров и один прототип графика.
 +
 +{{manual:​discovery:​low_level_discovery:​lld_rules_fs.png?​600|}}
 +
 +Представленные скриншоты иллюстрируют как уже обнаруженные элементы данных,​ триггера и графики выглядят в настройке узла сети. Обнаруженные объекты предварены префиксом-ссылкой золотистого цвета, которая ведет к правилу обнаружения,​ создавшего эти объекты.
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_items.png?​600|}}
 +
 +Элементы данных (а также, триггеры и графики) созданы с помощью низкоуровневого правила обнаружения невозможно удалить вручную. Тем не менее, они будут удалены автоматически,​ если обнаруженный объект (файловая система,​ интерфейс и т.д.) более не обнаруживаются (или не попадают более под фильтр). В этом случае они будут удалены спустя некоторое количество дней заданное в поле //​Период сохранения потерянных ресурсов//​.
 +
 +Когда обнаруженный объект становится '​Более не обнаруживается',​ в списке элементов данных будет отображаться оранжевый индикатор времени жизни. Переместите курсор мыши на этот индикатор и вы увидите сообщение с количеством дней до момента удаления элемента данных.
 +
 +{{manual:​discovery:​1.9.9_lifetime_indicator.png?​400|}}
 +
 +{{manual:​discovery:​low_level_discovery:​discovered_triggers.png?​600|}}
 +
 +{{manual:​discovery:​low_level_discovery:​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}. ​ В случае если вы хотите зафильтрровать loopback интерфейсы из возвращенных значений вам следует поместить "​{#​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|}}
 +
 +=== - JSON формат обнаружения элемента данных ===
 +
 +Требуемый JSON формат лучше всего иллюстрируется в примере. Предположим,​ что мы оставим старый Zabbix агент версии 1.8 (который не поддерживает "​vfs.fs.discovery"​),​ но нам также нужно обнаруживать файловые системы. Вот простой Perl скрипт для Linux, который обнаруживает смонтированные файловые системы и отдает на выходе JSON данные,​ в которых включено оба - и имя и тип файловой системы. Один из способов его использования это Пользовательский Параметр с ключем "​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>​
 +
 +Пример его вывода (переформатирован для наглядности) представлен ниже. 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"​ как регулярное выражение.