On Thursday 30 November 2006 17:33, [EMAIL PROTECTED] wrote: > I am not sure which way I should proceed, and the code setup for > metrics is kind of discouraging against putting in new ones with XDR > encoding because of the places I need to change stuff - linux/metric.c > and > gmond.c and ./lib/protocol_xdr.c and protocol.h at the least.
Yup, I would avoid hacking protocol.x (from which protocol_xdr.c is derived)
unless you want to maintain it: the current setup isn't too friendly towards
changing core metrics.
> Also the data structures are not condusive to a to having a variable
> number of processor's and thence the metrics themselves.
I haven't looked at the code, but wouldn't this just be a case of adding a few
more variables?
> Plan B would be to snip out the gmetric code and create gmetric style
> udp
> packets for the extra metrics, but it was not clear to me that that
> would
> be OK given that the callback stuff and the xdr codes are a bit
> intertwined.
I would go for this option: by using gmetric, you protect yourself against
having to maintain your changes when updating ganglia.
Not a complete solution, but something like:
while :; do gmetric --name="CPU0 usage" --value="$(awk '/^cpu0/{print \
$2}'</proc/stat)" --slope=positive --tmax=1; sleep 1; done
should work; although Ganglia doesn't take 1st-derivatives for +ve gradient
(counter) data, so you'll have to calculate this yourself before sending the
updated metric.
The problem with the above script is you're constantly fork()ing a new
processes (awk and gmetric above). To gather information on both CPUs, you
probably need to folk() four times per gathering (twice, if you use a bit of
python or perl).
HTH,
Paul.
pgpo1NKyN0or0.pgp
Description: PGP signature
