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
