Nagios 2.0 performance

Marc Powell marc at ena.com
Sat Sep 11 16:37:32 CEST 2004



> -----Original Message-----
> From: Peter McAlpine <peter at aoeu.ca>

> I've been reading this thread and appreciate all the tips everyone has
> to offer, but the time it takes the cgi's to load is obviously due to
> parsing the log file for each execution... unfortunately:
> *Parsing the log file each time status.cgi runs is just plain silly*

I would hardly use the word obviously. What evidence do you have to back
this assertion? What do you mean by 'parsing'? The status file on my
system is just over 900k and clearly delimited, hardly a challenging
file to 'parse'. If you think that nagios is parsing nagios.log each
time you should do some more research. I'm not a coder but I do have
years of experience with Nagios and tend to lean toward the list
traversals (which is really the parsing) as a big performance hit as has
been discussed here recently and in the past. There have been very
significant performance improvements in that regard in 2.0.

> 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.

> 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.

> 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.

--
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





More information about the Users mailing list