SNMP Discovery

[Diesel315]

Всем добрый день!
Вопрос связан больше с просвещением по части смысла функционала, нежели решение конкретной проблемы.

Можете подсказать, пожалуйста, по разделу Обнаружение SNMP OID'ов. В частности по - OID'ы для обнаружения добавляются в поле SNMP OID в следующем формате: discovery[{#МАКРОС1}, oid1, {#МАКРОС2}, oid2, …,]
Всегда предполагал, что какие OID тут мы перечислим, такие в итоге и будут находится! И именно эти OID можно потом использовать в прототипе данных.
Иными словами, если здесь не указать интересующий нас OID, то и в прототипе он не будет работать - "не нашелся" так сказать.

Но эксперимент показал, что это не так. В самом правиле обнаружения я указал допустим - discovery[{#SENSOR_LOCALE},1.3.6.1.4.1.232.6.2.6.8.1.3]
А в прототипе уже прописал - 1.3.6.1.4.1.232.6.2.6.8.1.4.{#SNMPINDEX}


И все работает. Данные получаются...
Зачем тогда в самом правиле поиска вообще что-то искать? Когда по логике можно в прототипе прописать нужное.

[Kos]

Главная задача правила обнаружения в SNMP LLD - по указанной ветке OID-а пробежаться по таблице и собрать список индексов в этой таблице.
Далее этот список индексов будет использоваться в прототипах в качестве значения макроса {#SNMPINDEX}.
Таким образом, если у вас несколько таблиц с одинаковыми индексами, то, по большому счёту, без особой разницы - какую именно из них указывать в правиле LLD.

Однако, кроме основной задачи, есть и вспомогательные.

Например, первая вспомогательная задача - сгенерировать более-менее удобные имена для элементов данных и триггеров. Поэтому, как правило, в качестве таблицы, например, для списка интерфейсов выбирается не абы какая таблица, а та, которая содержит читаемые (и, желательно, постоянные - не зависимо от последующих перезагрузок и изменений конфигурации) имена интерфейсов. Тогда макрос, соответствующий этому OID-у в правиле обнаружения, можно спокойно использовать как в ключах прототипов элементов данных, так и в названиях (самих элементов данных и триггеров).

Другая вспомогательная задача - иметь возможность фильтрации нужных элементов таблицы, чтобы не создавать ненужные объекты. И тут часто оказывается удобным использовать не одну, а несколько таблиц в правиле обнаружения. Например, с теми же интерфейсами - на большом стеке свитчей (с несколькими сотнями портов) нет смысла мониторить те порты, которые не используются. Поэтому в правиле LLD можно указать два OID-а: один - для таблицы с именами интерфейсов, а второй - для таблицы с параметром AdministrativeStatus; и в фильтре правила LLD указать, что интересуют только те порты, у которых параметр "AdministrativeStatus" соответствует состоянию "up".

[Kos]

Главная задача правила обнаружения в SNMP LLD - по указанной ветке OID-а пробежаться по таблице и собрать список индексов в этой таблице.
Далее этот список индексов будет использоваться в прототипах в качестве значения макроса {#SNMPINDEX}.
Таким образом, если у вас несколько таблиц с одинаковыми индексами, то, по большому счёту, без особой разницы - какую именно из них указывать в правиле LLD.

Однако, кроме основной задачи, есть и вспомогательные.

Например, первая вспомогательная задача - сгенерировать более-менее удобные имена для элементов данных и триггеров. Поэтому, как правило, в качестве таблицы, например, для списка интерфейсов выбирается не абы какая таблица, а та, которая содержит читаемые (и, желательно, постоянные - не зависимо от последующих перезагрузок и изменений конфигурации) имена интерфейсов. Тогда макрос, соответствующий этому OID-у в правиле обнаружения, можно спокойно использовать как в ключах прототипов элементов данных, так и в названиях (самих элементов данных и триггеров).

Другая вспомогательная задача - иметь возможность фильтрации нужных элементов таблицы, чтобы не создавать ненужные объекты. И тут часто оказывается удобным использовать не одну, а несколько таблиц в правиле обнаружения. Например, с теми же интерфейсами - на большом стеке свитчей (с несколькими сотнями портов) нет смысла мониторить те порты, которые не используются. Поэтому в правиле LLD можно указать два OID-а: один - для таблицы с именами интерфейсов, а второй - для таблицы с параметром AdministrativeStatus; и в фильтре правила LLD указать, что интересуют только те порты, у которых параметр "AdministrativeStatus" соответствует состоянию "up".

[Diesel315]

Спасибо большое за подробный ответ.
Очень доходчиво.