Custom LLD and Item Prototypes

[MopedHelena]

Hi,

I guess I will annoying some people with my question but I spent a lot of hours and it seems that I still didn't figured out how LLD really works.

Actually I haven't used custom LLDs until now but I want to monitor a Windows folder (filenames and their size) and LLD seems to be the way to go. After hours of try and error following the Zabbix documentation (https://www.zabbix.com/documentation...evel_discovery) I followed this guide https://smartsolutions.dioss.com/en/...ry-json-lists/ and got it working.

What I don't understand is why I need to collect the JSON data first in a kind of Master/Dummy item only to make a dependent discovery rule on the Master/Dummy item again and then a dependent item prototype (all guides I found on the web follow this scheme). Isn't there a easier way to get this type of information without this Master/Dummy item? As I said I spent some hours on processing the JSON data I catched with the discovery rule (Agent / key vfs.dir.get[D:\data]) directly and trying to figure out how to make item prototypes with the result.

What is the advantage of the Master/Dummy item method or is it really the (only?) way to go?

[ISiroshtan]

Hey there

What I don't understand is why I need to collect the JSON data first

Well the thing is.. you technically don't need to, if you don't want to. For Zabbix LLD the JSON is needed for one and one thing only - to get a list of entities through which to iterate and create prototype items and triggers. So instead of having JSON like

[
{
"basename": "status-foo.txt",
"pathname": "/var/lib/misc/status-foo.txt",
"dirname": "/var/lib/misc",
"type": "file",
"user": "root",
"group": "root",
"permissions": "0644",
"uid": 0,
"gid": 0,
"size": 0,
"time": {
"access": "2022-03-18T13:18:31+0100",
"modify": "2022-03-18T13:18:31+0100",
"change": "2022-03-21T19:08:03+0100"
},
"timestamp": {
"access": 1647605911,
"modify": 1647605911,
"change": 1647886083
}
...

you could as well feed it the

[{"pathname": "/var/lib/misc/status-foo.txt"}, {"pathname": "/var/lib/misc/status-bar.txt""}, ... , {"pathname": "/var/lib/misc/some_other_path""}]

and it would be enough to satisfy LLD requirement. Then instead of creating dependent item prototypes pointing back to JSON you can create a item prototypes of zabbix-agent type (or any other that would be able to get info you need) and make them pull information based on {#pathname} LLD macros directly from host.

So if it does not needed for LLD, why do we use dependent items?
Following the guide. you already getting all the information you need (presumably) via vfs.dir.get[/var/lib/misc]. So why would you want to get the same information again by other means? As information was already gathered and reported to Zabbix, it makes more sense to process it inside of Zabbix extracting needed bits of information that you need into dependent items.

So the benefit of using dependent items (in THIS) case - you not creating extra load for your hosts and network by requesting the same information again via different items but instead creating bit of extra load on Zabbix server side by extra (pre)processing steps.


Hope my answer makes sense for you

[cyber]

Why double dependents? Both disco and items? ... because then you need to obtain data only once ... you master item gets all data. Discovery will be triggered on first run and all items will be created. With next run of master item, all your previously created dependent items will get their values from master. You do not need to query data for each item separately. If there is a new item in master data, discovery will add it. If something is not there any more, it will be marked as "not discovered any more" and will be removed later (after the "keep lost resources" period).

[MopedHelena]

Thank you both for your detailed explainations.