ZABBIX Forums  
  #1  
Old 23-11-2017, 18:06
Linwood Linwood is offline
Senior Member
 
Join Date: Dec 2013
Location: Cape Coral, FL, USA
Posts: 257
Default SNMP Version as Macro

Please consider having SNMP version as a Macro, with all the relevant fields for all versions shown all the time. Then you can use the same template for SNMPv2 and SNMPv3 (and SNMPv1 but less relevant).

I realize it is not all that hard to change templates, but it is tedious to keep multiple templates in sync over time with changes, especially when those like to other templates, and those in turn call external scripts (though those can be parameterized I guess).
Reply With Quote
  #2  
Old 25-11-2017, 10:29
kloczek kloczek is offline
Senior Member
 
Join Date: Jun 2006
Location: UK/London
Posts: 872
Default

This could be not so easy to implement because SNMP version is used in type of the items.
Unless SNMP version will be as kind of item attribute and it will be no new kind of generic SNMP type item probably it will be hard to implement such functionality.

However fact is that currently it is a bit artificial as well to have SNMP version as an attribute per each item.
Solution which I see is move all details of the SNMP version to the host interface.
As the version of the SNMP protocol would be part of the interface definition will be possible to have SNM version independent items and templates.

The same issue is with zabbix active/passive items. As currently is item is passive or active it is not possible to have single template which could be used with passive and active agent.
As long as zabbix agent/zabbix agent (active) could be part of the host interface it will be possible to have passive/active monitoring templates.

Looks like as same as SNMP traps the same zabbix trapper items should not be part of the same generalization.
Reply With Quote
  #3  
Old 25-11-2017, 13:51
Linwood Linwood is offline
Senior Member
 
Join Date: Dec 2013
Location: Cape Coral, FL, USA
Posts: 257
Default

Fair enough. I have not tried to work through all the issues, but what's there now is very awkward. With many sites being forced into V3 just because it is encrypted (whether or not it actually offers any real security in their situation), I think this need will become more common over time.
Reply With Quote
  #4  
Old 25-11-2017, 18:30
kloczek kloczek is offline
Senior Member
 
Join Date: Jun 2006
Location: UK/London
Posts: 872
Default

Yet another observation.

It is yet another type of the item type which part of the description could be IMO moved to the interface. Looks like the same can be done in case of "Database monitor" type (AKA ODBC items).
I see some advantages of such approach.
If it will be possible to move those parts to interface it will be possible to add:

- permission to see/modify interface description which is quite important in case of keeping those bits out of eyes of some underprivileged users

- item API/ABI could have possibility to reach some additional interface metadata by name of some interface fields it could be possible to generalize items types. For example ssh or telnet item could be zabbix active or passive item collected from the agent or simple check fired from the server or the proxy
With this it will be possible easier to write agent loadable module to monitor for example mysql as item key could be able to reach host custom interface fields to read {MYSQL_PASSWD} {MYSQL_USER} data necessary on establishing connectivity to mysql engine.

I think that current JMX item could be just as simple check item but with this it could be easy to transform it to zabbix active/passive agent type because no longer JMX user/passwd will be part of the item description.

Nevertheless especially SNMP items seems like most promising to move auth/SNMP protocol version to the host interface to reduce number of zabbix item types.
If this generalization will open the gates to many other extensions available as loadable modules. All what is needed here is possibility to store in iterface definition key:value pairs and API possibility to access from the item code to read query those attributes.
With this things like telnet, ssh, ODBC, IPMI, JMX items types could be easily provided as loadable modules and add any new type of the items no longer will require to modify zabbix core code.
Reply With Quote
  #5  
Old 27-11-2017, 17:06
kaspars.mednis kaspars.mednis is offline
Senior Member
 
Join Date: Oct 2017
Posts: 244
Default

There is already a similar ZBXNEXT, you can vote for it here

https://support.zabbix.com/browse/ZBXNEXT-2613

Regards,
Kaspars
Reply With Quote
  #6  
Old 27-11-2017, 17:26
Linwood Linwood is offline
Senior Member
 
Join Date: Dec 2013
Location: Cape Coral, FL, USA
Posts: 257
Default

Easier said than done. Tried twice, both the two votes, and one removal, gave the same response.
Attached Images
 
Reply With Quote
  #7  
Old 27-11-2017, 21:36
kloczek kloczek is offline
Senior Member
 
Join Date: Jun 2006
Location: UK/London
Posts: 872
Default

Quote:
Originally Posted by kaspars.mednis View Post
There is already a similar ZBXNEXT, you can vote for it here

https://support.zabbix.com/browse/ZBXNEXT-2613

Regards,
Kaspars
Good to know that I came to exactly the same conclusions independently.
Just voted for this ticket.

Nevertheless I think that moving some part to the interface with come modules API extensions allowing to read interface data definitions and adding possibility to create custom interface may solve many future problems or simplify many existing zabbix code.

Problem with zabbix modules API/ABI is that zabbix does not provides some parts of internal API as official API. One example is in processing some data where is possible to make some internal parts as public is on processing json data. More and more monitored over zabbix objects/metrics provides raw description in json format. It would a bit waste to force external modules code writers to force system wide json library as zabbix internally is using json processing functions.

Separate some parts into for example libzabbixapi.so.<major_version> would allow easy to maintain current modules compatibility issues and with SONAME and with internal versioning solve incremental extensions and all would be possible to do this without embedding this into zabbix code.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:57.