If an external processes is going to do the work.... why can't that
external processes just work on the rrd files that are already there? I
may be misssing something drastically obvious... but I have been kicking
around that thought for awhile and just have not gotten to it.
So instead of working it as part of ganglia.. why not gmetad?
My $0.02 worth.
Pete.
Leif Nixon wrote:
[EMAIL PROTECTED] writes:
I was assuming that the normal host ping (done
for the host check) would still be done by nagios. I guess your
goal is to get rid of this.
Most of our clusters are built around a private network. The nodes
aren't reachable from outside the cluster, so the Nagios host can't
ping them. That's a rather common architecture.
But what you said about caching made me think; an external process
could pull down the Ganglia XML data, parse it and keep the data in
memory in cooked form as a snapshot of the state of the "grid". Nagios
plugins then could query that snapshot by some suitably lightweight
RPC mechanism. Or you could store the cooked data on disk in some
suitably clever file structure and let the plugins read that.
That way you can let Nagios do active service checks, and also use the
Ganglia data for host checks (using the REPORTED attribute), without
the overhead of re-parsing the entire XML data set for each check.
Hmm. That could fly.
Also, even if I haven't paid close attention, I understand Matt is
adding clever query mechanisms to Ganglia 3. If that turns out
light-weight enough, you could dispense with the whole caching
mechanism above, and let the Nagios plugins query gmond instead.
I like Nagios, mostly, and use it for everything else, so a connector
between Nagios and Ganglia would be very nice. Let me think about
this.
--
Peter Schmid
Logic Technology Inc.
GE Global Research Center
ITMS Engineering Systems Group
(518) 387-6903
