On Thursday 16 Mar 2006 01:31, Chuck Simmons wrote: > 5) It would be nice if the gmetric interface were a bit easier to use. > I wanted a subroutine library for my daemon and didn't want to spawn a > process each time I submitted stats.
This is certainly the way some of the grid-level monitoring infrastructures has gone (e.g. R-GMA, MonaLisa, etc...). They have a API you can link against and the application can then send data when it sees fit. This (more or less) already exists with libgmod (although I think thread-safety would have to be added). An alternative approach would be to have your daemon support some mechanism for exposing the stats, for example: SNMP, dumping XML (or csv, ...) on a TCP port (or over some UNIX socket), XML-RPC, SOAP (if you're feeling brave), ... You could run an external agent that periodically pulls data from your daemon and pushes it into Ganglia. This has the advantage that your daemon need know nothing about Ganglia, it merely provides data to interested parties. The monitoring agent might know about different monitoring systems. Not wishing to blow my own trumpet too much, but you could use MonAMI as this monitoring agent. It already supports the Ganglia/gmetric protocol so you'd only need a plugin for reading the output from your daemon. > The gmetric documentation is out of date. I don't understand the > purpose of the tmax and dmax arguments -- the documentation doesn't > explain the real purpose of these arguments. tmax and dmax are something of a mystery to me. I believe its something to do with the longevity of the data (so old data can be flushed). I set tmax to be the sample period (+1s, just in case) and dmax to zero. These seem to work OK, but might be wrong. Cheers, Paul.
pgpzP18mCttV0.pgp
Description: PGP signature
