Greetings,
By the way whole discuss about modules I want to share some my own not well organized (yet) free though about zabbix extensions.
Whole last week I've been thinking about some very specific not agent extensions but whole class of them.
As I wrote I know quite well SNMP and whole problematic related to SNMP.
Sometimes it may be easier to perform some monitoring from within application on the host where zabbix agent is working but using straight communication between agent and application.
The same problem is not new and has been solved with SNMP.
net-snmp provides SMUX extension which is even codified in RFC 1227 (snmp multiplexing protocol).
Lets try to assume that we have apache to monitor.
What if apache module will be able to communicate with zabbix agent and register dynamically own agent side keys and exchange with zbx agent information what needs to be monitored in apache?
On initialize such communication it should be necessary to hook something inside agent to receive two type of data:
Monitored external extension will need to send back monitoring data.
Personally I don't care at the moment about passive monitoring as in my envs I'm completely moved away from passive monitoring as problematic from point of large scale env.
And now second part of above picture. Extension working outside zabbix agent should be able to send in batches monitoring data to put it in zabbix agent queue and can have own loop collecting monitoring data. Such data would be send by agent to srv/prx using existing agent code.
Above will require some kind of generic interface of ZMUX like extensions allowing to talk bidirectionally with local extensions by allow to initialize/register ZMUX communication channel from monitored app.
Summarize:
IMO elegance of above like SNMP SMUX approach is that it does not require to deploy any agent side configuration changes or DSO extension. Each application can come with own zabbix monitoring extension as part of own code (which may be loaded as DSO or other type extension). Writing complicated extensions using perl/python/whatever will require only to talk over ZMUX socket.
It is only a matter of implementation how such monitoring will be dynamically assembled: actively allowing application(s) to register any or only specified extensions or passively delegating to zabbix agent initialize local MUX communication.
Other aspect is that above reduces to absolute minimum any intrusion in zabbix running code. If something will be wrong with MUX client code it will close socket and agent still should be working.
With something like this should be even possible to reuse jmx[] key if java gateway address/port will be the same as agent address/port (ans zabbix web frontend will be not forcing to switch to zabbix java gw item type if jmx[] will be used in item definition). With ZMUX like java gw key jmx[] would be able just normal zabbix agent or zabbix agent active item type.
I'm almost sure that many people are thinking about some set of extension of the zabbix like java gw but for other proposes. Probably only obstacle with doing this is that such extensions requires to define new type of the item and this adds additional overhead on own extension code maintenance. With SMUX ext all of such extensions can use normal agent monitoring items types.
Few pieces in above picture are still not well defined but I think that for some people it is obsequious where it goes
Zabbix MUX ext does not need to be working exactly like SNMP SMUX. However communication protocol will need to be part of official zabbix interface.
Whole SNMP SMUX ext is quite closely linked to the to MIBs which in zabbix context are not needed.
PS. I have fully allocated next two, three weeks but after this if no one will start working on above I'm going to start working on apache POC monitoring using above sky fold.
I'm not sure yet but probably first it can be just some php code but at some stage it can be more generic apache DSO module.
Nevertheless I think that first it would be good only to discuss above.
Comments?
By the way whole discuss about modules I want to share some my own not well organized (yet) free though about zabbix extensions.
Whole last week I've been thinking about some very specific not agent extensions but whole class of them.
As I wrote I know quite well SNMP and whole problematic related to SNMP.
Sometimes it may be easier to perform some monitoring from within application on the host where zabbix agent is working but using straight communication between agent and application.
The same problem is not new and has been solved with SNMP.
net-snmp provides SMUX extension which is even codified in RFC 1227 (snmp multiplexing protocol).
Lets try to assume that we have apache to monitor.
What if apache module will be able to communicate with zabbix agent and register dynamically own agent side keys and exchange with zbx agent information what needs to be monitored in apache?
On initialize such communication it should be necessary to hook something inside agent to receive two type of data:
- updates of zabbix agent configuration (zabbix agent active type monitoring)
- query about exact key (zabbix agent passive monitoring) and send asap requested monitoring data
Monitored external extension will need to send back monitoring data.
Personally I don't care at the moment about passive monitoring as in my envs I'm completely moved away from passive monitoring as problematic from point of large scale env.
And now second part of above picture. Extension working outside zabbix agent should be able to send in batches monitoring data to put it in zabbix agent queue and can have own loop collecting monitoring data. Such data would be send by agent to srv/prx using existing agent code.
Above will require some kind of generic interface of ZMUX like extensions allowing to talk bidirectionally with local extensions by allow to initialize/register ZMUX communication channel from monitored app.
Summarize:
- at the moment zabbix agent DSO ABI allows register items statically defined in such extension
- with SMUX like extension (Zabbix MUX) it will be not necessary to write anything like DSO ext for agent. All could be done from monitored component side which should only be trying to establish connection with agent to register own new items. After this such channel would be used to receive active/passive monitoring conf and to send monitoring data to the agent
- ZMUX extension should track list of registered items to deregister them if connectivity with ext SMUX client will be closed
- registering ZMUX interface probably should allocate thread per ZUX channel to communicate with multiplexed ext
- ZMUX ext could be centrally managed from point of view of authentication allowing (in first version) talk with SMUX ext with exact name on exact host/template. In future it can be armored by for example add kerb auth allowing monitored application only with zabbix agent over encrypted channel on monitored host. This will require probably new item type like "zabbix agent smux" allowing to talk agent with only exact ext. In first version this part can be omitted as ZMUX should be able to handle normal zabbix agent/zabbix agent active items.
IMO elegance of above like SNMP SMUX approach is that it does not require to deploy any agent side configuration changes or DSO extension. Each application can come with own zabbix monitoring extension as part of own code (which may be loaded as DSO or other type extension). Writing complicated extensions using perl/python/whatever will require only to talk over ZMUX socket.
It is only a matter of implementation how such monitoring will be dynamically assembled: actively allowing application(s) to register any or only specified extensions or passively delegating to zabbix agent initialize local MUX communication.
Other aspect is that above reduces to absolute minimum any intrusion in zabbix running code. If something will be wrong with MUX client code it will close socket and agent still should be working.
With something like this should be even possible to reuse jmx[] key if java gateway address/port will be the same as agent address/port (ans zabbix web frontend will be not forcing to switch to zabbix java gw item type if jmx[] will be used in item definition). With ZMUX like java gw key jmx[] would be able just normal zabbix agent or zabbix agent active item type.
I'm almost sure that many people are thinking about some set of extension of the zabbix like java gw but for other proposes. Probably only obstacle with doing this is that such extensions requires to define new type of the item and this adds additional overhead on own extension code maintenance. With SMUX ext all of such extensions can use normal agent monitoring items types.
Few pieces in above picture are still not well defined but I think that for some people it is obsequious where it goes
Zabbix MUX ext does not need to be working exactly like SNMP SMUX. However communication protocol will need to be part of official zabbix interface.
Whole SNMP SMUX ext is quite closely linked to the to MIBs which in zabbix context are not needed.
PS. I have fully allocated next two, three weeks but after this if no one will start working on above I'm going to start working on apache POC monitoring using above sky fold.
I'm not sure yet but probably first it can be just some php code but at some stage it can be more generic apache DSO module.
Nevertheless I think that first it would be good only to discuss above.
Comments?
Comment