Дублирующиеся ключи при использовании п&

[awakeman]

Добрый день уважаемые знатоки, я недавно начал осваивать низкоуровневые обнаружение в заббиксе, но столкнулся с проблемой. Постараюсь кратко. Есть правило обнаружения сетевых интерфейсов для cisco catalyst 3750 коммутатора:

discovery[{#IFDESCR}, .1.3.6.1.2.1.2.2.1.2]

На основании этого правила, скажем, имеется прототип элемента данных, который создает элемент данных "описание_интерфейса":
Имя прототипа: cisco interface $1
Ключ: ifdescr3750[{#IFDESCR}]
Snmp oid: .1.3.6.1.2.1.2.2.1.2.{#SNMPINDEX}

Это работает, создаётся нужный элемент данных, все ок. Однако при применении шаблона с этим правилом к другому свичу, возникает конфликт. Заббикс пишет что элемент данных с таким ключем уже существует. Это логично, ведь интерфейсы на цисках 3750 одни и те же. Вопрос. Какой параметр мне нужно добавить в прототип ключа, чтобы он был 100% уникален?

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

[Semiadmin]

А это lld вы сами писали? Для цисок есть достаточно готовых шаблонов с lld, можно начать с них (правда, м.б., придется слегка переделать их для 3 версии заббикс). Заодно и посмотреть, как пишется lld через snmp. Кстати, почему бы не использовать MIB вместо OID? Насчет уникальности ключей, одинаковые ключи для разных хостов - это совершенно нормально, ключи должны быть уникальными только в рамках одного хоста.

[yukra]

Ключ: ifdescr3750[{#IFDESCR}]

а почему ключ {#IFDESCR}? Это ведь InterFace Description? Если будут 2 интерфейса с одинаковым десткипшеном (например с пустым), то это как раз сгенерирует одинаковые ключи в пределах одного хоста. Попробуйте использовать в ключе {#SNMPINDEX}

[awakeman]

а почему ключ {#IFDESCR}? Это ведь InterFace Description? Если будут 2 интерфейса с одинаковым десткипшеном (например с пустым), то это как раз сгенерирует одинаковые ключи в пределах одного хоста. Попробуйте использовать в ключе {#SNMPINDEX}

Спасибо, в целом помогает, но есть косяк. В итоге мы имеем итемы
cisco interfaces discovery: cisco in load 10032
с ключами ciscoinload[10032]
что ни разу не информативно.

Помогло следующее:
В правиле обнаружения в поле snmp oid вводим:
discovery[{#SNMPVALUE}, .1.3.6.1.2.1.2.2.1.2]

Тогда имя элемента данных должно быть cisco out load {#SNMPVALUE}
И мы можем позволить себе ключ ciscooutload[{#SNMPINDEX}] вместе с snmp oid .1.3.6.1.2.1.2.2.1.16.{#SNMPINDEX}

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

[yukra]

Спасибо, в целом помогает, но есть косяк. В итоге мы имеем итемы
cisco interfaces discovery: Cisco in load 10032
с ключами ciscoinload[10032]
что ни разу не информативно.

В моей вселенной информативно должно быть имя айтема и имя триггера, а ключ айтема должен быть "технически правильным"