Универсализация LLD правила

[fractal90]

Всем привет, хотел бы спросить совета, мне надо опросить статус BFD с устройства

OID имеется

snmpwalk -v2c -c cisco_zabbix 172.26.84.1 1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4 -On
.1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4.192.168.101.222.4.192.168.101.90.12346.12346.2 = INTEGER: 1
.1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4.192.168.101.222.4.192.168.101.198.12346.12346.2 = INTEGER: 1
.1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4.192.168.101.222.4.192.168.101.218.12346.12346.2 = INTEGER: 1
.1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4.192.168.101.222.4.192.168.101.219.12346.12346.2 = INTEGER: 1
.1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4.192.168.101.222.4.192.168.101.221.12346.12346.2 = INTEGER: 1
.1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4.192.168.101.222.4.192.168.101.228.12346.12346.2 = INTEGER: 1
.1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4.192.168.101.222.4.192.168.101.229.12346.12346.2 = INTEGER: 1

Я сделал LLD discovery[{#BFD_BACKUP_CHANNEL},1.3.6.1.4.1.9.9.1002.1.1.1.1 .10.4] с фильтром {#SNMPINDEX} = 192.168.101.228

Параметр обнаруживает и создает прототип элемента данных - 1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4.{#SNMPINDEX}

и тут я задумался, мне надо создать элементы которые имеют в себе индекс 192.168.101.218 / 192.168.101.219 / 192.168.101.228 / 192.168.101.229, вариант в ЛОБ сделать таких 4 штуки LLD, но может есть какой то способ сделать это более динамически?

Допустим нашел я элемент согласно моему фильтру LLD - .1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4.192.168.101.222 .4.192.168.101.228.12346.12346.2 = INTEGER: 1, значение 192.168.101.222.4.192.168.101.228.12346.12346.2 я использовал для созданияпрототипа, а потом в имени прототипа указал - BFD to {$HOST} и в эту переменную добавил 192.168.101.228, исключив (красным) из значения которое нашлось в фильтре все до этого ip и после

<192.168.101.222.4.> 192.168.101.228 <.12346.12346.2>

[Kos]

Не совсем понятно, о чём именно вы спрашиваете.
Если в правиле LLD используется указанный вами OID:

discovery[{#BFD_BACKUP_CHANNEL},1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4]

то для приведённого вами же примера (вывод snmpwalk) в качестве индексов (т.е. значений макросов {#SNMPINDEX}) будет оставшаяся часть их OID-ов, т.е.:

192.168.101.222.4.192.168.101.90.12346.12346.2
192.168.101.222.4.192.168.101.198.12346.12346.2
192.168.101.222.4.192.168.101.218.12346.12346.2
192.168.101.222.4.192.168.101.219.12346.12346.2
192.168.101.222.4.192.168.101.221.12346.12346.2
192.168.101.222.4.192.168.101.228.12346.12346.2
192.168.101.222.4.192.168.101.229.12346.12346.2

Очевидно, ни одно из этих значений не совпадает с указанными вами фильтром: 192.168.101.228.

Если же вопрос в том, как в одном фильтре указать несколько значений, то нужно помнить, что значением фильтра в LLD является регулярное выражение, т.е. можно прописать фильтр, например, так:

{#SNMPINDEX} matches ^192.168.101.(218|219|228|229)

[fractal90]

да, все верно, в качестве индексов как раз будет оставшаяся часть их OID-ов

192.168.101.222.4.192.168.101.90.12346.12346.2
192.168.101.222.4.192.168.101.198.12346.12346.2
192.168.101.222.4.192.168.101.218.12346.12346.2
192.168.101.222.4.192.168.101.219.12346.12346.2
192.168.101.222.4.192.168.101.221.12346.12346.2
192.168.101.222.4.192.168.101.228.12346.12346.2
192.168.101.222.4.192.168.101.229.12346.12346.2

с помощью фильтра

{#SNMPINDEX} matches 192.168.101.228

я выбираю из этого перечня вот этот

192.168.101.222.4.192.168.101.228.12346.12346.2

в итоге создается элемент 1.3.6.1.4.1.9.9.1002.1.1.1.1.10.4.192.168.101.221. 4.192.168.101.228.12346.12346.2 = со значением 3 (up)

192.168.101.228 - это удаленный шлюз VPN до которого строится BFD связность - проверка UP/DOWN,

если сделать такой фильтр

{#SNMPINDEX} matches ^192.168.101.(218|219|228|229)

то естественно найдутся все значения из списка, но они будут с длинным именем

Имя прототипа такого плана, - Доступность узла {#SNMPINDEX} которое создает прототипы

Доступность узла 192.168.101.222.4.192.168.101.198.12346.12346.2
Доступность узла 192.168.101.222.4.192.168.101.218.12346.12346.2
Доступность узла 192.168.101.222.4.192.168.101.219.12346.12346.2
Доступность узла 192.168.101.222.4.192.168.101.221.12346.12346.2
Доступность узла 192.168.101.222.4.192.168.101.228.12346.12346.2
Доступность узла 192.168.101.222.4.192.168.101.229.12346.12346.2

. в MIB нет идентификатора к которому я мог бы подвязаться для указания идентификатора в имени, вот поэтому и задумался, а можно ли после того как найдется искомое значение указанное в фильтре подставить его в имя вырезав лишнее, чтобы вышло так:

Доступность узла 192.168.101.198
Доступность узла 192.168.101.218
Доступность узла 192.168.101.219
Доступность узла 192.168.101.221
Доступность узла 192.168.101.228
Доступность узла 192.168.101.229​

Сейчас у меня просто созданы 6 LLD правил для каждого узла и имена у них просто указаны по имени девайса

Доступность узла vpn1
Доступность узла vpn2
Доступность узла vpn3
Доступность узла vpn4
Доступность узла vpn5
Доступность узла vpn6

[Kos]

в MIB нет идентификатора к которому я мог бы подвязаться для указания идентификатора в имени, вот поэтому и задумался, а можно ли после того как найдется искомое значение указанное в фильтре подставить его в имя вырезав лишнее, чтобы вышло так:

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

[fractal90]

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

Спасибо за наводку, буду изучать