[ZBXNEXT-3940] Provide a way to flush SNMP cache for a host or all hosts Created: 2017 Jun 14  Updated: 2023 Dec 20  Resolved: 2020 Mar 11

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: API (A), Frontend (F), Proxy (P), Server (S)
Affects Version/s: 3.0.9
Fix Version/s: 5.0.0alpha3, 5.0 (plan)

Type: Change Request Priority: Trivial
Reporter: Raymond Kuiper Assignee: Marina Generalova (Inactive)
Resolution: Fixed Votes: 13
Labels: cache, runtimecontrol, snmp, snmpv3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Causes
causes ZBX-23740 Zabbix SNMP checks and SNMP config file Closed
Duplicate
is duplicated by ZBX-13770 zabbix server/proxy MUST be restarted... Closed
is duplicated by ZBX-16916 SNMPv3 Network discovery confuses AES... Closed
Team: Team D
Sprint: Sprint 61 (Feb 2020), Sprint 62 (Mar 2020)
Story Points: 1

 Description   

Zabbix caches some SNMP properties (engine time, engine boots, engine id) of a host when using SNMPv3 to enable RFC complaint communication with these hosts.

Unfortunately, we seem to be running into some snmpEngineTime issues on some devices every once in a while (we've double checked to see there are no duplicate SNMPengineID's in this environment).

The only current remedy we have if these issues occur, is to either reboot the device (which resets the engine time on the device and increments the engine boots counter), or we need to restart the Zabbix server proces (which clears the cache and is less of a problem normally).

It would be great if we could flush the snmp cache for these problem devices (via GUI and API) or if we could clear all of the SNMP cache with a -R flag to zabbix_server and zabbix_proxy without having to restart the entire server.

Relates to (amongst others):



 Comments   
Comment by Oleksii Zagorskyi [ 2017 Jun 14 ]

My correction is - not Zabbix cashes, but the netsnmp library, used by zabbix daemon, does it. So it's sort of a "side effect".
An ZBXNEXT-2352 needs to added to the list to be complete (although there are lots of cross links for all them).

I think it should be not that hard to implement libnetsnmp's function "free_etimelist" calling to all poller* processes by zabbix's -R flag.
It should not break the ZBXNEXT-2352 idea.

Comment by Raymond Kuiper [ 2017 Jun 14 ]

Thanks for the comment, zalex

Comment by richlv [ 2017 Jun 14 ]

some time ago there was a discussion on whether zabbix could detect/suspect these problems happening and try flushing the cache.
don't recall whether it was considered feasible in the end, though.

Comment by Raymond Kuiper [ 2017 Jun 14 ]

I would be happy to be able to manually remedy the issue. I might even be able to use a Zabbix action to remedy it if I can do it on a per host basis via the API

Comment by Oleksii Zagorskyi [ 2018 Apr 20 ]

ZBX-13770 discusses a bit related thing - "hidden" cache on libnetsnmp level.

Comment by Sandro G. [ 2018 Jun 21 ]

@Oleksiy Zagorskyi
I would like to ask you for more information on how to call the net-snmp function free_etimelist() from outside?
Have you written a small C program that sends the command to net-snmp or does a change need to be made within the Zabbix code? I'm not very familiar with accessing functions of net-snmp.

Background:
We have a problem with our Hirschmann switches because they do not comply with the USM specifications (RFC 3414) and do not increase the EngineBoots value after a restart as prescribed. The switches have a permanent value of "1" and cause problems with the SNMPv3 query after a restart, because the Zabbix server (or net-snmp) has stored the increased EngineTime in its SNMP cache. We have already opened a ticket at the manufacturer, but would like to reset the cache manually until a solution is known (if any problem is seen by the manufacturer).

I would like to use the net-snmp function (free_etimelist) to restore the correct SNMPv3 query when restarting the switches without restarting the entire Zabbix proxy each time.

I hope you or someone who has already used the function can help me.

 

Comment by Oleksii Zagorskyi [ 2018 Jun 22 ]

I did not and probably anyone else did not try to write such patch for zabbix_server.
Maybe this link could help you https://www.zabbix.com/development_services

Comment by Vitaly Zhuravlev [ 2019 Jan 11 ]

If I got it right, that should be fixed by automatically flushing the cache when such parameters are changed. No new buttons.

zalex_ua No, automatic is not the best way. And changed items config is not the only case when flushing snmp cache is needed. I'd prefer to go with an option to flush it manually on demand.
I imagined that it would a runtime option (-R) for zabbix_server or zabbix_proxy. At least I'd prefer to have this way in any case. It would be a consistent approach, like to manage housekeeper.
Button in frontend - would be nice to have it too, but it would be more complicated as need to pass the command to proxies as well.

vzhuravlev: why it's not the best way?

zalex_ua could you fill up criteria how to detect when the automatic flushing should be performed?

vzhuravlev: Changing items. What else? You said there is more.

zalex_ua Also because of a set of use cases described in ZBX-8385. This part will be not so easy to define - on which such cases flush the cache automatically.
The only comes to my mind is: if device returns EngineBoots=0 or 1 and report (responce) "usmStatsNotInTimeWindows", then flush the cache. It's still to be discussed.

And the question - is it possible to detect such conditions from the library response? From discussion with wiper in the ZBX-8385, if I understood correctly, there is no such a way.

So, I'd prefer to have an option to flush the cache manually anyway.

Comment by Alexei Vladishev [ 2020 Jan 24 ]

Manual flushing of SNMP cache is included into Zabbix 5.0 roadmap. If everything goes fine it will be implemented and available very soon, stay tuned.

Comment by Artjoms Rimdjonoks [ 2020 Feb 27 ]

Available in versions:

Comment by Marina Generalova (Inactive) [ 2020 Mar 02 ]

Documentation updated:

Comment by Oleksii Zagorskyi [ 2020 Mar 04 ]

THANK YOU ALL for this new feature in zabbix !!!

Comment by Raymond Kuiper [ 2020 Mar 05 ]

Very happy this has finally made it's way into Zabbix, thank you!

Generated at Fri Mar 29 08:54:49 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.