Как сделать в шаблоне Zabbix разные OID на одинаковых устройствах?

Question

[Дмитрий]

Суть вопроса: есть ряд девайсов, которые имеют на один и тот же параметр разные OID (на каждом девайсе - свой). Почему так - неизвестно..

То есть на одном устройстве мы получим загрузку CPU по такому OID:

SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.8.132.36.141.26.205.124 = Gauge32: 86

то на другом таком же устройстве получим с этим же OID:

SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.8.132.36.141.26.205.124 = No Such Instance currently exists at this OID

и на нем уже будет другой рабочий OID:

SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.8.180.199.153.220.95.160 = Gauge32: 23

То есть база одна (SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.8), по snmpwalk нормально отрабатывает, по snmpget (и в zabbix также) уже нет.

То есть нормальный template не сделать.

Вопрос - есть ли там встроенные средства, чтобы это как-то обойти?
Может, через LLD или еще какой-то хак?

Answer 1

[Александр]

Думаю, что нет. Придется писать шаблоны под разные группы устройств.
LLD задачи, на мой взгляд, не решит - всё равно же нужно указывать какой OID вытягивать.

Answer 2

[Дмитрий]

Удалось выяснить, что каждое устройство добавляет в конце свой MAC-адрес, преобразованный в DEC.
Например, SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.8.132.36.141.26.205.124 - в конце mac одной точки.
SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.8.180.199.153.220.95.160 - mac другой точки.

Пока сделал по простому - в шаблоне в поле OID добавил макрос {$AP_ID}
Для каждой точки при добавлении указываю его, соответственно.
То есть, получилось SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.8.{$AP_ID}

Вероятно, его можно просто автоматически вычислять, но пока не знаю, как это сделать средствами Zabbix.

P.S.: Эти устройства, если что - точки доступа Motorola (Zebra) WiNG AP650, AP6532, AP7131

Answer 3

[Юрий]

День Добрый Дмитрий
Удалось ли вам решить вопрос с мониторингом точек Motorola (Zebra) (нынче уже Extreme) в Zabbix?
Если да, не могли бы вы поделиться шаблоном для Zabbix?

Comments

[Дмитрий]

В общем, сделал так , как написал выше, точек всего 22, не стал заморачиваться.

Answer 4

[Dimasmir0]

Приветствую.

Такая задача решается в Заббиксе при помощи LLD.
Например:
SNMP OID для обнаружения может выглядеть так:
discovery[{#SNMPVALUE},SNMPv2-SMI::enterprises.388.50.1.4.2.1.1.3]
А SNMP OID прототипа элемента получающего количество подключенных клиентов так:
SNMPv2-SMI::enterprises.388.50.1.4.2.25.1.1.1.4.{#SNMPINDEX}.{#SNMPINDEX}

На выходе мы получаем элемент с SNMP OID типа
SNMPv2-SMI::enterprises.388.50.1.4.2.25.1.1.1.4.116.103.247.15.18.11.116.103.247.15.18.11 по которому доступно количество подключенных клиентов.

Comments

[Kasatka23]

Есть вопрос)
Подскажи пожалуйста. Есть OIDы - для CPU
-- 1.3.6.1.4.1.388.50.1.4.2.2.1.1.8
wingStatsDevSysInfoLoadLimitS0 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"10 times the average cpu load over the last minute
(2 => .2 % cpu load)

XPath: /wing-stats/device[mac=key1]/sysinfo/load_limit_s0"
::= { wingStatsDevSysInfoEntry 8 }


-- 1.3.6.1.4.1.388.50.1.4.2.2.1.1.9
wingStatsDevSysInfoLoadLimitS1 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"10 times the average cpu load over the last five minutes
(2 => .2 % cpu load)

XPath: /wing-stats/device[mac=key1]/sysinfo/load_limit_s1"
::= { wingStatsDevSysInfoEntry 9 }


-- 1.3.6.1.4.1.388.50.1.4.2.2.1.1.10
wingStatsDevSysInfoLoadLimitS2 OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"10 times the average cpu load over the last fifteen minutes
(2 => .2 % cpu load)

XPath: /wing-stats/device[mac=key1]/sysinfo/load_limit_s2"
::= { wingStatsDevSysInfoEntry 10 }

Это надо реализовать с помощью LLD.
Собственно первым шагом написать, Discovery.
Я правильно понимаю,что OID для дискавери будет выглядеть так:

OID: discovery[{#SNMPVALUE},SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.10.{#SNMPINDEX}
key discovery: wingStatsDevSysInfoEntry[{#SNMPVALUE}]

item prototypes:
1.3.6.1.4.1.388.50.1.4.2.2.1.1.{#SNMPINDEX}
key: wingStatsDevSysInfoEntry[{#SNMPVALUE}]

$ snmpwalk -v2C -c wbpublic x.x.x.x 1.3.6.1.4.1.388.50.1.4.2.2.1.1.10
SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.10.184.80.1.53.199.212 = Gauge32: 40
$ snmpwalk -v2C -c wbpublic x.x.x.x 1.3.6.1.4.1.388.50.1.4.2.2.1.1.10
SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.10.180.45.86.138.188.242 = Gauge32: 22

[Dimasmir0]

Kasatka23, не совсем так. {#SNMPINDEX} используется уже в самом item, в discovery его быть не должно.
Если использовать правило вида discovery[{#DEVICENAME},SNMPv2-SMI::enterprises.388.50.1.4.2.1.1.3], то будут получены все дочерние ноды и значения, например:
SNMPv2-SMI::enterprises.388.50.1.4.2.1.1.3.116.103.247.154.180.222 Office-1-Reception, где в:
{#SNMPINDEX} будет записано 116.103.247.154.180.222,
{#DEVICENAME} будет записано Office-1-Reception.

В item prototype можно создать так:
Name: {#DEVICENAME} cpu load,
Key: wingStatsDevSysInfoEntry[{#DEVICENAME}],
SNMP OID: SNMPv2-SMI::enterprises.388.50.1.4.2.2.1.1.10.{#SNMPINDEX}.