Nagios 2.0 Event Broker and DB Support

[John P. Rouillard]

In message <3F29ADFB.3157.1AE3E5D at localhost>,
"Ethan Galstad" writes:
[...]
>developed modules itself.  Doing this would give the modules the 
>benefit of having access to internal Nagios structures and functions 
>(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 
>using the dlopen() function.
>
>- Nagios would call the module's initialization function (the name of 
>which would be standardized).
>
>- The module's init function would register for various types of 
>Nagios event data (service checks, host checks, log entries, event 
>handlers, etc.) using callback functions.
>
>- When Nagios encounters an event for which a module has registered a 
>callback function, Nagios would call that module's function and pass 
>it data relevant to the event.  The module is then free to do 
>whatever it wants to that event data.  An example might be to log 
>service checks, performance data and log entries to MySQL, etc.
>
>- Before shutting down, Nagios calls the module's de-init function.  
>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 
>a big problem I have with it.  If I implement things this way, the 
>user-developed modules would have access to internal Nagios data 
>structures and functions.  This is not necessarily bad, as ill-
>behaved modules would not be adopted by too many people. :-)  

True, but look at the issues with mod_perl and the stability of
apache. I would prefer and external application simply so that my core
system will remain up. Now having said that, I prefer it to be built
in because it means I don't have to worry about monitoring/restarting
the broker if it fails.

>However, modules that might be compiled and working fine
>for Nagios 2.0 might segfault under future versions if the internal 
>data structures change.  Here's an example of what I mean:
[...]
>Off the top of my head, I could overcome this by requiring that the 
>user modules indicate (by calling a function) what version of Nagios 
>they are compiled for.  If they report anything but the current 
>version (or do not report at all), unload them so they can do no 
>harm.

You can encapsulate the internal data structures in a class and
provide access functions for the class. This hides the internal
structure, but still makes it available to the modules. 

Define a version for the API (rather than for nagios), and have the
module register for a particular version of the API. Number your API
versions so that a module written for 1.2 of the API will work with
API 1.7, but not work with 1.0, then De-register the 1.2 written module
if it runs under a nagios with a 1.0 API, or De-register if the 1.2
tries to run in a version of nagios that uses version 2.x of the API.

[...]
>PS: I had originally planned on exposing almost all of Nagios' data 
>and events to the broker, but I may have to scale that down if I plan 
>on getting 2.0 out this century.  Perhaps just support for:
>
>	- Service and host checks
>	- Event handlers
>	- Log data
>
>This would allow the development of modules to log check information, 
>performance data, and log file data to a DB (or whatever).

It would also be nice to allow the modules to put themselves into the
core/plugin interface as well. This is another reason to allow the
objects to be dynamically loaded as they can be loaded into different
parts of the data stream.

I am thinking specifically of a module that can divert/forward the
plugin output to SEC as has been discussed on the list. However this
module would need to be able to tell the core to not change the
current state of the service etc.

By defining an API you could choose to publish/not publish this
functionality, and the functionality wouldn't change in the face of
internal changes to data structures etc, just the implementation if
this API function would change. This does mean a richer API would need
to be made available, and that means more work for you, but less work
for the module authors, and less chance of breakage for nagios.

				-- rouilj
John Rouillard
===========================================================================
My employers don't acknowledge my existence much less my opinions.


-------------------------------------------------------
This SF.Net email sponsored by: Free pre-built ASP.NET sites including
Data Reports, E-commerce, Portals, and Forums are available now.
Download today and enter to win an XBOX or Visual Studio .NET.
http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01