SNMP Version as Macro

[Linwood]

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).

[kloczek]

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.

[Linwood]

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.

[kloczek]

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.

[kaspars.mednis]

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

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

Regards,
Kaspars

[Linwood]

Easier said than done. Tried twice, both the two votes, and one removal, gave the same response.

[kloczek]

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.