[Nagios-devel] Future of Nagios (was Nagios is dead! Long live Icinga!)
Steven D. Morrey
smorrey at ldschurch.org
Wed May 6 21:49:03 UTC 2009
I've been looking at doing something like that also, but thought it would be of very limited applicability.
If anyone is interested in something like that let me know. I couldn't do it during my day job but if there was enough interest it could be something for the evenings/weekends.
From: D. Emmanuel Feinsmith [daniel at danielemmanuelfeinsmith.com]
Sent: Wednesday, May 06, 2009 3:15 PM
To: Nagios Developers List
Subject: Re: [Nagios-devel] Future of Nagios (was Nagios is dead! Long live Icinga!)
In terms of reloading/restarting nagios to pick up new configuration,
this is a common problem which can be solved with an event broker that
writes directly into Nagios memory space. The timing of this has to be
done carefully so as to avoid any problems, but it is eminently
doable. I know this can be successfully accomplished as I was hired as
a consultant for a large university client in Upstate New York, where
I gave them the ability to reconfigure their Nagios instance on the
fly without having to restart Nagios. It updates the CGI screens, the
Zero down time on a reconfigure.
On May 6, 2009, at 1:47 PM, Andreas Ericsson wrote:
> Mathieu Gagné wrote:
>> Hi Ethan,
>> First, thank you very much for Nagios.
>> Our enterprise relies heavily on it and Nagios has been a great
>> monitoring tools for us for so many years. Up to now, nothing has
>> surpassed its simplicity of use and we will continue to use it in the
>> foreseeable future.
>> On 5/6/09 11:56 AM, Ethan Galstad wrote:
>>> 4. Big things are coming around the bend for Nagios. Big things
>>> time. Be patient for a bit longer and you'll see the results.
>> As an enterprise looking to scale Nagios to tens of thousands
>> hosts and services, what could be our expectations of the future
>> regarding scalability?
> I should think some sort of event-transport module integrating tightly
> with the user interface will handle this. Fortunately, we're working
> exactly such a solution. The event-transport module is reasonably
> and the gui is well under way. Check out www.op5.org, and particularly
> merlin and ninja (merlin will be merged with reports-module and
> reports-gui will be merged into ninja in the near future).
>> We are using NDOutils to centralize host/service status.
>> One of our main challenge will be to optimize the configuration and
>> patch Nagios/NDOutils to make reloads as fast as possible since
>> and removable of monitored hosts have a high turnover rate. (I don't
>> know if it's the correct way to say it in English)
> Merlin doesn't have this problem, as it works differently with its
>> Reloading Nagios so it can pickup the new configuration is viewed
>> as a
>> "flaw" by our developers team because there's no monitoring done
>> that time.
> Well, restarting or just reloading the configuration doesn't really
> a difference to what kind of monitoring is happening during the
> Even if Nagios were to reload the configuration without requiring a
> restart, no network monitoring would happen during the reloading.
>> If we reload Nagios too often, it would simply pass the majority of
>> time exporting configuration/status to NDOutils and scheduling checks
>> without doing any real work at all. Too seldom and new monitoring
>> take too much time before being scheduled.
>> Any future plan regarding this aspect?
> Well, I've experimented a little bit. It seems to be several orders of
> magnitude faster to do the configuration parsing in two passes. One to
> find out how many objects there are of each type and sort them into a
> two-dimensional table of and then doing a binary search on that table,
> as opposed to creating fixed-sized hash tables and pre-insert objects
> into it. This is especially true for huge configurations, and appears
> to be caused by far more beneficial memory access patterns and the
> ability to only parse most objects a single time since we know that
> all hosts have been parsed by the time services are parsed, fe.
>> Also, have you ever heard of DNX? http://dnx.sourceforge.net/
>> Any future plan about a similar feature within Nagios?
> DNX is an event-broker module. The Nagios core has been modified to
> accommodate modules of that kind, but the actual functionality is of
> the kind that the eventbroker api was designed for, so it's not likely
> that such functionality will be brought into the nagios core.
> The NEW KODAK i700 Series Scanners deliver under ANY circumstances!
> production scanning environment may not be a perfect world - but
> thanks to
> Kodak, there's a perfect scanner to get the job done! With the NEW
> KODAK i700
> Series Scanner you'll get full speed at 300 dpi even with all image
> processing features enabled. http://p.sf.net/sfu/kodak-com
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your
production scanning environment may not be a perfect world - but thanks to
Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700
Series Scanner you'll get full speed at 300 dpi even with all image
processing features enabled. http://p.sf.net/sfu/kodak-com
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
More information about the Nagios-devel