Nagios 2.0 performance

[Marc Powell]

> -----Original Message-----
> From: nagios-users-admin at lists.sourceforge.net [mailto:nagios-users-
> admin at lists.sourceforge.net] On Behalf Of Peter McAlpine
> 
> > > Status should be stored within nagios, and the cgi's should query
> > > nagios (not the log file) for status.
> >
> > And how would you recommend this inter-process communication happen?
I'm
> > sure any reasonable suggestion would be duly considered. You might
also
> > want to present evidence to back your conclusion that this really is
the
> > issue and why your solution would be better.
> 
> Since you asked...
> I was thinking along the same lines as the shared memory suggestion
> made in another post. I figure the bulk of the cgi code could be moved
> into the nagios process, and simply have the cgi's query some
> port or socket for this status.

I personally would rather have the daemon entirely focused on doing
things like monitoring and alerting than having to also spend cycles on
handling CGI requests. There are already scalability issues related to
those two tasks, why burden the core with additional tasks? Think in
crisis mode, you've got a lot of stuff down (potentially hundreds of
devices) and a lot of people are looking at the interface to monitor
what still needs to be worked on. The daemon is now burdened with
handling those requests to display the status when it should be focused
entirely on determining what the status is.

> > > OR
> > > Status should be stored in a database.
> >
> > Nagios <= 1.2 can store status data in a database and the CGI's can
read
> > it from there (I believe even Netsaint could). As a user with a
fairly
> > large installation (2674 services on 1645 hosts), I can tell you
that
> > there is little difference between nagios loading status data from a
> > flat file versus a database (pgsql in my case). In fact, flat file
seems
> > to be just a smidge quicker in my installation (I use both methods).
I'm
> > presuming that you haven't even tested your theory given that you
didn't
> > know Nagios could do this already.
> 
> Yes, I knew that Nagios <= 1.2 can store the status in a database.
> However 1 minute you say, "Nagios <= 1.2 supports databases" and the
next
> you say, "Nagios 2.0+ cgi's are much faster"... I've used both, and
> find the cgi generation times to be unsatisfactory regardless of which
> one I use.

I'm sorry, even if I did say both those as quoted (which I didn't
exactly) and in the same context, I don't see the connection or the
contradiction in those two statements. Perhaps you can elaborate? While
I never stated it explicitly, since you bring it up, status.cgi in 2.0
specifically _is_ much faster over 1.x with any backend. A status
summary that takes about 5 minutes under 1.x takes about 10 seconds
under 2.0. I'd call that significantly improved. The discussions that
have been occurring on this list that you referenced originally were in
regards to optimizing that even further, for which I am totally in
favor, as long as core functionality isn't impaired. As has also been
discussed, config parsing is one of the biggest time hogs now and there
may be things that can be done along those lines to help as well.

> > > If supporting multiple databases is a problem:
> > > -Say "too bad, only foosql is supported" (mysql runs on MsWindows
btw)
> > > -Use something like ODBC to make the database more portable.
> >
> > The path has already been chosen. Nagios and the CGI's will use flat
> > files for data storage. That appears to work best for Ethan and the
> > program after all is written by him, for him and we just benefit
from
> > it. Users are free to use the event broker daemon in 2.0 to store
copies
> > of the data in whatever storage mechanism they prefer but the Nagios
> > will always use flat files.
> 
> This is not an argument, and it concerns me when I hear this sort of
> comment: "We have decided now deal with it".

To be clear, I am not a developer on the project, merely a user, but I
have been here for a very long time, including the year or two of off
and on discussion on database support. After all that Ethan still chose
to drop database support for status data in favor of the event broker
daemon, for his own reasons and he was very determined to do it _and_ he
gave us at least a year warning. Don't treat it as if it were an
arbitrary decision made one morning over coffee. I'm not dismissing your
ideas it's just that it has been hashed and re-hashed on this list and
you weren't bringing anything new to the table that hadn't already been
discussed. You yourself recommended the same attitude: 'too bad, only
flat files are supported'. As you clearly seem to recognize, you can't
make everyone happy and unfortunately, at this point in time, you are
the one that can't be made happy. Until (and IF) Ethan weighs in on this
discussion we've got flat files and the event broker to work with which
isn't such a bad deal at all. 

--
Marc



-------------------------------------------------------
This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170
Project Admins to receive an Apple iPod Mini FREE for your judgement on
who ports your project to Linux PPC the best. Sponsored by IBM. 
Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php
_______________________________________________
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