discovery[snmp] обрезает ответ по символу переноса строки.

[DeadPool]

Всем привет.
Предполагаю что это баг, но, возможно есть решение... Сам не нашел =(
Делаю LLD discovery[{#MACRO},oid] этот OID возвращает строковый результат, но не в одну строку, а в несколько (3-4), сервер в discovery[] обрезает этот результат по первой строке, т.е. по символу переноса строки \n, а нужны все строки, как можно избежать обрезания строк?
Если этот же самый OID запрашивать как метрику на хосте через SNMP Агент - то ответ приходит в нормальном виде, в несколько строк, не обрезанный, все 3-4 строки.

Тестировал на версии 4.4.6 и на последнем zabbix-appliance из докер образа ubuntu-trunk (5.0.1beta1)

[demidtor]

Пробовали поставить тип возвращаемого результата как - текст?

[DeadPool]

В LLD?... Там нету настроек получаемого результата, он возвращает JSON объект с массивом запрошенных {MACRO},OID и данные там могут быть различные.

[demidtor]

Как же нет, когда есть.

[DeadPool]

Я же написал, в первом сообщении, что делаю LLD discovery[]. Про прототипы элементов данных речи не идет, прототипы создаются уже на основе LLD discovery. Вот у вас "Список обнаружений / Network interfaces" Вот нажмите на "Network interfaces" и попробуйте там выбрать "Тип информации".

[demidtor]

А я о чем пишу? Поймите разницу между правилами обнаружения и прототипами данных с типами информации, которые и формируются на основе правил обнаружения.

[demidtor]

Общая архитектура процессов обнаружения заключается в следующем.

Сначала, пользователь создает правило обнаружения в “Настройка” → “Шаблоны” → колонка “Обнаружение”. Правило обнаружения состоит из (1) элемента данных, который осуществляет обнаружение необходимых объектов (например, файловые системы или сетевые интерфейсы) и (2) прототипов элементов данных, триггеров и графиков, которые должны быть созданы на основании полученных значений этого элемента данных.


https://www.zabbix.com/documentation...evel_discovery
Читайте. Здесь четко все расписано.

[DeadPool]

А я о чем пишу? Поймите разницу между правилами обнаружения и прототипами данных с типами информации, которые и формируются на основе правил обнаружения.

Вы пишете о прототипе данных, до которого мне еще надо получить полный, а не обрезанный ответ функцией discovery.

Я понимаю разницу между правилом обнаружения и прототипом данных, это вы поймите что мне нужен полный ответ, а не обрезанный от функции dicsovery при обнаружении данных, чтобы потом взять этот ответ и использовать в прототипе данных.

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

https://www.zabbix.com/documentation...very/snmp_oids
Читайте. Здесь тоже четко написано.


Приходит ответ вот такого типа (данных "{MACRO}": "data" там может быть столько, сколько запросите) так вот в одном из "{MACRO}":"data" я запрашиваю OID, который возвращает HEX-string на несколько строк и заббикс обрезает эти несколько строк до одной по символу перевода строки "\n"

[demidtor]

Прошу прощения. Немного не понял вопроса. Ясно теперь. А что за устройство-оид-текст возвращаемого ответа полностью?

[DeadPool]

Принтеры.... возвращают название расходного материала HEX-данными в несколько строк. Но тут не важно какое устройство, если в ответе будет символ переноса строки - то он обрежется по первой строке.
В аттаче пример ответа. Зеленым выделено то, что возвращает принтер, красным подчеркнуто то, до чего обрезает заббикс в discovery.
ЗЫ: как я уже писал в первом сообщении, если этот OID запросить как метрику на хосте через SNMP-Агент то обрезаться ничего не будет, данные будут полными и в истории сохранится все строки , а не только первая

[demidtor]

Да, скорее всего надо глянуть в исходных кодах или скриптах. И еще. В приведенном Вами примере не увидел символа перевода строки.

[Kos]

DeadPool , вот я, честно говоря, не очень представляю, где Вы видите тот получающийся JSON, который отрабатывает в правиле обнаружения. Где-то в логах сервера Zabbix? Или же вы его сами формируете каким-то внешним скриптом?

[DeadPool]

DeadPool , вот я, честно говоря, не очень представляю, где Вы видите тот получающийся JSON, который отрабатывает в правиле обнаружения. Где-то в логах сервера Zabbix? Или же вы его сами формируете каким-то внешним скриптом?

Ну, во первых в мануале написано четко, что возвращает эта функция и в каком виде https://www.zabbix.com/documentation...very/snmp_oids , а во вторых да, в логах я вижу что приходит в discovery. А в третьих в 5м заббиксе/фронтенде появилась возможность в предобработке тестировать шаги предобработки, получая при этом тестируемые данные непосредственно с хоста, а не вводя вручную и там при тесте они тоже приходят огрызком.

"Или же вы его сами формируете каким-то внешним скриптом?" по-моему, в каждом своем сообщении я пишу discovery[{#MCARO},OID]

[Kos]

DeadPool , не обижайтесь, пожалуйста.

по-моему, в каждом своем сообщении я пишу discovery[{#MCARO},OID]

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

И даже отвечая на заданный вопрос у нас получается классическое недопонимание. Мне было бы интересно увидеть сам JSON (конкретно для Вашего случая - какой он получается в результате), а заодно узнать, где именно Вы его наблюдаете (я, например, этого не умею, кроме как включать отладочный режим на сервере и затем долго искать нужный фрагмент в серверных логах). А Вы ссылаетесь на документацию, где написано, какой у него формат должен быть (это я и сам знаю, но мне-то интересно на Ваш посмотреть).
А в пятой версии в самом деле можно тестировать работу правил LLD и видеть получаемый в результате SNMP-запроса JSON? Тогда это для меня ещё один аргумент в пользу перехода на пятёрку.

[demidtor]

Если вернуться к баранам. Меня вообще удивляет разговор про обрезание строки, при наличии символа переноса строки, хотя в приведенном примере нет ни одного вхождения "0A".

[DeadPool]

Прекратите нести чушь... где вы видели чтобы знак переноса строки указывался явно прям вот текстом, чтобы глазами было видно?! У вас прям везде в линуксе после каждой строки стоит \n, а в винде \r\n?!

[DeadPool]

[USER="312851"]

А в пятой версии в самом деле можно тестировать работу правил LLD и видеть получаемый в результате SNMP-запроса JSON? Тогда это для меня ещё один аргумент в пользу перехода на пятёрку.

Да! Очень удобно! Для меня это тоже большой + для перехода на пятерку.

В общем по вопросу из сабжа - это баг, буду создавать тикет на баг трекере. Только что проверил запрос на версию IOS с с циски 2951, она тоже возвращает ответ в несколько строк (без всяких HEXов, просто текст) и, да, тоже обрезалось по первой строке, хотя их 3.