Добрый день!
Вопрос по SNMPINDEX из разных таблиц. Требуется консультация в понимании логики работы
Zabbix Server 7.4.12
Debian 12
Суть:
Есть базовый шаблон мониторинга SAN коммутаторов *Brocade FC by SNMP*. К сожалению он не совсем верный логически, так как "да" вроде бы автором и закладывалась логика обнаружения только значимых портов через фильтрацию:
- {$NET.IF.IFADMINSTATUS.NOT_MATCHES} :: ^2$ :: Ignore down(2) administrative status
И оно вроде как даже работает, но только для относительно новых версий моделей. Потому что только в новых моделях (новая версия FOS Brocade), если нет SFP Transceiver, то порт автоматически переходит в - down(2) administrative status
На старых версиях так не работает, по умолчанию все порты в up administrative status, если они лицензированы.
В итоге картина примерно такая:
Все первые 12 порт (лицензированные) в статусе UP ("{#IFADMINSTATUS}":"1"), соответственно LLD их находит и добавляет в мониторинг.
Изучал разные MIB базы и нашел, что в базе SW-MIB есть нужная таблица swFCPortTable c параметром swFCPortPhyState (INTEGER { noCard ( 1 ) , noTransceiver ( 2 ) , laserFault ( 3 ) , noLight ( 4 ) , noSync ( 5 ) , inSync ( 6 ) , portFault ( 7 ) , diagFault ( 8 ) , lockRef ( 9 ) , validating ( 10 ) , invalidModule ( 11 ) , noSigDet ( 14 ) , unknown ( 255 ) } ) по которому как раз можно было бы отфильтровать. Только вот беда...
В этой таблице SNMPINDEX имеет значения - 1/2/3 и т.д.
А в нужной нам (.ifXEntry), из которой мы потом строим элементы данных SNMPINDEX имеет значения - 1073741824/1073741825/1073741826 и т.д.
И получается итоговый JSON имеет две разные таблицы сопоставления:
Вопрос:
Я правильно понимаю, что их скрестить/подружить/сопоставить друг с другом нельзя?
То есть используя фильтрацию {#IFPORTPHYSTATE} из одной таблицы (swFCPortTable), потом правильно формировать элементы данных, которые основываются на параметрах из другой таблицы (ifXEntry) при различных значениях - {#SNMPINDEX}
Вопрос по SNMPINDEX из разных таблиц. Требуется консультация в понимании логики работы
Zabbix Server 7.4.12
Debian 12
Суть:
Есть базовый шаблон мониторинга SAN коммутаторов *Brocade FC by SNMP*. К сожалению он не совсем верный логически, так как "да" вроде бы автором и закладывалась логика обнаружения только значимых портов через фильтрацию:
- {$NET.IF.IFADMINSTATUS.NOT_MATCHES} :: ^2$ :: Ignore down(2) administrative status
И оно вроде как даже работает, но только для относительно новых версий моделей. Потому что только в новых моделях (новая версия FOS Brocade), если нет SFP Transceiver, то порт автоматически переходит в - down(2) administrative status
На старых версиях так не работает, по умолчанию все порты в up administrative status, если они лицензированы.
В итоге картина примерно такая:
Code:
{"{#SNMPINDEX}":"1073741824","{#IFOPERSTATUS}":"2" ,"{#IFADMINSTATUS}":"1","{#IFNAME}":"FC port 0/0","{#IFDESCR}":"FC port 0/0","{#IFTYPE}":"56"},
{"{#SNMPINDEX}":"1073741825","{#IFOPERSTATUS}":"2" ,"{#IFADMINSTATUS}":"1","{#IFNAME}":"FC port 0/1","{#IFDESCR}":"FC port 0/1","{#IFTYPE}":"56"},
...
{"{#SNMPINDEX}":"1073741835","{#IFOPERSTATUS}":"2" ,"{#IFADMINSTATUS}":"1","{#IFNAME}":"FC port 0/11","{#IFDESCR}":"FC port 0/11","{#IFTYPE}":"56"},
{"{#SNMPINDEX}":"1073741836","{#IFOPERSTATUS}":"2" ,"{#IFADMINSTATUS}":"2","{#IFNAME}":"FC port 0/12","{#IFDESCR}":"FC port 0/12","{#IFTYPE}":"56"},
{"{#SNMPINDEX}":"1073741837","{#IFOPERSTATUS}":"2" ,"{#IFADMINSTATUS}":"2","{#IFNAME}":"FC port 0/13","{#IFDESCR}":"FC port 0/13","{#IFTYPE}":"56"},
...
{"{#SNMPINDEX}":"1073741846","{#IFOPERSTATUS}":"2" ,"{#IFADMINSTATUS}":"2","{#IFNAME}":"FC port 0/22","{#IFDESCR}":"FC port 0/22","{#IFTYPE}":"56"},
{"{#SNMPINDEX}":"1073741847","{#IFOPERSTATUS}":"2" ,"{#IFADMINSTATUS}":"2","{#IFNAME}":"FC port 0/23","{#IFDESCR}":"FC port 0/23","{#IFTYPE}":"56"}]
Изучал разные MIB базы и нашел, что в базе SW-MIB есть нужная таблица swFCPortTable c параметром swFCPortPhyState (INTEGER { noCard ( 1 ) , noTransceiver ( 2 ) , laserFault ( 3 ) , noLight ( 4 ) , noSync ( 5 ) , inSync ( 6 ) , portFault ( 7 ) , diagFault ( 8 ) , lockRef ( 9 ) , validating ( 10 ) , invalidModule ( 11 ) , noSigDet ( 14 ) , unknown ( 255 ) } ) по которому как раз можно было бы отфильтровать. Только вот беда...
В этой таблице SNMPINDEX имеет значения - 1/2/3 и т.д.
А в нужной нам (.ifXEntry), из которой мы потом строим элементы данных SNMPINDEX имеет значения - 1073741824/1073741825/1073741826 и т.д.
И получается итоговый JSON имеет две разные таблицы сопоставления:
Code:
{"{#SNMPINDEX}":"1073741824","{#IFOPERSTATUS}":"2","{#IFNAME}":"FC port 0/0","{#IFDESCR}":"FC port 0/0","{#IFTYPE}":"56"},
{"{#SNMPINDEX}":"1073741825","{#IFOPERSTATUS}":"2","{#IFNAME}":"FC port 0/1","{#IFDESCR}":"FC port 0/1","{#IFTYPE}":"56"},
{"{#SNMPINDEX}":"1073741826","{#IFOPERSTATUS}":"2","{#IFNAME}":"FC port 0/2","{#IFDESCR}":"FC port 0/2","{#IFTYPE}":"56"},
{"{#SNMPINDEX}":"1073741827","{#IFOPERSTATUS}":"2","{#IFNAME}":"FC port 0/3","{#IFDESCR}":"FC port 0/3","{#IFTYPE}":"56"}
{"{#SNMPINDEX}":"1","{#IFPORTPHYSTATE}":"4"},
{"{#SNMPINDEX}":"2","{#IFPORTPHYSTATE}":"2"},
{"{#SNMPINDEX}":"3","{#IFPORTPHYSTATE}":"2"},
{"{#SNMPINDEX}":"4","{#IFPORTPHYSTATE}":"2"}
Я правильно понимаю, что их скрестить/подружить/сопоставить друг с другом нельзя?
То есть используя фильтрацию {#IFPORTPHYSTATE} из одной таблицы (swFCPortTable), потом правильно формировать элементы данных, которые основываются на параметрах из другой таблицы (ifXEntry) при различных значениях - {#SNMPINDEX}
Comment