I would like to add one more item to the wishlist. A while back, I posted this email to ganglia-general regarding Ganglia federation:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg00036.html Basically, the issue is, if you have multiple clusters (gmetad) that you want to aggregate via a 'super' gmetad, all the fine-grain XML data of the entire cluster is being sent to the 'super' gmetad from each gmetad. In my opinion this is wasted bandwidth, because when you click through the cluster's gmetad, you will be re-directed to that cluster's web monitoring page (from the 'super' gmetad's web monitoring page), so all you really need are the SUMMARY data, but not everything. I guess if all your clusters are local -- this isn't an issue. But if your clusters are in geographically disperse locations, and bandwidth costs is an issue, addressing this situation will be beneficial, not to mention more efficient. Would someone be able to acknowledge that this is an issue and figure out together how we can get around it? If possible I would like to see this addressed in the upcoming 3.1.0 release. Thanks, Bernard On 10/31/07, Brad Nicholes <[EMAIL PROTECTED]> wrote: > I took a quick look over the wish-list items that were proposed on the > mailing list and tried to determine which items would break compatibility and > therefore must be completed before we release 3.1.0. I have identified three > tasks for which I am planning on completing and commiting the code to trunk > over the next few weeks. These tasks include: > > 1-* Add TITLE attribute to the XDR data to communicate a human readable name > There is another task on the wish list which makes this more general which > is: > -* Flexible method of adding extra metric metadata. > We could include extra metadata, not just "alias"/"title". For > example, some > metrics have a natural minimum and maximum value. Perhaps coming up > with an > extendable way of encoding metric metadata so future changes can be > included > without losing backward compatibility. > I would rather implement the more flexible method of adding extra metric > metadata but I am not really sure how to do that with XDR. If somebody has a > good idea of how that could be done with XDR, please let me know. Otherwise > I will probably just add the attribute to the existing set of attributes. > > 2-* Add a GROUP attribute (comma delimited) to the XDR data > This would allow metrics to declare the category that they belong to. The > category should be added at the metric definition level within the metric > module rather than a directive in the .conf file. Again if there were a more > flexible way to add extra metric metadata to the XDR package, that would be > the preferred method. Short of that, I just plan to add an attribute that > would hold a comma delimited list of group names that a metric can belong to. > > 3-* Modify all byte count metric to 8 byte integers > At this point I am assuming that this is one of the issues that is causing > the 4T limit problem. For now this is just a temporary fix. The real fix > would be to move all of the built in metrics out of gmond itself and > implement them as C interface modules which define the correct counter size. > If somebody wants to tackle porting the built in metrics rather than applying > the temporary fix now, please feel free and let me know that you are doing > it. Otherwise, I will try to take care of at least getting the sizing right > and then port the metrics sometime later. > > > I have attached a rough compilation of the tasks that were identified > through the wish list. This list is not very detailed and should probably be > used as a jumping off point for adding all of these enhancements into > bugzilla. Once in bugzilla, more detail should be added to each enhancement > so that we can have a good discussion about each one, prioritize them and get > them implemented. > > Brad > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Ganglia-developers mailing list > Ganglia-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ganglia-developers > > > ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
