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 definiti
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]