Мониторинг интерфейсов. Динамические индексы и функция get[...]

[Wadim_Sch]

Добрый день!
Столкнулся с такой проблемой. Дело в том, что сетевое оборудование некоторых производителей меняет индексы интерфейсов после перезагрузки. У Cisco это можно было запретить в конфиге. Соответственно Zabbix ещё с версии 1.8 поддерживает динамические индексы. Вот оно для версии 7.0. https://www.zabbix.com/documentation...p/dynamicindex. Соответственно очень давно я настроил шаблон для поиска параметров интерфейсов соответсвенно этой рекомендации.

Теперь Zabbix говорит: "А с функцией get[...] работать лучще". Ну типа асинхронный опрос и все плюшки с этим связанные. https://www.zabbix.com/documentation...itemtypes/snmp
OK
Пытаюсь изменить в прототипе Item-а ifHCInOctets[index,ifDescr,{#IFNAME}] на get[ifHCInOctets[index,ifDescr,{#IFNAME}]]. А нет, так не работает. Для get[...] похоже нужен только OID хотя MIB-имена тоже вроде бы подерживаюся.

Есть ли какая-то возможность поженить ifHCInOctets[index,ifDescr,{#IFNAME}] с функцией get[...] ?

[Kos]

Прямой ответ на ваш вопрос: насколько я понимаю, в данный момент работа с динамическими индексами асинхронными поллерами не поддерживается.
Был enhancement request на эту тему (ссылка), можно сходить там и проголосовать, а заодно добавить свой use case (пока что не особо видно, чтобы это было сильно востребовано - ну, разве что я сегодня ещё свой голос добавил).

Ответ "для поддержания беседы": мне кажется, что данная "фича", несмотря на первый же пример в документации, предназначена немного для других ситуаций - а именно, когда узнать нужные индексы заранее вообще невозможно либо они достаточно часто меняются. Там второй пример (с контролем памяти по конкретному процессу) более релевантен: мы знаем имя процесса, но заранее понятия не имеем, с каким индексом он окажется в таблице процессов.
В случае с сетевыми интерфейсами, мне кажется, эффективнее полагаться на штатный LLD, но с важным уточнением: в ключах прототипов элементов данных использовать не LLD-макрос {#SNMPINDEX} (поскольку индексы не часто, но могут поменяться), а что-то более стабильное (имя интерфейса - обычно доступно как LLD-макрос {#IFNAME} или {#IFALIAS}).

[Wadim_Sch]

Правильно ли я понимаю?

То есть в поле "Key" будет: ifHCOutOctets.[{#IFNAME}], а в поле "SNMP OID" ifHCOutOctets[{#SNMPINDEX}].
Например: Key: ifHCOutOctets.[1/1/5] -- SNMP OID: ifHCOutOctets[505]
Теперь если индекс после перезагрузки поменялся: 505 -> 710
В следующий LLD процесс, Zabbix изменит индекс во всех Items для порта 1/1/5 на 710.
Key: ifHCOutOctets.[1/1/5] -- SNMP OID: ifHCOutOctets[710] и начнет собирать правильную информацию.
То есть после перезагрузки и до следующего LLD, Zabbix может получать не корректную информацию о портах. Ну для меня это не критично.

При такой настройке динамические индексы собственно и не нужны...

[Kos]

Wadim_Sch, да, именно так.

Причём и история, и формулы вычисляемых элементов данных, и надписи в картах сети ссылаются на элементы данных не по их ID, а по их ключу. То есть, если ключ не меняется, то при изменении индексов всё остаётся на своих местах.
Мы в своё время заметили этот эффект, поскольку на некоторые карты сети были выведены текущие значения трафика на конкретных интерфейсах, а после некоторых изменений (добавлялись/удалялись агрегаты и VLAN'ы) оказалось, что вместо нужных значений отображается фаза луны
После этого и переделали. Соответственно, поскольку все ключи поменялись (вместо индексов там стали фигурировать наименования интерфейсов), то история по ним потерялась; но это произошло предсказуемо и однократно (после этого уже подобных проблем не возникало).