We have had time to take a closer look at libmetrics and while it is a useful reference, there are significant architectural differences between sFlow's approach to counter polling and Ganglia's. The libmetrics library export rates rather than counters. An sFlow agent exports raw counters and leaves it to the sFlow analyzer to calculate rates. While we would aim to be able to generate the same metrics on the analyzer, an sFlow agent won't be able use many of the libmetrics calls.
Given the differences, you should choose an approach to maintaining libmetrics that best suits the Ganglia project. We may create a similar library for our project, exposing the underlying counters. Peter On Mar 7, 2010, at 10:57 AM, Daniel Pocock wrote: > Peter Phaal wrote: >> Hi all, >> >> We are considering using libmetrics as a stand-alone library. In its current >> form, with the separate configure script, it looks like it would ideally >> suite our purposes. I noticed a recent discussion about dropping the >> separate configure script[1] and wanted to express our interest in keeping >> it. The discussion also mentioned licensing. It looks like all the elements >> of the library are > As I see it, the current libmetrics/configure is broken, and the way it > is invoked is also broken: > > - when it is invoked from the top-level configure, none of the command > line options are passed to it, this is particularly bad for > cross-compiling, multilib, etc > > - many of the configure tests are run twice on each build, which is > inefficient and painful for developers, configure takes a long time on > Cygwin in particular > > - code has to be duplicated across both configure scripts > > As I see it, there are three ways forward: > > a) separate libmetrics into an independent project, independent package, > etc with a well defined API - this would be ideal if there is genuine > demand from projects like yours, as you wouldn't have to download all of > Ganglia just to play with libmetrics > > b) scrap the separate configure script, merge it into the top-level > configure. If someone does only want to build libmetrics, they can > still do so by running a command like this: > > ./configure --enable-static && make -C libmetrics > > c) hack the scripts even more to deal with the problems I have described > (e.g. passing command line options to the nested configure) > > I have endorsed solution (b) simply because it is easier and I was > unaware of demand for option (a). If there is demand for option (a), > then I have no objection to that solution. The only solution I object > to is (c), the status quo. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
