[Nagios-devel] RE: [Nagios-users] Nagios 2.0 Event Broker and DB Support
Posted: Thu Jul 31, 2003 11:26 pm
Hi,
Ethan, I like it!!.
I see no problems with modules having access to internal nagios
structures. If you develop a good API, I'm sure
it will have no changes until you release new major versions of nagios.
Like linux kernel....
A suggestion: allow more than one module to handle the same event data.
Use some kind of priority to call those modules. In this way,
with an event data generated, nagios can call to mysql module, then
log_file module, then snmp_module .....=20
Regards,
Javier.
-----Mensaje original-----
De: Ethan Galstad [mailto:[email protected]]=20
Enviado el: viernes, 01 de agosto de 2003 7:02
Para: [email protected];
[email protected]
Asunto: [Nagios-users] Nagios 2.0 Event Broker and DB Support
Sorry for the crosspost, but the nagios-devel list is usually pretty=20
quiet when I request comments about new features I'm implementing. =20
This one is bigger than most, so I wanted to reach more people. This=20
is a bit long, so bear with me...
I am almost complete with coding for 2.0. Two big things remain: the=20
event broker and DB support (which is currently broken).
My original intent was to develop the event broker as a separate=20
application, tying it to Nagios with a unix domain socket. Nagios=20
would send the event broker information about the everything that was=20
going on (service checks, downtime, flapping, log entries, etc.). =20
The event broker would be able to load user-developed modules (object=20
files) at runtime and pass various types of Nagios data to them for=20
processing. This is all fine and good. I have a working prototype=20
of the event broker that does just this and seems to work okay. I=20
got to thinking that it was rather stupid to develop a separate=20
application for this when I could simply have Nagios load user-
developed modules itself. Doing this would give the modules the=20
benefit of having access to internal Nagios structures and functions=20
(which is good and bad - see below).
Here's an overview of how it would work:
- Nagios would load user-specified modules (object files) at startup=20
using the dlopen() function.
- Nagios would call the module's initialization function (the name of=20
which would be standardized).
- The module's init function would register for various types of=20
Nagios event data (service checks, host checks, log entries, event=20
handlers, etc.) using callback functions.
- When Nagios encounters an event for which a module has registered a=20
callback function, Nagios would call that module's function and pass=20
it data relevant to the event. The module is then free to do=20
whatever it wants to that event data. An example might be to log=20
service checks, performance data and log entries to MySQL, etc.
- Before shutting down, Nagios calls the module's de-init function. =20
This allows the module to clean up any resources it may be using.
Seems good in theory. Heck, might even work okay. However, there's=20
a big problem I have with it. If I implement things this way, the=20
user-developed modules would have access to internal Nagios data=20
structures and functions. This is not necessarily bad, as ill- behaved
modules would not be adopted by too many people.
=20
However, modules that might be compiled and working fine
for Nagios 2.0 might segfault under future versions if the internal=20
data structures change. Here's an example of what I mean:
User module registers for Nagios service check data using its=20
mymod_handle_servicecheck() function, which has a prototype of:
int mymod_handle_servicecheck(service *);
The service struct is an internal Nagios structure definition which=20
changes between Nagios versions. If the user module is compiled for=20
use with Nagios 2.0 and it's definition of the service struct, it=20
will have problems if it is not recompiled for future versions of=20
Nagios.
Off the top of my head, I could overcome this by requiring that the=20
user modules indicate (by calling a function) what version of Nagios=20
they are compiled for. If they
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]
Ethan, I like it!!.
I see no problems with modules having access to internal nagios
structures. If you develop a good API, I'm sure
it will have no changes until you release new major versions of nagios.
Like linux kernel....
A suggestion: allow more than one module to handle the same event data.
Use some kind of priority to call those modules. In this way,
with an event data generated, nagios can call to mysql module, then
log_file module, then snmp_module .....=20
Regards,
Javier.
-----Mensaje original-----
De: Ethan Galstad [mailto:[email protected]]=20
Enviado el: viernes, 01 de agosto de 2003 7:02
Para: [email protected];
[email protected]
Asunto: [Nagios-users] Nagios 2.0 Event Broker and DB Support
Sorry for the crosspost, but the nagios-devel list is usually pretty=20
quiet when I request comments about new features I'm implementing. =20
This one is bigger than most, so I wanted to reach more people. This=20
is a bit long, so bear with me...
I am almost complete with coding for 2.0. Two big things remain: the=20
event broker and DB support (which is currently broken).
My original intent was to develop the event broker as a separate=20
application, tying it to Nagios with a unix domain socket. Nagios=20
would send the event broker information about the everything that was=20
going on (service checks, downtime, flapping, log entries, etc.). =20
The event broker would be able to load user-developed modules (object=20
files) at runtime and pass various types of Nagios data to them for=20
processing. This is all fine and good. I have a working prototype=20
of the event broker that does just this and seems to work okay. I=20
got to thinking that it was rather stupid to develop a separate=20
application for this when I could simply have Nagios load user-
developed modules itself. Doing this would give the modules the=20
benefit of having access to internal Nagios structures and functions=20
(which is good and bad - see below).
Here's an overview of how it would work:
- Nagios would load user-specified modules (object files) at startup=20
using the dlopen() function.
- Nagios would call the module's initialization function (the name of=20
which would be standardized).
- The module's init function would register for various types of=20
Nagios event data (service checks, host checks, log entries, event=20
handlers, etc.) using callback functions.
- When Nagios encounters an event for which a module has registered a=20
callback function, Nagios would call that module's function and pass=20
it data relevant to the event. The module is then free to do=20
whatever it wants to that event data. An example might be to log=20
service checks, performance data and log entries to MySQL, etc.
- Before shutting down, Nagios calls the module's de-init function. =20
This allows the module to clean up any resources it may be using.
Seems good in theory. Heck, might even work okay. However, there's=20
a big problem I have with it. If I implement things this way, the=20
user-developed modules would have access to internal Nagios data=20
structures and functions. This is not necessarily bad, as ill- behaved
modules would not be adopted by too many people.
=20However, modules that might be compiled and working fine
for Nagios 2.0 might segfault under future versions if the internal=20
data structures change. Here's an example of what I mean:
User module registers for Nagios service check data using its=20
mymod_handle_servicecheck() function, which has a prototype of:
int mymod_handle_servicecheck(service *);
The service struct is an internal Nagios structure definition which=20
changes between Nagios versions. If the user module is compiled for=20
use with Nagios 2.0 and it's definition of the service struct, it=20
will have problems if it is not recompiled for future versions of=20
Nagios.
Off the top of my head, I could overcome this by requiring that the=20
user modules indicate (by calling a function) what version of Nagios=20
they are compiled for. If they
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]