Ahh.. fair enough. I'll see what I can do. :-) Thanks! On Thu, Jul 2, 2009 at 10:20 AM, Brad Nicholes<bnicho...@novell.com> wrote: > Creating a standard template for building a module independent of the core is > something that we really haven't gotten around to doing. So I think in this > instance, you would be the template creator :). You should be able to start > with the Ganglia autoconf stuff and derive something from there. Sorry, I > wish we had a standard template because I know that would make life easier. > > Brad > > >>>> On 7/1/2009 at 7:46 PM, in message > <8121824c0907011846q7934d103t980e76728842f...@mail.gmail.com>, JB Kim > <jbremn...@gmail.com> wrote: >> Thanks for the feedback. Creating these metrics into independent >> module makes sense. I'll refactor it to isolate the code within >> mod_iostat.c and see how it works out. >> Before I do so, is there a "standard" template for configure/make >> files to build these DSO modules independently? >> Having such deployment template (perhaps also .spec) structure would >> encourage other developers to contribute code more easily, I think. >> >> On Wed, Jul 1, 2009 at 11:15 AM, Brad Nicholes<bnicho...@novell.com> wrote: >>> Thanks for the new module code. I haven't had a chance to actually look >> at the code yet but considering that this is a new metric module, it might be >> better to decouple it from the rest of the Ganglia code as an independent >> module rather than having the code integrated into metrics.c and the core >> build system. If the module is independently buildable then it really >> doesn't matter if it is linux only or cross platform. Even if the module >> remained linux only, only those who are interested would download, build and >> use it which is fine. It would also make it much easier for us to simply >> drop the tarball into the /contrib directory of SVN in order to make it >> available immediately rather than having to integrate it into the core build >> and re-release the whole project. The ideal situation would be to also >> include a .spec file that would allow the module to be built and packaged >> into its own RPM. But just a buildable source tarball would be great. >>> >>> It is good to see people contributing new modules to the project even if >> they are only for a single platform. The more modules we have to offer, the >> better the whole project is for everybody. >>> >>> Brad >>> >>>>>> On 6/30/2009 at 9:00 PM, in message >>> <8121824c0906302000y181b23adr87ebd98124450...@mail.gmail.com>, JB Kim >>> <jbremn...@gmail.com> wrote: >>>> Hi folks >>>> >>>> Wow, it didn't occur to me this thread was more than a year ago. Time >>>> surely flies when you have a newborn at home. :-) >>>> In any case, I've made necessary modifications to 3.1.2 release to >>>> allow iostat-related metrics for linux. >>>> >>>> Here is the tarball that compiles on linux and reports 7 extra metrics >>>> from a new DSO module called iostat. >>>> >>>> http://www.remnantone.com/pkgs/ganglia/ganglia-3.1.2_io.tar.gz >>>> >>>> The mod_iostat contains the following metrics: >>>> >>>> - io_readtot >>>> - io_readkbtot >>>> - io_writetot >>>> - io_writekbtot >>>> - io_svctmax >>>> - io_queuemax >>>> - io_busymax >>>> >>>> The code changes have been made to: >>>> >>>> - libmetrics/libmetrics.h >>>> - libmetrics/linux/metrics.c >>>> - gmond/modules/mod_iostat.c >>>> - Makefile.am changes to include a new module build >>>> >>>> There are couple of points: >>>> >>>> * The new set of metrics are only for linux at this point. (supports >>>> 2.4 and 2.6 kernels) >>>> As you can see, all of the metric functions are implemented within >>>> libmetrics/linux/metrics.c >>>> * These metric functions report aggregated values. 4 of them are sums >>>> across disks, 3 of them are max across the disks. >>>> These metrics would be ideal for cluster computing nodes which often >>>> has 1 or 2 disks, not for large servers with multitude of disks. >>>> * I had thought about making things isolated to >>>> modules/iostat/mod_iostat.c. >>>> However, since the current implementation only works on linux, I >>>> decided it was best to place it in libmetrics/linux, which is >>>> already os-dependent code, rather than trying to support multi-os >>>> build with bunch of #ifdef/#endif inside of >>>> modules/iostat/mod_iostat.c. >>>> * Future improvements should consider reporting independent io metrics >>>> for user supplied list of disks instead of aggregating the whole. >>>> * Lastly, apologies for ugly code... >>>> >>>> If there's sufficient interest and you would like these metrics to be >>>> included in the subsequent release, I'll enhance/modify the code as >>>> necessary. >>>> >>>> Thanks! >>>> >>>> On Tue, Apr 29, 2008 at 8:58 PM, JB Kim<jbremn...@gmail.com> wrote: >>>>> Sure, sounds like a plan. I'll take a crack at it and let you know. >>>>> >>>>> On Tue, Apr 29, 2008 at 12:18 PM, Brad Nicholes <bnicho...@novell.com> >>>>> wrote: >>>>>> >>> On 4/28/2008 at 8:26 PM, in message >>>>>> <8121824c0804281926wb285fe4u5f269cfbf58a0...@mail.gmail.com>, "JB Kim" >>>>>> >>>>>> <jbremn...@gmail.com> wrote: >>>>>> > Folks, >>>>>> > >>>>>> > I've made some changes to ganglia 3.0.7 gmond code to provide >>>>>> > aggregated >>>>>> > disk IO >>>>>> > statistics for linux hosts. Since a given host can have one or more >>>>>> > disks, >>>>>> > the >>>>>> > values from each individual disk are aggregated to a sum or to a max. >>>>>> > >>>>>> > It seems like a lot of folks are using a wrapper for iostat command to >>>>>> > send >>>>>> > data >>>>>> > via gmetric. While this is also a useful approach, I thought it would >>>>>> > be >>>>>> > nice >>>>>> > and convenient to have this reported from gmond, although the data >>>>>> > would be summarized >>>>>> > for an entire host. The code simply reads from either /proc/partitions >>>>>> > or /proc/diskstats, and >>>>>> > maintains the old and the new values for each disk to calculate the >>>>>> > diff. >>>>>> > >>>>>> > These are the new metrics that were added: >>>>>> > >>>>>> > >>>>>> > Ganglia_metric_cb_define("io_readtot", io_readtot_func); >>>>>> > Ganglia_metric_cb_define("io_readkbtot", io_readkbtot_func); >>>>>> > Ganglia_metric_cb_define("io_writetot", io_writetot_func); >>>>>> > Ganglia_metric_cb_define("io_writekbtot", io_writekbtot_func); >>>>>> > Ganglia_metric_cb_define("io_svctmax", io_svctmax_func); >>>>>> > Ganglia_metric_cb_define("io_queuemax", io_queuemax_func); >>>>>> > Ganglia_metric_cb_define("io_busymax", io_busymax_func); >>>>>> > >>>>>> > >>>>>> > If you are interested, you can download and try out the source here: >>>>>> > >>>>>> > http://www.remnantone.com/pkgs/ganglia/ganglia-3.0.7_io.tar.gz >>>>>> > >>>>>> > and the README doc about the modifications I've made: >>>>>> > >>>>>> > http://www.remnantone.com/pkgs/ganglia/README >>>>>> > >>>>>> > >>>>>> > I have been running this modified gmond for sometime at work and it >>>>>> > worked out quite >>>>>> > nicely. >>>>>> > >>>>>> > I don't know how relevant this is considering the pending move to more >>>>>> > modular >>>>>> > framework for gmond core metrics in 3.1.x, but hopefully it will be >>>>>> > useful for folks still dependent on version 3.0.x. Having said that, >>>>>> > I'd be happy to help >>>>>> > integrate these metrics into 3.1.x framework as .so loadable modules, >>>>>> > if there's sufficient >>>>>> > interest. >>>>>> > >>>>>> >>>>>> I would suggest that you convert these metrics to modules first so that >>>>>> they >>>> can be included as part of the 3.1.x branch. Then if there is enough >>>> interest in backporting them, they can be backported to the 3.0.x branch. >>>>>> >>>>>> Brad >>>>>> >>>>>> >>>>> >>> >>> >>> > > >
------------------------------------------------------------------------------ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
