Hi Brad: I just tested SVN r883 and it seems that the new gmond can no longer see older versions of gmond (prior to the XDR refactoring) -- is this an expected behaviour?
Thanks, Bernard On 11/21/07, Brad Nicholes <[EMAIL PROTECTED]> wrote: > I have just merged the monitor-core-XDR-refactor branch back into trunk. > The work that was done in the branch touched a lot of the core functionality > of gmond, gmetad and gmetric. > First of all, this new code has refactored the XDR packets by splitting > them into value packets and metadata packets. The idea here is that gmond > will normally just send a value packet on the multicast channel that just > carries enough information so that other listeners know where the packet came > from, the metric being reported, the value type and the value itself. All > other information is carried in the metadata packet which also includes > additional metadata such as a metric title and group(s) that the metric > belongs to. > For a multicast connection, the metadata packets are only sent on an as > needed bases. In other words, if a gmond listener recieves a value packet > but does not currently hold the associated metadata for the metric, it can > request that all gmonds listening on the same multicast channel, send the > metadata for all metrics included in a specific metric collection. This > allows any gmond to resync with all other gmonds on an as needed bases. In > unicast mode there isn't a way to broadcast a metadata request. Therefore a > new directive has been added called send_metadata_interval that allows a > gmond to resend its metric metadata on a specific interval. The purpose for > doing this is to try to avoid sending metric metadata with every metric > value. This wasn't necessarily a problem for the builtin metrics because > every gmond already had hardcoded knowledge of the metadata. However for > gmetrics or modular metrics this was not the case. For these types of > metrics, all metadata ha > d to be sent with each metric value. The new code makes a compromise > between sending minimal metadata for hardcoded metrics and all metadata for > unknown metrics. It also decouples the now builtin metrics from the > hardcoded metadata which will allow them to be ported to modular metrics. > This refactoring also added another capability to the entire ganglia > system and that is the ability for each metric to carry additional metadata > that can be used to enhance the web frontend. At this point the additional > metadata that is being carried is TITLE, GROUP and DESCRIPTION. However, the > new metadata packets are designed to be able to carry any additional metadata > without gmond having to know or care about what the data really is. The > downside to this is that under the current architecture of gmetad, the XML > decoding code needs to know what to expect as far as XML tags and attributes. > So given the current gmetad architecture, gmetad will have to modified > whenever a new type of metadata is added. This needs to be fixed. > > Calling for PHP web frontend help! > With the introduction of additional metadata, there is some work that needs > to be done to the web frontend. I am not a PHP hacker and I know that many > of you are, so I am asking for help in this area. The XML output of both > gmond and gmetad has been enhanced to include a new tag called <EXTRA_DATA> > This tag is contained by the <METRIC> tag and carries a single attribute and > value. The attribute can actually anything but is currently defined to be > TITLE, GROUP or DESC. There can only be a single TITLE or DESC passed for > each metric however there maybe multiple GROUPs. I would like to see > somebody enhance the web frontend in such a way so that the TITLE is being > used as the title for each metric graph rather than the metric name. Also a > new filtering method should be added to allow user to display graphs based on > the GROUP that a metric belongs to. The DESCription data could be added as > mouse-over text for each graph or constant metric. I think that these types > of en > hancements will go a long way to improving the usability of the web frontend. > It would also be very helpful of those C coders out their would review the > changes that I have made to make sure that I am not dropping metric packets > or leaking memory in some way. I am hoping that with these changes we can > start seriously looking at a 3.1 release. I would also like some feedback on > the spoofing functionality. Spoofing was reworked to simply be additional > metadata for a metric. I think I have it all working again but it could use > some more testing. > > Brad > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Ganglia-developers mailing list > Ganglia-developers@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/ganglia-developers > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
