>>> On 11/6/2007 at 2:32 PM, in message <[EMAIL PROTECTED]>, Matthias Blankenhaus <[EMAIL PROTECTED]> wrote:
> > 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 ? > > Actually there is. This type of module could be done as either a C DSO or a python module. Both of which are dynamically loaded by Gmond at start up and stay resident through the lifetime of Gmond. The examples for each of these types of modules are in the trunk code of SVN under monitor-core/gmond/modules and monitor-core/gmond/python_modules. Whether you do it using the C interface or python, is really up to you or anybody else who wants to implement it. Python would probably be easier but C has the advantage of being a little more low level. 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
