Получение измененного {#SNMPINDEX} в LLD

[AQS]

Есть обнаружение:
discovery[{#DEVNAME},1.3.6.1.4.1.9.9.23.1.2.1.1.6,...
Проблема в том что оно возвращает {#SNMPINDEX}=1001.1
В данной ветке этот индекс работает отлично, но мне нужно получить несколько параметров содержащих индекс {#SNMPINDEXSHORT}=1001 (удалить последние два символа)

Как создать переменную (макрос) содержащую {#SNMPINDEX} без двух последних символов?

[Kos]

Делать предобработку в правиле LLD, которая с помощью JavaScript добавит требуемый макрос с нужным значением.
Пример такой предобработки приводился не так давно в этой теме (ссылка).

[AQS]

//transform a source string into JSON object
val_json=JSON.parse(value);
//Обрезка SNMPINDEX на два символа
for (i in val_json) {

val_json[i]["{#SNMPINDEXSH}"] = val_json[i]["{#SNMPINDEX}"].substring(0,val_json[i]["{#SNMPINDEX}"].length-2);
}
//return the result as a string
return JSON.stringify(val_json);

Спасибо

А подскажите можно както получить доступ к значению элемента не в LLD? Ну или почему не работает дефолтовый макрос {HOST.HOST}

[AQS]

Скрипт работает верно, тест с оборудования показывает что в {#SNMPINDEXSH} попадает нужное число.

Проблемма в том что элемент данных не создаеться по прототипу.
Используеться OID:
.1.3.6.1.2.1.31.1.1.1.6.{#SNMPINDEXSH}
Тест, при ручном заполнении {#SNMPINDEXSH}, выдает нужные данные, но элемент данных в узле сети не появляется...

[Kos]

А подскажите можно както получить доступ к значению элемента не в LLD? Ну или почему не работает дефолтовый макрос {HOST.HOST}

Возможно, я неправильно понял вашу задачу - видимо, вам нужен не сам по себе LLD-макрос, содержащий SNMP-индекс, а значение, которое извлекается по такому OID-у.
Нет, доступа к другому значению из LLD-правила получить нельзя. Можно, разве что, объединять в одном правиле несколько SNMP таблиц, но эти таблицы должны иметь одинаковую размерность и индексы - например, сетевые интерфейсы: таблица их имён, их состояний (ifAdminStatus) и текущего статуса (ifOperationalStatus) и т.п. Но, похоже, это не ваш случай.
Если это та же задача, что и в соседней теме (ссылка), то лучше не размазывать обсуждение по нескольким темам, а продолжать там.

[AQS]

Приношу свои извинения, но по данной теме все равно остался вопрос. (см выше)

[Kos]

Покажите, пожалуйста, пример того, как выглядит JSON, получаемый в качестве результата LLD-правила, и скриншот настроек прототипа элемента данных.

[AQS]

Покажите, пожалуйста, пример того, как выглядит JSON, получаемый в качестве результата LLD-правила, и скриншот настроек прототипа элемента данных.

Дискавери:

discovery[{#DEVNAME},1.3.6.1.4.1.9.9.23.1.2.1.1.6,{#INTNAME} ,1.3.6.1.4.1.9.9.23.1.2.1.1.7,{#DEVMODEL},1.3.6.1. 4.1.9.9.23.1.2.1.1.8,{#VLAN},1.3.6.1.4.1.9.9.23.1. 2.1.1.11,{#UPLINK},1.3.6.1.4.1.9.9.23.1.2.1.1.24]

Результат (после скриптов):

[{"{#SNMPINDEX}":"10102.1","{#DEVNAME}":"C3750_2k1_CORE_stack.msk.miit.ru","{#INTNAME}":"GigabitEthernet2/0/2","{#DEVMODEL}":"cisco WS-C3750G-24PS","{#VLAN}":"1","{#UPLINK}":"2972273237","{#SNMPINDEXSH}":"10102","{#DEVNAMESH}":"C3750_2k1_CORE_stack"}]

[HIDEN]





[/HIDEN]


При этом элемент данных не создается

[Kos]

При этом элемент данных не создается

Спасибо.
Странно, я своим взглядом проблем в конфигурации тоже не вижу.

Могу предположить лишь следующее:

• либо нужные вещи отфильтровываются, т.к. для правила LLD заданы какие-то фильтры, не дающие создать элемент данных из прототипа (проверьте, пожалуйста);
• либо при попытке его создать возникает какая-то ошибка; но в этом случае она должна фигурировать как в логе сервера Zabbix, так и в веб-интерфейсе (при настройках правила обнаружения справа будет красная пометка, при наведении мышкой на неё - высвечивается текст ошибки).

На скринште видно, что для этого правила обнаружения указан не один прототип элемента данных, а десять. Не работает ни один из них, или же девять элементов данных создаются, а десятый - нет?
Правильно ли я понимаю, что JSON, генерируемый правилом дискаверинга, содержит только одну строку (для единственного "{#SNMPINDEX}":"10102.1", а других значений индекса нет)?
Если же нет (т.е. значений индексов больше), то отличаются ли они последним или предпоследним компонентами (например, "10102.1", "10102.2", "10102.3" и т.д., или же "10102.1", "10103.1", "10104.1" и т.д.)?

[AQS]

1) Фильтров нет, проверил.
2) Вы правы:

Cannot process LLD macro "{#SNMPINDEXSH}": unsupported construct in jsonpath starting with: "{#SNMPINDEX}".

3) Элементы данных разные, те что используют #SNMPINDEX создаються, те что с #SNMPINDEXSH - нет
4) Для данного устройства одна строка, в особо запутанных случаях может быть комбинация ваших примеров. Первое число это snmp номер порта устройства, второе порядковый номер cdp обнаружения на порту. В реальных условиях часто будет "10102.1", "10103.1", "10104.1".

Скрипт:

//transform a source string into JSON object
val_json=JSON.parse(value);
//Обрезка SNMPINDEX на два символа
for (i in val_json) {

val_json[i]["{#SNMPINDEXSH}"] = val_json[i]["{#SNMPINDEX}"].substring(0,val_json[i]["{#SNMPINDEX}"].length-2);
}
//return the result as a string
return JSON.stringify(val_json);

[Kos]

Ну, я надеюсь, что лишние пробелы в ваших примерах discovery и результата (после скриптов) - это просто артефакты отображения на форуме?
Других нарушений структуры JSON-а я не вижу.
Можно, разве что, предложить в порядке экперимента переименовать ваши макросы на более короткие и не включающие в себя имена других макросов - например, {#MY_INDEX} и {#MY_DEVNAME}. Ещё можно заменить (опять же, в порядке эксперимента) ваш собственный макрос на стандартный {#SNMP_INDEX} как в ключе, так и в OID-е прототипа, после чего убедиться, что элемент данных создаётся корректно (работать он, правда, не будет, но создаваться-то должен), а затем - по одному возвращаться к исходному макросу (начиная с OID-а, где это важно для функционала; для ключа можно даже оставить и так).

[AQS]

Ну, я надеюсь, что лишние пробелы в ваших примерах discovery и результата (после скриптов) - это просто артефакты отображения на форуме?

Это автодобавление переноса в редакторе форума... Если копировать не напрямую с http страницы забикса, а через блокнот, то все нормально.

Переименовать макросы попробовал, не помогло...

[Kos]

Переименовать макросы попробовал, не помогло...

Теперь ругается на макрос с новым именем?

[AQS]

Теперь ругается на макрос с новым именем?

Cannot process LLD macro "{#INDEXSH}": unsupported construct in jsonpath starting with: "{#SNMPINDEX}".

И как теберь из обнаружения {#SNMPINDEX}":"10102.1" обратиться в ветку .1.3.6.1.2.1.31.1.1.1.6.10102?

[Kos]

Макрос {#INDEXSH} сейчас присутствует и в JSON-е, и в прототипе элемента данных?

Я не понимаю смысла этой ругани. Жалуется на некую неподдерживаемую конструкцию в JSON-е; но в единственном JSON-е, который Вы привели, я не вижу ничего криминального (кроме лишних пробелов, которые мог вставить движок этого форума). Кроме того, эта (якобы) некорректность не помешала создать элементы данных из остальных прототипов; то есть если некорректность в JSON-е и есть, то некритичная (другие макросы обрабатываются вполне успешно).

Что будет происходить, если макрос {#INDEXSH} оставить в JSON-е, а в прототипе элемента данных его не использовать? Как я описывал раньше: заменить его стандартным макросом
{#SNMPINDEX}, а после того, как элемент данных из такого прототипа успешно создастся - заменить в прототипе макрос в графе OID снова на {#INDEXSH}?

(добавлено)
Только сейчас заметил: ругается-то не на JSON, а на JSONPath.
Проверьте, пожалуйста, нет ли у вас где-то (вероятно, в правиле препроцессинга) шагов препроцессинга (предобработки) с типом "JSONPath". Вероятно, проблема там.