PHP user interface for Nagios

Jesús M. NAVARRO jesus_navarro at undominio.net
Tue Jun 3 16:30:38 CEST 2003


Hi, John:

El Martes, 3 de Junio de 2003 15:35, John Arley Burns escribió:
> --- Jesús M. NAVARRO <jesus_navarro at undominio.net> wrote:
> > Hi, John:

[...]

> >
> > The "view config" option is merely a wrapper around the config.cgi
> > CGI, since
> > that was my very first idea: if I can just drop in a few PHP classes
> > so I
> > have the same functionality current Nagios ui has, then I can go at
> > my own
> > pace adding functionality or rewriting CGIs as I feel I can, and
> > still using
> > the byproduct on a day by day basis.
>
> There is a PHP program that allows editing of config files named
> "NAGAT", available on the "Extras" download page off the main Nagios
> site.  Perhaps you could merge this into your own.
>

I'll take a look at it.

> I'm currently working on getting debian packaging working for Nagios,
> the current debian package has some problems.  I'll release it to
> debian when it's ready.
>

I'm a Debian user, and I know Debian packages todate are outdated and with 
more than one rough corner, so that news are welcome.
I'd consider having more than one package: core engine, plugins, gui and 
extras should be different packages, if you want my opinion.

> The main piece I'll eventually contribute is probably in the monitoring
> area.  NSCA is a good start for a basic system but I need something
> that's far more secure and works over HTTPS.  I'm currently not sure if
> extending NSCA is better or developing an entirely new add-on agent.
> That's probably going to be my major contribution to Nagios.
>

Well, I see two things I think Nagios can do better than now (I'm trying to 
make a positive criticism here, so plase take it that way):
1/ The NCSA issue: it can go through ssh or https (I see this can be easier to 
manage through a firewall).  The conectivity issue is part one, and the 
connection load is the other one: rigth now if I want ten remote probes at a 
box I have to start ten encripted connections (and this is a clear overload).  
Probably your two issues would be properly managed with a serialization 
protocol (say XML) so the server can ask through any given port for all 
remote probes at a box, and recieve them all on a single piece.  Something 
like...

<probes>
	<total number=10>
		<probe>
			<order number=1>
			<kind=disk ocupation>
			<values>
				<disk=hda>
					<ocupation=70%>
					<size=20GB>
				</disk>
			</values>
		<probe>
		<probe>
			<order number=2>
			<kind=number of proccesses>
			(...)
		</probe>
		(...)
	</total>
</probes>

This way one conection (and one connection negotiation) makes all, and you 
immediately know if all data was transfer or not.

2/ Alarm handling is top offer for that kind of tool, but trends 
presentation/analisis is second one: I'd want to see a tool like a merge 
between Nagios and Cacti (going to the "paradigms", I'd say BigBrother+MRTG).

3/ (Ok, I lied) I'd want to see Nagios more concentrated about the collecting 
engine (daemon, scheduling queue, active/passive checks) and a clean 
interface both to plugins and UI, so I could use it as a fundation for my 
"Control Center" -alarms, trends, file integrity, remote intrusion probes... 
nagios+cacti+snort+samhain+...

Well... my two cents.
-- 
SALUD,
Jesús
***
jesus_navarro at undominio.net
***



-------------------------------------------------------
This SF.net email is sponsored by: eBay
Get office equipment for less on eBay!
http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5




More information about the Developers mailing list