Нет данных в item value

[zabbixlan]

Добрый день, помогите разобрать плз
Отправляю c хоста sender - traptest.discovery {"data":{"drive":[{"number":"K77TFK57","weight":"1380","size":"24 70" }]}}
Создаю discovery rule:
Name: discovery test
Type: Zabbix trapper
Key: traptest.discovery
препроцессинг: $.data.drive
макрос: {#NUMBER} $.number

item prototypes
Name: NUMBER
Type: Dependent item
Key: test[{#NUMBER}]
Preprocessing
$.[?(@.NUMBER == '{#NUMBER}' )].number
Trim []
В итоге прототип данных создаётся, макрос {#NUMBER} указывается в ключе, но данных почему то нет и история пуста, подскажите мб я что то не так указал? как поместить ответ от json в данные?

[Kos]

У вас в данных и в выражении JSONPath регистр слова "number" разный:

{"data":{"drive":[{"number":"K77TFK57","weight":"1380","size":"2470"}]}}

$.[?(@.NUMBER == '{#NUMBER}')].number

Не находит он такого (что вполне логично).

[zabbixlan]

У вас в данных и в выражении JSONPath регистр слова "number" разный:


Не находит он такого (что вполне логично).

Добрый день
поменял, но когда делаю Test item появляется ошибка (ранее не делал этот тест поэтому ошибку не видел): cannot extract value from json by path "$.[?(@.number == '{#NUMBER}' )].number": no data matches the specified path
пробовал и $.data.[?(@.number == '{#NUMBER}' )].number, $.data.drive.[?(@.number == '{#NUMBER}' )].number, $.data.drive[0].[?(@.number == '{#NUMBER}' )].number результат то же
Подскажите а правильно ли я отсылаю сендер в сторону дискавер с соответствующим ключом(traptest.discovery) а не в сторону обычного item?

[Kos]

когда делаю Test item появляется ошибка (ранее не делал этот тест поэтому ошибку не видел): cannot extract value from json by path "$.[?(@.number == '{#NUMBER}' )].number": no data matches the specified path

Похоже, что вы пробуете делать тест не на сгенерированном элементе данных, а на его прототипе. В этот момент значение LLD-макроса {#NUMBER} ещё не подставлено, поэтому тест и не проходит (во всех вариантах). В реальном элементе данных вместо LLD-макроса должно быть уже подставленное реальное значение.

Подскажите а правильно ли я отсылаю сендер в сторону дискавер с соответствующим ключом(traptest.discovery) а не в сторону обычного item?

Вот не знаю. Стандартная практика - иметь один мастер-айтем (с типом "Text" и коротким сроком хранения истории - она нужна только на время отладки, потом можно вообще историю отключить), а остальное (и LLD-rule, и прототипы элементов данных) делать в качестве зависимых от него dependent items, выдёргивая через предобработку нужные фрагменты значения исходного мастер-айтема. Причём, для самого правила LLD крайне желательно через предобработку убирать из JSON-а все динамические данные, оставляя только более-менее статичные значения LLD-макросов, и добавлять шаг предобработки "тротлинг", чтобы не дёргать весь процесс LLD (сравнительно дорогой по ресурсам) каждый раз.
А что у вас сейчас указано в качестве мастер-айтема для прототипов - ваш traptest.discovery?

[zabbixlan]

Похоже, что вы пробуете делать тест не на сгенерированном элементе данных, а на его прототипе. В этот момент значение LLD-макроса {#NUMBER} ещё не подставлено, поэтому тест и не проходит (во всех вариантах). В реальном элементе данных вместо LLD-макроса должно быть уже подставленное реальное значение.

Ага, уже увидел да действительно вы правы, тест не правильно проходил, сделал правильный тест всё хорошо, тест проходит.

Вот не знаю. Стандартная практика - иметь один мастер-айтем (с типом "Text" и коротким сроком хранения истории - она нужна только на время отладки, потом можно вообще историю отключить), а остальное (и LLD-rule, и прототипы элементов данных) делать в качестве зависимых от него dependent items, выдёргивая через предобработку нужные фрагменты значения исходного мастер-айтема. Причём, для самого правила LLD крайне желательно через предобработку убирать из JSON-а все динамические данные, оставляя только более-менее статичные значения LLD-макросов, и добавлять шаг предобработки "тротлинг", чтобы не дёргать весь процесс LLD (сравнительно дорогой по ресурсам) каждый раз.
А что у вас сейчас указано в качестве мастер-айтема для прототипов - ваш traptest.discovery?

В дискавер указал zabbix trapper без зависимостей, я пробовал пускать json через обычный item ловить его дискавером и обрабатывать но почему то обычный айтем не пропускает данную транскрипцию json а только такой {"data":[{"number":"K777K77","weight":"1000","size":"200 0"}]}
Ну и я ещё подумал зачем усложнять процесс если дискавер тоже может делать ловушки

[Kos]

В дискавер указал zabbix trapper без зависимостей

Это понятно, но это не ответ на тот вопрос, который был задан

А что у вас сейчас указано в качестве мастер-айтема для прототипов - ваш traptest.discovery?

[zabbixlan]

Это понятно, но это не ответ на тот вопрос, который был задан

нет указан обычный айтем, дискавер там нельзя указать
кста забыл сказать припроцессинг поменял на $.data.drive.[?(@.number == '{#NUMBER}' )].number с ним тесты проходят

[Kos]

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

Понятно, спасибо.

Просто в такой конфигурации получается, что у traptest.discovery есть своя предобработка; и для меня неясно: при обработке его зависимых элементов данных им передаётся исходный JSON или же уже после этой предобработки. Использование описанной техники как раз позволяет избежать всех этих двусмысленностей: в обычный айтем (с типом "Zabbix trapper" и типом данных "Text") вы засылаете тот JSON, какой хотите; а в зависимых элементах данных уже обрабатываете его так, как нужно для них. А нужно по-разному для правила LLD и для прототипов айтемов.

почему то обычный айтем не пропускает данную транскрипцию json

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

[zabbixlan]

Понятно, спасибо.

Просто в такой конфигурации получается, что у traptest.discovery есть своя предобработка; и для меня неясно: при обработке его зависимых элементов данных им передаётся исходный JSON или же уже после этой предобработки. Использование описанной техники как раз позволяет избежать всех этих двусмысленностей: в обычный айтем (с типом "Zabbix trapper" и типом данных "Text") вы засылаете тот JSON, какой хотите; а в зависимых элементах данных уже обрабатываете его так, как нужно для них. А нужно по-разному для правила LLD и для прототипов айтемов.

Тоесть я так понимаю что всё таки нужно отсылать в обычный айтем и так по цепочке?

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

Да верно, только что переделал json в обычным трапером, и данные да пошли и время повелось единственный момент почему данные обновляются только поле 2-х одинаковых отправок? и если меняешь number то предыдущие становятся с ошибкой?

[Kos]

То есть я так понимаю что всё таки нужно отсылать в обычный айтем и так по цепочке?

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

если меняешь number то предыдущие становятся с ошибкой?

Потому что выражение в предобработке не находит в исходных данных заданный шаблон.

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

[zabbixlan]

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


Потому что выражение в предобработке не находит в исходных данных заданный шаблон.

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

Задача заключается в том что бы ловить json и вытаскивать из него 3 вида данных это nomber, size, weight они будут постоянно разные и создавать по каждому item то есть в итоге должно получится 3 итема. Далее по каждому из них настроить графики\триггер, в теории значения этих данных путём скрипта можно подставить в любом виде к примеру если {#NUMBER} NONE или просто 0 и т.д для всех этих данных то срабатывает аллерт. Ну и смотря на перёд думаю о том что в будущем можно было бы сделать что то интересное на основе этих данных, ну тип статистику выгружать какую ни будь и т.д.

[Kos]

Задача заключается в том что бы ловить json и вытаскивать из него 3 вида данных это number, size, weight они будут постоянно разные и создавать по каждому item то есть в итоге должно получится 3 итема.

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

[zabbixlan]

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

я думал что json который я отправляю это и есть массив данных возможно я ошибался, но вообще формат json есть возможность задать любой, вернее какой нужен.
В теории можно сделать просты проверки тогда скрипт будет отсылать 3 ключа но это как то не практично т.к заббикс очень гибок и хотелось бы работать с одним мэседжом.
Подскажите плз если будет отсылаться массив данных можно ли будет держать всё в одном итеме? и как это реализовать на стороне заббикса? мб есть ли какой то пример?

[Kos]

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

Ну вот ваш исходный JSON из первого сообщения:

{"data":{"drive":[{"number":"K77TFK57","weight":"1380","size":"2470"}]}}

В нём действительно есть массив (то, что в квадратных скобках), но этот массив состоит из одного элемента - объекта с тремя атрибутами (number, weight и size).
Если таких объектов много, тогда есть смысл и в массиве, и в автообнаружении.
Например, передаются данные о множестве драйвов, каждый из которых идентифицируется своим постоянным номером и имеет переменные вес и размер.
В этом случае можно для каждого из них при помощи LLD создавать свои элементы данных - допустим, drive.weight["K77TFK57"] (в который попадёт значение 1380) и drive.size["K77TFK57"] (в который попадёт 2470). Поскольку значения числовые, то по ним можно строить график и легко настроить нужные прототипы триггеров (например, если для какого-то драйва в качестве числового значения пришёл ноль).

[zabbixlan]

Ну вот ваш исходный JSON из первого сообщения:

{"data":{"drive":[{"number":"K77TFK57","weight":"1380","size":"2470"}]}}

В нём действительно есть массив (то, что в квадратных скобках), но этот массив состоит из одного элемента - объекта с тремя атрибутами (number, weight и size).
Если таких объектов много, тогда есть смысл и в массиве, и в автообнаружении.
Например, передаются данные о множестве драйвов, каждый из которых идентифицируется своим постоянным номером и имеет переменные вес и размер.
В этом случае можно для каждого из них при помощи LLD создавать свои элементы данных - допустим, drive.weight["K77TFK57"] (в который попадёт значение 1380) и drive.size["K77TFK57"] (в который попадёт 2470). Поскольку значения числовые, то по ним можно строить график и легко настроить нужные прототипы триггеров (например, если для какого-то драйва в качестве числового значения пришёл ноль).

Добрый день
К сожалению номер тоже не постоянный, все 3 переменные разные, но намёк понял (честно говоря сегодня тоже пришла идея указать за основу переменную которая будет постоянной а за ней уже динамические данные.