>>> On 10/29/2008 at 4:03 AM, in message <[EMAIL PROTECTED]>, Carlo Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: > On Tue, Oct 28, 2008 at 12:25:18PM -0600, Brad Nicholes wrote: >> >>> On 10/28/2008 at 3:39 AM, in message <[EMAIL PROTECTED]>, Carlo >> Marcelo Arenas Belon <[EMAIL PROTECTED]> wrote: >> >> > 2) is spoofing healthchecks really needed?, considering that the last > update >> > from the spoofed host will be updated anyway by the metric report? > > the use here of "healthcheck" is incorrect, the issue is for "heartbeats" as > detailed in the subject. > >> The health check needs to be there mainly so that the heartbeat metric shows > up for the spoofed box in the XML. > > every time a spoofed metric is sent, the "REPORTED" value for the host that > is > being spoofed will be updated, which is AFAIK the whole point of the > "heartbeat" message anyway. > > the "REPORTED" value is tied to the host and not to any specific metric > which > is where the term "heartbeat metric" doesn't really fit for a model where > the > spoofing is a METRIC attribute instead. >
Right, but there is still the heartbeat metric which is what the -H parameter is meant to produce. So if the question is, do we need to spoof the heartbeat metric from gmetric, I guess my answer is I'm not sure. The changes to gmetric were to support the functionality that already existed but using the newer XDR format. Gmond specifically looks for the heartbeat metric so that it can set the value of GMOND_STARTED in the XML. My guess is that anybody that is spoofing any metric for another machine, must also spoof a heartbeat metric as well. >> Once the module spoofing functionality has been accepted for backport, I > have an example python module that spoofs the base information such as > heartbeat, location, boottime, etc. By just adding this module, you get all > of the spoofed base metrics. > > interesting; could that be the reason why while testing gmetric spoofing in > trunk the "GMOND_STARTED" value was apparently getting updated? > > haven't yet tracked that bug, as I wanted to focus in the 3.1 code first, > but > that is also a regression as it will prevent anyone to identify which hosts > are being spoofed through it (which was one of Yemi's concerns when this was > introduced around 3.0.4) > Yep, this is probably the reason. There may be a bug in how the heartbeat value is being generated. >> > 3) even if using some METADATA with the metric code to indicate the >> > SPOOF_HOST between gmetric and gmond is that EXTRA_ELEMENT needed in the > gmond XML? >> >> I'm not sure I understand the question. The EXTRA_ELEMENT XML tag is used > because spoofing is an extension to the standard metric data just like TITLE > and GROUP. > > right; before there was no XML interface because spoofing was being done at > the XDR level, but my concern was directed at why the EXTRA_ELEMENT for > "SPOOF_HOST" was visible from the XML exported from gmond when it has been > already processed and it is indeed redundant. > Simply because the SPOOF_HOST tag is being treated like any other EXTRA_ELEMENT rather than having to put extra code into gmond just to strip it out. It isn't hurting anything by being there so there really isn't any need to do extra work to pull it out. > it is also strange IMHO that the SPOOF_HEARTBEAT doesn't show if the > intention > was to keep those EXTRA_ELEMENT in gmond after they were processed. > SPOOF_HEARTBEAT is being stripped out mainly because it is attached to the heartbeat metric and the heartbeat metric itself is never produced in the XML. >> The only way to do without the EXTRA_ELEMENT tag would be to rework the > standard tags to include some kind of spoofing attribute. > > there are already standard XDR tags for spoofing (at least in 3.0) which > could > be most likely reused for this if needed, but then I am confused of what the > rationale was behind using instead EXTRA_ELEMENT tag with 3.1 if using XDR > was > possible after the XDR refactoring. > The spoofing XDR packets no longer exist in 3.1.x. All of the XDR tags were generalized into metadata or values packets rather than packets for specific types of data. That is why spoofing shows up as an EXTRA_ELEMENT. The whole idea behind the XDR data refactoring was so that it could be easily extended without having to introduce new specialized XDR packets such as spoofing packets. All that really has to be done is just add any extra metadata as an EXTRA_ELEMENT and the existing metadata XDR packet will just handle it. Brad ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
