Brad Nicholes wrote: >>>> On 11/10/2009 at 9:30 AM, in message <[email protected]>, >>>> Daniel >>>> > Pocock <[email protected]> wrote: > >> Brad Nicholes wrote: >> >>>>>> On 11/10/2009 at 4:11 AM, in message >>>>>> >>>>>> >>> <[email protected]>, Himanshu >>> Sharma >>> <[email protected]> wrote: >>> >>> >>>> Hello all, >>>> >>>> We were looking to store Ganglia data in MySql rather than just an >>>> RRD. There was a discussion earlier on the same issue - >>>> http://www.mail-archive.com/[email protected]/msg02100. >>>> html. >>>> It would be great if there was some reusable code available or if >>>> there was any outcome out of it as to what could be the best possible >>>> approach. >>>> >>>> >>>> >>> One solution to this was the rewrite of gmetad in python. We did this a >>> >> couple of years ago and added it to the SVN repository. One of the new >> features of the python rewrite was the introduction of gmetad plugins. The >> plugin interface allows you to plug in a python module where you can do >> anything you want with the data that is being gathered from the gmond >> agents. >> There are examples of plugins that store data in an RRD database as well as >> one that generates email alerts. You should be able to use the RRD database >> plugin as an example to easily create a plugin that stores the data in a >> MySQL database instead or in addition to RRD. >> >>> >>> >> Which gmetad is intended to be on the future roadmap? >> >> For a large site, do you believe it is fair to say that the C >> implementation is best for performance? >> >> I was thinking of patching gmetad so that it can get the metrics from a >> local gmond instance using shared memory rather than XML, and some >> various other optimizations too >> >> > > This is yet-to-be-determined. Basically the Ganglia community needs to > decide which gmetad will be going forward. The python rewrite adds some new > functionality which is not available in the C version. However if the C > version continues to be good enough, then the python rewrite may never really > see the light of day. However, if there are more and more requests for > metric data to be stored or used in different ways outside of just trending, > then the python rewrite of gmetad will probably be the way to go rather than > trying to enhance the C version with the same features. The python rewrite > of gmetad has obviously not had the level of testing and stabilization as the > C version which puts the python version at a disadvantage. However with the > plugin interface, gmetad and Ganglia could really grow up to include not just > trending but alerts, health and complex data analysis too (or anything else > you can dream up for a plugin). So the bottom line is that the future > roadmap of gmetad is up to the community and who wants to step up to make > things happen. > >
I can imagine that requirements will vary amongst the community - some people have huge networks and demands for frequent polling, while other people have the luxury of ignoring scalability, and just focussing on features. Personally, I don't have a problem with making both official, or maybe even a combination of approaches, e.g. I've been playing around with a Java API for parsing the XML. It is not a complete gmetad, but I can imagine that if such building blocks were distributed with Ganglia, people would come up with fresh ideas for applications to build on top. ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Ganglia-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ganglia-developers
