[Nagios-users] Nagios 2.0 Event Broker and DB Support
garrick
garrick at usc.edu
Fri Aug 1 19:52:37 CEST 2003
Once the modules have access to nagios internals, let's do more than
just receive events. I'd like to dynamically define services and remove
them a few hours later. I'd like to override the contacts.cfg files and
substitute user information with an RBAC from LDAP (along with the CGI's
authn pieces). I can probably think of a few more subsystems I could
override to better integrate into my environment.
About the dynamic services thing... I manage a research computing
cluster and each job tends to be a bit fragile. During the lifetime of
a job, there are several scriptable checks I can do to check the health
of the job and the nodes it is using. It would be fun if each job could
temporarily be its own service. While a job is running, nagios would
monitor it just like any other service. I know the current solution is
to use a single generic job service with passive checks submitted by
an external process that would identify any particular problems.
On Fri, Aug 01, 2003 at 12:02:03AM -0500, Ethan Galstad alleged:
> Sorry for the crosspost, but the nagios-devel list is usually pretty
> quiet when I request comments about new features I'm implementing.
> This one is bigger than most, so I wanted to reach more people. This
> is a bit long, so bear with me...
>
> I am almost complete with coding for 2.0. Two big things remain: the
> event broker and DB support (which is currently broken).
>
> My original intent was to develop the event broker as a separate
> application, tying it to Nagios with a unix domain socket. Nagios
> would send the event broker information about the everything that was
> going on (service checks, downtime, flapping, log entries, etc.).
> The event broker would be able to load user-developed modules (object
> files) at runtime and pass various types of Nagios data to them for
> processing. This is all fine and good. I have a working prototype
> of the event broker that does just this and seems to work okay. I
> got to thinking that it was rather stupid to develop a separate
> application for this when I could simply have Nagios load user-
> 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. :-)
> 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:
>
> User module registers for Nagios service check data using its
> mymod_handle_servicecheck() function, which has a prototype of:
>
> int mymod_handle_servicecheck(service *);
>
> The service struct is an internal Nagios structure definition which
> changes between Nagios versions. If the user module is compiled for
> use with Nagios 2.0 and it's definition of the service struct, it
> will have problems if it is not recompiled for future versions of
> Nagios.
>
> 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.
>
> I'm afraid I'm a bit over my head on how to handle this one. Some of
> you developers out there must have experience with this type of
> thing. If so, how did you handle it? What would you recommend?
> Comments, suggestions, flames? Is there a better way to accomplish
> this? Speak up now.
>
> What does this have to do with DB support, you ask? Well, if I
> implement the event broker as I have proposed I will be yanking
> native DB support out of Nagios completely. You can then write a
> module to log to a DB if you want. :-)
>
> 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).
>
>
> Ethan Galstad,
> Nagios Developer
> ---
> Email: nagios at nagios.org
> Website: http://www.nagios.org
>
>
>
> -------------------------------------------------------
> 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
> _______________________________________________
> Nagios-users mailing list
> Nagios-users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-users
> ::: Please include Nagios version, plugin version (-v) and OS when reporting any issue.
> ::: Messages without supporting info will risk being sent to /dev/null
>
-------------------------------------------------------
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
More information about the Developers
mailing list