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
