On Tue, 6 Nov 2007, Brad Nicholes wrote:
> >>> 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. > Cool. Are there examples for this available or documention ? I assume this Gmond module would have to be written in C and is loaded as a DSO into gmond ? Thanx, Matthias > 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
