Zabbix + JSON numbers have quotation marks

[cru5ader]

Вечер добрый!

Правильно ли я понимаю, что вывод json для заббикса требует такой вид:

{ "{#FSNAME}":"\/", "{#FSTYPE}":"rootfs" },

где вывод данных (в данном случае "\/" и "rootfs" ) обязательно должен быть в кавычках, судя по стандартам json, этого не требуется.

http://www.ecma-international.org/publications/files/ECMA-ST/ECMA-404.pdf

Просто этот момент смущает меня очень.

[zyxar]

3.4 Discovery of SNMP OIDs, там ниже примеры JSON

[sadman]

В Zabbix-е "ненастоящий" JSON - нет, к примеру, анализа false/true, сам анализ построчный, а не потоковый. Да и требование к экранированию некоторых символов (начиная с какой-то версии) изменилось.

Мне тоже постоянно эксперименты ставить приходится - проскочит json или крестами покроется

[Kos]

[...] где вывод данных (в данном случае "\/" и "rootfs" ) обязательно должен быть в кавычках, судя по стандартам json, этого не требуется.

http://www.ecma-international.org/pu...t/ecma-404.pdf

Почитал документ по Вашей ссылке (кстати, спасибо за неё, документ лаконичный - всего 4 страницы).
Насколько я понял, кавычки необязательны только для числовых значений. Для строк (которыми являются и строковые значения, и все имена) кавычки обязательны:

a string is a sequence of unicode code points wrapped with quotation marks (u+0022).

Т.е. в Вашем примере - по стандартам json это как раз-таки требуется.

[sadman]

В Zabbix-е "ненастоящий" JSON - нет, к примеру, анализа false/true,

Прошу прощения перед разработчиками, скачал и посмотрел исходники 2.4.7 - true/false/null распознает, судя по switch-у. Почему же у меня не получалось использовать их в фильтре - загадка...

[cru5ader]

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

Пример я как раз таки взял Ваш.
И данные которые я получаю как раз таки числовые, Вот мой пример:

{ "{#IPRANGE}":"10.231.255.226 - 10.231.255.254", "{#IPDEFINED}":253, "{#IPUSED}":0, "{#IPTOUCHED}":0, "{#IPFREE}":253 },

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

[Kos]

Пример я как раз таки взял Ваш..

Мой? Вы ничего не путаете?

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

Ну, если у Вас информация от разработчика - то, наверное, он лучше знает, как там реализовано. Я тогда, правда, не очень понимаю суть Вашего вопроса на этом форуме, если у Вас уже есть квалифицированный ответ. Было бы интересно узнать, если не секрет, что ещё рассказал об этом разработчик - например, в чём именно некорректность при работе Zabbix-а с JSON-ом, в каких именно случаях она проявляется, а главное - как оформлять эти JSON-ы так, чтобы Zabbix точно их обрабатывал.

[cru5ader]

Мой? Вы ничего не путаете?

Ну, если у Вас информация от разработчика - то, наверное, он лучше знает, как там реализовано. Я тогда, правда, не очень понимаю суть Вашего вопроса на этом форуме, если у Вас уже есть квалифицированный ответ. Было бы интересно узнать, если не секрет, что ещё рассказал об этом разработчик - например, в чём именно некорректность при работе zabbix-а с json-ом, в каких именно случаях она проявляется, а главное - как оформлять эти json-ы так, чтобы zabbix точно их обрабатывал.

Пример был взят с сайта заббикс.
У меня претензий нет, я хочу просто разобраться почему без двойных кавычек заббикс не "съедает" данные.

[sadman]

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

static zbx_json_type_t	__zbx_json_type(const char *p)
{
	if ('"' == *p)
		return ZBX_JSON_TYPE_STRING;
	if (('0' <= *p && *p <= '9') || '-' == *p)
		return ZBX_JSON_TYPE_INT;
	if ('[' == *p)
		return ZBX_JSON_TYPE_ARRAY;
	if ('{' == *p)
		return ZBX_JSON_TYPE_OBJECT;
	if ('n' == p[0] && 'u' == p[1] && 'l' == p[2] && 'l' == p[3])
		return ZBX_JSON_TYPE_NULL;

	zbx_set_json_strerror("Invalid type of JSON value \"%.64s\"", p);

	return ZBX_JSON_TYPE_UNKNOWN;
}

Т.е. то, что начинается с " - строка, с [0..9-] - число, с [ - массив, с { - объект. Однако, перед декодированием строка проходит валидацию (процедуры, написанные другим человеком), в которой уже всё по стандарту JSON - true/false и \uXXXX -числа, и даже числа, начинающиеся с +...
Таким образом JSON может валидацию пройти, но после быть декодированным несколько иначе, чем ожидается.

А в чем проявляется пищевое отравление вашего Заббикса?

[Kos]

Пример был взят с сайта заббикс.
У меня претензий нет, я хочу просто разобраться почему без двойных кавычек заббикс не "съедает" данные.

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

Если я правильно Вас понимаю (в чём уже сомневаюсь), то у Вас что-то не работает в случае, когда передаются числовые значения. Но неясно, что же именно работает не так, как ожидается. Напишите, пожалуйста, ещё раз суть проблемы. Числовые значения тоже приходится брать в кавычки, иначе возникает ошибка? Как именно это у Вас проявляется? Что именно Вы делаете, что при этом происходит?