Nagios 2.0 performance

[Andreas Ericsson]

Peter McAlpine wrote:
> *Parsing the log file each time status.cgi runs is just plain silly*
> 

It's the method available today. Not using fresh status is plain silly.

> Status should be stored within nagios, and the cgi's should query
> nagios (not the log file) for status. 
> OR
> Status should be stored in a database.

I've mentioned this about a hundred times. If support for logging to a 
socket in a straightforward and well documented way people wouldn't have 
to fiddle with the core to develop clever way of logging status. Once 
proper database-logging has been implemented, I'm sure some SQL-guru can 
hack up a couple of superfast queries and donate them to the local 
PHP-freak (php has the fastest hashes and best web-coding features 
around, period), and web frontends should start popping up all over the 
place.

Problems;
1/ Nagios core needs to be fiddled with at least once for this to work, 
and Ethan hasn't mentioned anything about making any such solution 
resident in the source, so it might be work spent for nothing.
2/ The listening end of the socket needs to be written by someone 
competent enough to make it easily extendable, and 'automagically' 
compatible with current Nagios code, or THAT part of the project will 
die away as soon as the original author stops maintaining it.

-- 
Andreas Ericsson                   andreas.ericsson at op5.se
OP5 AB                             www.op5.se
Lead Developer


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