Добавление в имя обнаруженного интерфейса {#SNMPINDEX} помимо {#SNMPVALUE}

[ghoru]

Template SNMP Interfaces Обнаруживает интерфейсы «через один» из-за одинаковых имён для данного примера:

IF-MIB::ifDescr.1 = STRING: Ethernet 10/100 Mbit/s
IF-MIB::ifDescr.2 = STRING: Ethernet 10/100 Mbit/s
IF-MIB::ifDescr.3 = STRING: Ethernet 10 Mbit/s internal
IF-MIB::ifDescr.4 = STRING: Ethernet 10 Mbit/s internal
IF-MIB::ifDescr.5 = STRING: Ethernet 100 Mbit/s internal
IF-MIB::ifDescr.6 = STRING: Ethernet 1000 Mbit/s Full Duplex
IF-MIB::ifDescr.7 = STRING: Ethernet 1000 Mbit/s Full Duplex
IF-MIB::ifDescr.8 = STRING: Optical channel Zelax GM-1G
IF-MIB::ifDescr.9 = STRING: Optical channel Zelax GM-1G

В правилах обнаружения, в окне лога (стлобец Инфо)

Cannot create item: item with the same key "ifAdminStatus[Ethernet 10/100 Mbit/s]" already exists.
Cannot create item: item with the same key "ifAdminStatus[Ethernet 10 Mbit/s internal]" already exists.
Cannot create item: item with the same key "ifAdminStatus[Ethernet 1000 Mbit/s Full Duplex]" already exists.
Cannot create item: item with the same key "ifAdminStatus[Optical channel Zelax GM-1G]" already exists.

Как сделать имена с номерами {#SNMPINDEX}, например для 2-х последних строк:
Optical channel Zelax GM-1G - 8
Optical channel Zelax GM-1G - 9

[Whols]

А как выглядит строка для прототипа элемента?

[Kos]

При отработке LLD для каждого создаваемого из прототипа элемента данных уникальным должен быть ключ, а не имя.
Собственно, об этом у вас и написано в логе.
Выходов из этого может быть несколько.

Вариант первый, самый простой: использовать в ключе (не в имени, а именно в ключе!) прототипа макрос {#SNMPINDEX} вместо нынешнего {#SNMPVALUE}.
Что использовать в имени - на ваш вкус: хоть один, хоть другой, хоть оба сразу.
Конкретно описанную проблему это решит. Однако, может приводить к другим проблемам.

Так, порядок (да и само наличие) конкретных SNMP-индексов на свитче - величина непостоянная. Добавили к стеку ещё один свитч - появилась целая "пачка" новых портов со своими индексами. Сконфигурировали новый транк, VPN или VLAN - добавились новые интерфейсы. Но с добавлением ещё ладно, хуже с удалением. А потом перезагрузили устройство - все интерфейсы перенумеровались заново (возможно, в другом порядке). Некоторые свитчи имеют специальные настройки, позволяющие сохранять индексацию при перезагрузках; но это лишь снижает вероятность проблем, но не исключает их полностью.

Сами же проблемы заключаются в том, что если вы потом использовали где-то обнаруженные ключи (на графиках, в картах сети и т.п.), то после того как индексация "поплыла", во всех таких местах эти ключи будут ссылаться на совершенно другие элементы данных.

Решением же является при обнаружении опираться ну другую таблицу OID-ов: не ту, где хранятся наименования интерфейсов (1.3.6.1.2.1.2.2.1.2 или 1.3.6.1.2.1.31.1.1.1.18), а ту, где хранятся их уникальные имена вроде ge-0/1/0, xe-0/0/2 или ae0 (1.3.6.1.2.1.31.1.1.1.1) - они фиксированы, и ими, собственно, и оперирует админ .

[ghoru]

Вариант первый, самый простой: использовать в ключе (не в имени, а именно в ключе!) прототипа макрос {#SNMPINDEX} вместо нынешнего {#SNMPVALUE}.

Спасибо, нужный эффект достигнут, получились такие ключи:
ifAdminStatus[{#SNMPVALUE}-{#SNMPINDEX}]

В веб-интерфейсе:
Admin status of interface Ethernet 10 Mbit/s internal-3 up (1)
Admin status of interface Ethernet 10 Mbit/s internal-4 up (1)
Admin status of interface Ethernet 10/100 Mbit/s-1 up (1)
Admin status of interface Ethernet 10/100 Mbit/s-2 up (1)
Admin status of interface Ethernet 100 Mbit/s internal-5 up (1)
Admin status of interface Ethernet 1000 Mbit/s Full Duplex-6 up (1)
Admin status of interface Ethernet 1000 Mbit/s Full Duplex-7 up (1)
Admin status of interface Optical channel Zelax GM-1G-8 up (1)
Admin status of interface Optical channel Zelax GM-1G-9 up (1)