>>> On 11/6/2007 at 1:50 PM, in message <[EMAIL PROTECTED]>, "Brad Nicholes" <[EMAIL PROTECTED]> wrote: >>>> On 11/6/2007 at 1:45 PM, in message > <[EMAIL PROTECTED]>, Matthias > Blankenhaus <[EMAIL PROTECTED]> wrote: > >> >> On Tue, 6 Nov 2007, john allspaw wrote: >> >>> Hey all - >>> >>> While I love the idea of the python module, I'd like the plain-old gmetric >> binary to stay as-is. I'm not sure if there are/were plans on getting rid of >> it in favor of the new custom framework stuff. Some of the reasons why I >> think it should stay: >>> >>> - Gmetric makes building custom metrics insanely easy. I tell people all >>> the >> time: "if you can make a number with any script you have, you can get it > into >> ganglia, with whatever language you want." >>> >>> - We have a lot of custom metrics that depend on other software, (we take >> results from nagios checks and spit them into ganglia with the gmetric >> command, for example) and that can't be rewritten without a lot of work. >>> >>> A huge part about why some folks where I work (Yahoo!) are interested in >> ganglia is that even with as basic install, you get a LOT >>> of visibility into your systems and network, with very little effort. Being >> able to embed a one-line gmetric command into any other monitoring they >> already have is the icing on the cake. >>> >>> Thoughts ? >> >> I also vote for keeping gmetric in the game. I have asked this question >> before and I now sense a chance to reissue it :-). Here is goes: >> >> Is there general interest in extending gmetric so that it can take a list >> of metrics, instead of just one ? >> >> We have a situation where we need to feed in lots of metrics and thus >> suffer from the resulting system calls. >> >> Another thought I had to further reduce system latency was to daemonize >> gmetric and let it read from a local socket or pipe or whatever peopel >> think is most convinient. >> >> Cheers, >> Matthias >> >> > > The good news is that the gmond module interface (python or C) takes care of > those issues. This isn't a reason to get rid of gmetric, just a reason to > consider moving your metrics to the module interface rather than enhancing > gmetric. >
Another thought along these lines is that it might be easier to build a Gmond module that will execute a given list of scripts and return the results as individual metrics rather than enhance gmetric. By implementing a gmond script execution module you get daemonization for free as well as metric scheduling. Gmond already provides us with the infrastructure we need to collect metrics and modules allow us to extend it in any way that is necessary. Brad ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
