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