Имя эелемента данных в автоматическом об

[Deks]

После выхода версии 2.0 повилась возможность автоматического обнаружения к примеру сетевых интерфесов используя SNMP-протокол.
Стандартный прототип поиска интерфейсов использует в найденном имени интерфейса его SNMP-Index.
К примеру:
Имя прототипа элементов данных: ifInOctets.$1
Ключ: ifInOctets[*{#SNMPINDEX}*]
OID: ifInOctets.{#SNMPINDEX}

Тогда при найденном интерфесе с SNMP-Index=1, имя элемента данных для данного интерфейса в заббиксе будет называться: ifInOctets.*1*
И соотвественно графики данного интерфейса будут называться так же, содержащими SNMP-Index.

А хотелось бы сделать так, чтобы они содержали не INDEX, а Desription данного интерфейса, как в имени элемента данных, так и в имени графика.

Кто сталкивался с этой задачей, подскажите каким образом можно осуществить задуманное?

[zalex_ua]

По форуму пробовали искать ?
Поищите - недавно обсуждалось.

[dima_dm]

Вот ссылка

http://www.zabbix.com/forum/showthread.php?t=28870

[Deks]

Вот ссылка
http://www.zabbix.com/forum/showthread.php?t=28870

к сожалению из этой ссылки не совсем понятноя как и где необходимо указывать snmpvalue.

Я пытался поиграть с этим, в итоге только насоздавал кучу графиков, которые удалить в ручную нельзя, а сами они удалятся только через месяц.

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

[Deks]

Если я правильно понимаю, данные прототипа должны быть такие?


Имя прототипа элементов данных: ifInOctets.$1
Ключ: ifInOctets[*{#SNMPVALUE}*]
OID: ifInOctets.{#SNMPINDEX}

[Deks]

хотя если так делать, то SNMPVALUE берет значение ifInOctets.

А мне нужно имя это интерфейса у которого мы смотрим входящие октеты.

[neo32]

Присоединяюсь к данному вопросу)

[Deks]

Решение найдено.
При создании правила обнаружения интерфейсов, необходимо указать в виде ключа: ifDescr, и SNMP OID: IF-MIB::ifDescr
Комьюнити оставить: {$SNMP_COMMUNITY} (прошу обратить внимение - это настройка не для элементов данных в правиле обнаружения, а именно настройка этого правила)

Т.е. если брать дефолтовое правило обнаружения "Network interfaces"
из шаблона "Template SNMP Interfaces", то необходимо изменить изменить его настройки в соотвествии с вышесказанным.

[neo32]

Тогда вопрос в другом, мне создать такое правило, которое бы работало только с интерфейсами которые находятся в состоянии up, и при этом сделать в таком правиле, адекватное читаемое название интерфейса, в получаемых данных ? насколько я понимаю это возможно сделать разве что создавая правило с OID ifOperStatus

[Jimson]

Тогда вопрос в другом, мне создать такое правило, которое бы работало только с интерфейсами которые находятся в состоянии up, и при этом сделать в таком правиле, адекватное читаемое название интерфейса, в получаемых данных ? насколько я понимаю это возможно сделать разве что создавая правило с OID ifOperStatus

Это можно сделать через правило реализованное внешней проверкой, скриптом, о чем я и писал в свое время тему, на которую выше давали ссылку. Понять логику этого решения очень просто, при условии что вы понимаете что такое SNMP, что такое JSON и как zabbix реализует LLD. Вы же все время возвращаетесь к "SNMPVALUE", которое по сути является просто именем макроса во встроенном SNMP LLD правиле.

[neo32]

Jimson
Да я понял, буду пробовать вот как раз сейчас ваш скриптец, спасибо.
Я просто не могу уловить одной простой вещи, нигде не могу найти простого и внятного описания того, как само непосредственно правило обнаружения связано с прототипами данных. Как одно влияет на другое, помимо того, что мы в самом правиле создаём прототипы данных которые хотим мониторить.
Я не понимаю зачем создавать само правило обнаружения, если в теории можно было бы создавать просто прототипы данных, в которых мы так и так указываем полный(почти) путь к OID нас интересующих, кроме последнего, возможно изменяющегося значения и привязывать их к конкретных шаблонам в качестве обнаруживаемых димамических элементов.

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

Если не трудно можете внести ясность в мои размышления?))

[vvlad]

neo32, каша у Вас в голове, однако...

Для начала стоит понять, что есть SNMP, и в частности - MIB, который лежит в его основе. По сути, любой MIB - дерево. И любой из его элементов, адресуемых конкретным OID - это либо конечный элемент, либо родительский для содержащихся в нем дочерних элементов.

Далее... Часть данных в MIB организована таблицами. Один из примеров - ifTable. Имя интерфейса (ifName), описание (ifDescr) и ряд других - есть поля этой таблицы. Каждый конкретный интерфейс в этой таблице адресуется индексом. Причем, от устройства к устройству количество строк в этой таблице различно, индексы порой идут не по порядку, а в некоторых случаях вообще представлены не целым числом, а строкой. Соответственно, для того, чтобы получить, к примеру, имя, или описание конкретного интерфейса, нам требуется узнать его индекс.

Для реализации этой задачи в Zabbix служит механизм низкоуровневого обнаружения. В документации приведен пример с ifDescr. В правиле задается этот OID (который на самом деле 1.3.6.1.2.1.2.2.1.2), который при отработке zabbix'ом данного правила направляется в узел под мониторингом в bulk-запросе. В ответ узел, если в его дереве MIB определен такой OID, возвращает перечень подэлементов:

$ 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

Каждый дочерний элемент имеет OID, состоящий из базового (ifDescr), плюс индекс интерфейса. Результат отработки правила обнаружения - таблица:

{#SNMPINDEX} -> 1   {#SNMPVALUE} -> WAN
{#SNMPINDEX} -> 2   {#SNMPVALUE} -> LAN1
{#SNMPINDEX} -> 3   {#SNMPVALUE} -> LAN2

Где макрос {#SNMPINDEX} - индекс дочернего элемента базового OID, а макрос {#SNMPVALUE} - его значение. На базе этих макросов из заданных прототипов строятся конкретные элементы данных. При этом, как правило, при формировании OID в прототипе используется именно {#SNMPINDEX}. Так, к примеру, получить алиас определенного интерфейса можно, задав OID ifAlias.{#SNMPINDEX}, объем входящего трафика - ifInOctets.{#SNMPINDEX} и т.д., и т.п.

Макрос {#SNMPVALUE} можно при этом использовать в качестве части имени элемента данных, части ключа, в прототипах тригеров, графиков - везде, где фантазия позволит.

Настоятельно рекомендую начать с азов, с понимания SNMP как такового. Дальше будет проще...

[Jimson]

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

Правило LLD это обычная zabbix-проверка (ничем не отличающаяся от проверок элементов данных), но zabbix ожидает что эта проверка вернет 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"  }
  
  ]
}

В этой структуре передается массив "объектов", где каждый объект описан некоторым набором параметров. В примере из документации, который я привел выше, "объекты" - файловые системы, а параметры которыми описаны эти объекты FSNAME и FSTYPE. Далее zabbix для каждого "объекта" создает элементы данных, триггеры и графики в соответствии с прототипами описанными в данном правиле, иначе говоря прототипы это шаблоны элементов/триггеров/графиков.

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

Фильтры тут при чем? Проблема в том что вы не осознали необходимости LLD, забейте на LLD, возьмите и сделайте мониторинг интерфейсов влоб: создайте элементы данных для каждого интерфейса вручную, триггеры и тп. Может быть тогда вы поймете для чего нужен LLD.

[vvlad]

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

Кстати, здравая рекомендация. Просветление гарантировано.

[neo32]

Здравствуйте, спасибо огромное за ответы, собственно руками уже всё делалось, и шаблоны с каждым элементом данных/триггерами/графиками для целого зоопарка ус-в делать не хочется, поэтому то и как раз было решено использовать LLD.
Сам принцип работы SNMP то я более менее понимаю, в принципе вооружившись для начала любым сносным SNMP браузером MIB'ов, можно более менее адекватно понять что такое SNMP и как им пользоваться.(или snmpwalk'ом)
Принцип работы же LLD для меня остаётся понятен не до конца, то что встроенными макросами {#snmpindex} и {#snmpname} мы можем брать данные с OID'a в определённом MIB, но вот взаимосвязь непосредственно самого правила обнаружения LLD с прототипами данных которые создаються как бы внутри него, мне не совсем понятно, почему тогда нельзя обойтись без самого правила а создавать лишь сразу прототипы данных ? и есть ли вообще какая то взаимосвязь между правилом и прототипами? то есть к примеру прототип смотрит на то что вернуло правило и в итоге из этого выдаёт значение запрашиваемое в его параметрах(прототипа)