-
Problem report
-
Resolution: Duplicate
-
Major
-
None
-
3.4.3
-
None
-
Sprint 20, Sprint 21
Not a bug , but ...
Just FYI, I'm using a patch from ZBXNEXT-4103 to let my SNMPv3 device a chance to work in bulk mode. But it's not related to current case.
But when I use it (bulk really works, with notes), I see an unexpected queue behavior - it's jumping.
When attempt to capture snmp traffic, I could see that maximal OIDs number my device may reach is close to ~60 and as I was able to figure out - it depends on data size the device should reply by.
Zabbix nicely splits on 2 parts and repeats requests in the same "snmp session" when it gets "error-status: tooBig".
That and plus that my device probably not that fast, causes that the whole host polling may take up to 10-20 seconds.
The host has 1000 items with 60 seconds update interval.
Internal monitoring: if increase update interval to queue measurement to 3 seconds, we can cleanly see those spikes. See graph.
Yes, I know that such items polling depends on interfaceID so scheduled time will be the same for all the 1000 items.
When I have 4 hosts and many pollers - it gets not any better.
I need to monitor much more such snmp hosts and much more items per host.
The request is to reconsider such behavior and maybe improve some part (scheduling or queue calculation).
I have bunch of snmp traffic captures with different number of pollers, 1 or 4 number of hosts, captured from server start and following 3-4 polling batches. Can be provided on request.
- part of
-
ZBXNEXT-4103 provide a way to work in BULK mode for buggy snmp devices (mismatched OIDs)
- Need info