> Umm... just off the top of my head... aren't there callbacks being made
> for every check as soon as the check is done? I know there's something
> about it in checks.c
Yes, there are many callbacks, but from what I could see, they were not
called in the worker threads. Like I said, though, I haven't looked at it
much.... with my limited understand, it seems the worker threads are
responsible soley for running the check and putting the results onto the
queue of stuff to deal with.
> Make it a dual piece. The eventbroker logs to a socket and another
> program listens in and (optionally) parses it a bit before shoving it
> into DB. It's much more generic that way, and it'll be easy to plug in a
> variety of DB-supporting modules in the listening end.
A loadable module is pretty easy to duplicate and change, which is why I
was hoping for a non-trivial example.
complexity and I frankly don't see the gain. Doesn't mean I'm not missing
something, though...
> > (On a side note, why doesn't nagios use glib? Yes, I know that's another
> > dependancy, but in my experience the benefits are more than worth it.)
> >
>
> glib is a fairly large library to install, and I don't think it's
> available for all too many platforms (since it fiddles a lot with the
> lower level stuff, like threads and memory management). Nagios is fairly
> portable, and I think Ethan is reluctant to make it depend on libs that
> makes it less so.
Large and less previlent, certainly. But I've never met an environment I
couldn't compile it for.
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]