прототипы, lld.

[Lekas]

Доброго времени суток!

К сожалению нашел не так много информации и/или, видимо, не понимаю логику.
Есть скрипт на хостах, который возвращает JSON:

{
"data" : [
{
"{#GPUTEMP}" : "54",
"{#GPUNAME}" : "PCI_SLOT_NAME=0000:05:00.0",
"{#GPUFAN}" : "1795"
},
{
"{#GPUNAME}" : "PCI_SLOT_NAME=0000:06:00.0",
"{#GPUFAN}" : "1837",
"{#GPUTEMP}" : "61"
}
]
}


Количество хостов и GPU не известно и/или не конечно, следовательно необходима авторегистрация и низкоуровневое обнаружение.

Прототип элемента данных получает правильные значения {#GPUNAME}, {#GPUFAN} и {#GPUTEMP}, но после каждого изменения значения у меня создаётся новый элемент данных (скрин в аттаче).

Можно ли вообще передавать одним JSON`ом все необходимое (скорее даже: как правильнее передавать и принимать)?
Или обязательно необходимо у агента в конфиге делать два UserParametr`а и делать отдельный скрипт, который будет вырезать нужное значение, как в примерах с файловыми системами?

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

Что я делаю не так? ))

Фото в аттаче.


PS: не судите строго, это мой первый опыт LLD.

PSS: Zabbix 3.4.10.

Заранее благодарен за помощь.

[sadman]

Gpufan - это скорость вращения вентилятора что ли? с какой целью вы ее в имя ключа подставляете?

[Lekas]

Добрый день!

Да, это скорость вращения вентилятора.

Очевидно я не правильно понимаю логику и предполагал, что это идентификатор значения параметра, из которого будет создан один элемент данных. Но в данном случае новый элемент данных создаётся при каждом изменении значения.
Можете подсказать как исправить это? формат Json - можно изменить, если необходимо, его делает скрипт.

GPUTEMP - температура
GPUNAME - имя карты. (PCI-слота)
GPUFAN - скорость вращения вентилятора.

[teddy]

Доброго времени суток!

К сожалению нашел не так много информации и/или, видимо, не понимаю логику.
Есть скрипт на хостах, который возвращает JSON:

{
"data" : [
{
"{#GPUTEMP}" : "54",
"{#GPUNAME}" : "PCI_SLOT_NAME=0000:05:00.0",
"{#GPUFAN}" : "1795"
},
{
"{#GPUNAME}" : "PCI_SLOT_NAME=0000:06:00.0",
"{#GPUFAN}" : "1837",
"{#GPUTEMP}" : "61"
}
]
}


Количество хостов и GPU не известно и/или не конечно, следовательно необходима авторегистрация и низкоуровневое обнаружение.

Прототип элемента данных получает правильные значения {#GPUNAME}, {#GPUFAN} и {#GPUTEMP}, но после каждого изменения значения у меня создаётся новый элемент данных (скрин в аттаче).

....
Заранее благодарен за помощь.

По LLD вы должны создавать описание того, что потом будете опрашивать. В вашем примере скорее всего что то типа ELEMENT_{#GPUNAME} с ключом my.key.request[{#GPUNAME}] где ключ ( запрос ) с параметром имя ресурсов, которое вы получаете макросом {#GPUNAME}, уже будет забирать и получать собственно данные.

[sadman]

Добрый день!

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

Все так и есть: в LLD каждый раз приходят разные значения скорости (и это естественно), а Zabbix следуя правилам, создает новые айтемы - ведь их еще нет. Полагаю, что вам не нужно использовать в ключе нечто, что меняется так быстро. Найдите более устойчивый идентификатор. И, как правильно отметил teddy - необходим второй этап - на котором будет по идентификатору запрашиваться температура и скорость. А совать их в LLD - контрпродуктивно. Если вы хотите закидывать все значения махом, то есть другие пути, но они более сложные в понимании.

[Lekas]

Спасибо за ответы.

Идентификатор, который не меняется - это "{#GPUNAME}", в данный момент создаётся элемент данных с именем, с этим проблем нет.
Получается, что мне в конфиг zabbix_agent надо добавить ещё один UserParametr и, соответственно, скрипт который будет возвращать значения параметров по "{#GPUNAME}"?

Вообще я и хотел закидывать всё и сразу, именно поэтому я и думал, что данный метод мне подходит.

А можете дать мне ссылку на статью про "более сложные в понимании" методы?

[sadman]

Спасибо за ответы.

Получается, что мне в конфиг zabbix_agent надо добавить ещё один UserParametr и, соответственно, скрипт который будет возвращать значения параметров по "{#GPUNAME}"?

Да.

Для заброса данных так же можно применить https://www.zabbix.com/documentation...mtypes/trapper

[Lekas]

Спасибо за ответ и ссылку на ман, обязательно почитаю.
Но я тут нашел описание https://www.zabbix.com/forum/in-russ...ix-trapper-lld

и ещё https://blog.zabbix.com/zabbix-3-4-m...-example/5784/
Пример с Меркурием идеально подходит, но там реализация без LLD.

Если я всё правильно понимаю, то в данном примере меркурий отдаёт один раз Json со всеми значениями а zabbix-server его уже дербанит по элементам данных.
В случае с созданием прототипов элементов данных я не понимаю что делать с ключами.

Согласно описанию описанию происходит так:
1. родительский прототип получает полный json.
2. дочерний прототип вытаскивает значения параметров из того же json`а (берёт его у родителя)
На мой взгляд это идеальный вариант.

Вариант со вторым Userparametr можно сделать и будет работать, но количество проверок будет огромно (на мой взгляд). Если примерно, то больше 1000 устройств, и с каждого устройства надо снять минимум 2 параметра (скорее всего появится и 3-й). Хотелось бы минимизировать количество обращений.

[mykolaq]

ос windows у вас? есть пример lld с помощью openhardwaremonitor и wmi. могу поделиться

[Lekas]

Нет, у меня всё на линухе.

lm-sensors подошел бы, но есть параметры, которые только скриптом могу дернуть, поэтому и говорю, что это было бы идеальным вариантом.

[Lekas]

ос windows у вас? есть пример lld с помощью openhardwaremonitor и wmi. могу поделиться

Прошу прощения, не сразу вчитался)) Если у Вас в примере lld дёргает динамические значения, буду признателен если поделитесь примером.

Заранее спасибо!