RFC/RFP Nagios command workers

[Adam Augustine]

On Wed, Jun 29, 2011 at 2:50 AM, Andreas Ericsson <ae at op5.se> wrote:

> On 06/28/2011 05:13 PM, Matthieu Kermagoret wrote:
> > Hi list,
> >
> > First of all, sorry for the delayed response, last month was pretty
> > crazy at work :-p
> >
> > On Mon, May 23, 2011 at 12:38 PM, Andreas Ericsson<ae at op5.se>  wrote:
> >> On 05/23/2011 11:37 AM, Matthieu Kermagoret wrote:
> >> Because shipping an official module that does it would mean not only
>

[snip]


> > For years it's been Nagios'
> > development team's policy not to include features that could be
> > written as modules. I liked it that way.
> >
>
> Everything can be written as modules. The worker process thing will have
> the nice sideeffect that modules can register sockets that core Nagios
> will listen to events from, with a special callback when there's data
> available on the socket. This reduces complexity of a lot of modules by
> a fair bit. With worker-processes instead of multiple threads it's also
> trivial to write modules with regards to thread-safety, and potential
> leaks in worker modules (such as embedded perl) can be ignored, since
> we can just kill the worker process and spawn a new one once it's done
> some arbitrary number of checks. This is how Apache handles leaky
> modules and we could do far worse than using the world's most popular
> webserver as an example.
>
> There's also another thing. Mozilla Firefox has been accused of feature
> stagnation in the core since they let addon writers handle adding new
> features, and far from everybody uses modules. Google Chrome has taken
> a fair share of users from Firefox lately, partly because it implements
> some of the more popular modules directly in-core. Nagios has also been
> accused of feature stagnation, even though broker module development
> has flourished in recent years (nagios with modules is nothing like the
> old nagios without them), so it makes sense to add certain selected
> module capabilities to the core.
>
>
There seem to be two issues, I think, that are getting mixed here. I think
the accusation of Mozilla Firefox/Nagios Core feature stagnation is a
separate issue from
putting things in core as opposed to making them a NEB module.

The Linux kernel is a good example of tons of features existing in modules
and
not being included in the core, yet not having the feature stagnation
problem.
The difference between those and FF/Nagios is that the modules are included
in
the /distribution/ of the code and many are active by default.

This has the major advantage that if someone doesn't like/need a particular
module,
it can be trivially removed. This helps performance tuning. etc. At the same
time,
it allows feature progression, by default.

I think if this approach were taken, more modularization rather than hard
coding things into the core, but including more widely accepted modules
in the default Nagios Core distribution, that would keep everyone happy.

That being said, I think placing the networking socket code into the core is
completely reasonable, since it is such an essential part of the
architecture.
Although theoretically you could remove all networking from the Linux kernel
and still run...

Really, on that part at least, I think either way would work out fine.

Just a thought,
  Adam Augustine



>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20110630/0c93128e/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel