Legacy vs current (walk) SNMP polling

[juanmarcos]

So the trend seems to be that one should use "meta" walk items polling the required OIDs and then reference those in the prototypes.

However
1) you lose overview: Short of looking up an instantiated item (when it's too late), the item prototypes screen doesn't show e.g. the different items' intervals anymore, but you have to go look in the master item.
2) for every type of item for which you want e.g. a separate update interval you'd have to create a standard "walk" item (the "meta" item I wrote about), probably that would be by subtree...

I don't know what exactly the problem was that should be solved by doing this differently.
Probably the issue was hammering the devices with individual requests all the time.
However this new approach seems like a workaround the user is supposed to implement (and understand).
While it seems that the underlying system should take care of it and not force the user to setup sth not very straightforward.
Pooling of the requests could probably be addressed by the application. I'd imagine since the system knows what needs to be done it can pool the requests and "combine walk" whatever is necessary instead of hammering the devices with individual GETs of the same stuff a hundred times. If that is the problem.

Thoughts?


BTW Also one should say this is not very well documented for such very important (basic) stuff.

The "Item, trigger, graph prototypes" section could be way more detailed. (here: https://www.zabbix.com/documentation...snmp_oids_walk)

I only found out what exactly to do via the forum:

https://www.zabbix.com/forum/zabbix-help/462864-zabbix-6-4-and-new-snmp-walk-discovery-rule?p=463022#post463022

Step 1: make the item which will do the walk[] over your OIDs
Step 2: make a discovery rule which uses the master item you just made, in pre-processing you add SNMP to Jsonpath with filenames {#IF.DESC} {#IF.IN.OCTETS} etc and the OID without the index.
Step 3: make the item prototype, in pre-processing you use "snmp walk value" with parameters like: 1.3.6.1.2.1.2.2.1.10.{#SNMPINDEX}

[quackduck]

All I can say is this.

It's not documented, so you won't find it in the official documentation. I read through the whole documentation very carefully but it lacked several crucial things. Some things in the documentation even felt a bit misleading - had nothing to do with what someone reasonably could expect those articles to be about.

You'll have to look through multiple sources and do a lot of trial and error. Unfortunately I can't share my internal article that I had to write for how to do this.

The big picture (IIRC):
1. Create a main SNMP walk item. All it does, is walking the SNMP table that you're interested in.
2. Create a discovery rule (or maybe it was another item(s) somewhere...) that use that walk as a dependent item.. and then preprocess it as something..

This will give you part of the picture, but many questions will remain:https://blog.zabbix.com/improving-sn...lection/27231/