[ZBXNEXT-3119] Check SNMP object names (like a C snmp_parse_oid() )when defining SNMP items and discovery rules Created: 2016 Jan 28 Updated: 2016 Jan 29 |
|
Status: | Open |
Project: | ZABBIX FEATURE REQUESTS |
Component/s: | Frontend (F) |
Affects Version/s: | None |
Fix Version/s: | None |
Type: | Change Request | Priority: | Trivial |
Reporter: | Vitaly Zhuravlev | Assignee: | Unassigned |
Resolution: | Unresolved | Votes: | 0 |
Labels: | discoveryrule, lld, oid, snmp | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Description |
Wouldn't that be an improvement If Zabbix frontend can warn user that a value taken from SNMP MIB and put in SNMP OID field (in items or discovery rules) cannot be resolved because no MIB available or counter name was misspelled? Right now item creation/update is accepted and the problem can be seen only when trying to find out why there is still no data coming in latest data or why still no interfaces could be discovered. It really could take a lot of time to debug as you have to visit too many places on the frontend. P.S> |
Comments |
Comment by Aleksandrs Saveljevs [ 2016 Jan 28 ] |
There are many related feature requests on the subject:
Please choose one you wish this request to be closed as a duplicate of. |
Comment by Vitaly Zhuravlev [ 2016 Jan 28 ] |
asaveljevs, I disagree, those tickets suggest building a complete tool for working with SNMP (which is indeed must be) as I suggest minor feature(check) that can help a lot while we are on the way to build a proper SNMP/MIB tool/wizard. Currently this check is done by Zabbix Server only (snmp_parse_oid()) - too far from the point where user is making a mistake (could make it). If it is too time consuming to implement - well lets close it and wait for MIB tools one day |
Comment by Oleksii Zagorskyi [ 2016 Jan 29 ] |
A specific thing, but still want to share here - I several times noticed that if you have configured a huge MIBs set, then your snmp* commands executed slower than without the MIBs. That's expected as every time the command should be started from scratch. I want to say that MIBs for a network management system is a perfect thing, but for a loaded monitoring system - this is a question. This way I sometimes considered that if a user wants to use MIBs for snmp* commands he could create his own $HOME/.snmp/snmp.conf and enable mibs loading there, without changing global configuration file /etc/snmp/snmp.conf, which will affect zabbix server too. It was also very interesting for me how a lot of MIBs do affect system performance for snmp traps receiving ! It means that MIBs for zabbix server could be undesired, thus MIBs support for frontend is also not very required |
Comment by Aleksandrs Saveljevs [ 2016 Jan 29 ] |
Alternatively, frontend can use MIBs to convert from a human friendly representation like "IF-MIB::ifDescr.1" to ".1.3.6.1.2.1.2.2.1.2.1", showing the first for user's convenience and storing the second one for server's consumption. Such OID preparsing may (or may not) reduce load on the server a bit, as per the comment above. Alternatively, Zabbix server can do such preparsing or caching itself. |