On 1/27/12 7:24 AM, Gladish, Jacob wrote: > > > If you want access to that metric data in JSON format, the quickest > way, by far, is to write a small conversion utility that fetches data > from the gmetad. I can imagine a perl script running in Apache/CGI > that does it on demand. You'd then have access to apache's caching > capability. And if necessary, you could even make it so that you can > query for scalars instead of the entire dataset. Imagine something > like: > > wget > http://my-gmetad-proxy:8080/gxml-to-json.pl?cluster=foo&host=bar&metric=baz > > Someone who's PHP savvy could possibly write this so that it fit > into the ganglia web. I'm not sure RPM dependencies are an issue at > this point as this could be something optionally installed or simply > disabled if JSON packages where not present. >
"Quickest" maybe if your metric is time to implement without writing C code for the ganglia project... However, what I'm proposing is offering a tcp listener port to gmond, not gmetad, which could be queried directly and in a light weight fashion and would be entirely independent from even having a running gmetad. Also, ANY system which takes one format then parses it and reformats it into a another output format is not only going to reduce transport and computational load but it will greatly increase those loads. I can say this with 100% confidence as I've implemented such systems for not only ganglia, but also for opennms, and nagios. I don't want something that builds on top of gmetad (honestly I'm not even convinced that gmetad has much of a future in ganglia-monitor-core but that is a whole other discussion) rather I'm proposing that gmond be made more flexible and developer friendly as well as increasing the general efficiency of it's method of communication. gmond already has a nice lightweight binary protocol for nodes to communicate with one another, one which it is possible to code against directly, but it requires independently tracking the metadata hash as well as maintaining a state machine to honor DMAX and TMAX policy. XML OTOH is self describing and schemaless, but it is wildly inefficient in byte count and parsing it is quite computationally expensive especially in the case of large clusters where the XML from gmond might weigh in at 10's of MB per transaction (I measured 30MB on a cluster yesterday). Generating json in the same sort of streaming fashion that the current xml code works in should be mostly trivial and the end result would serve provide more options to both endusers and developers. -Dave ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
