>>> On 8/21/2008 at 11:54 AM, in message <[EMAIL PROTECTED]>, Rich
Paul <[EMAIL PROTECTED]> wrote:
> I'm currently deploying ganglia 3.1.0. I noticed that there were
> problems with nodes appearing in the gmond xml feed with no metrics, or
> with fewer metrics than they should have.
>
> My network config is as follows:
>
>
> udp_send_channel {
> host = borgdev20
> port = 8650
> }
> udp_recv_channel {
> port = 8650
> }
> tcp_accept_channel {
> port = 8181
> }
>
> It appears that when the gmond collecter, on borgdev20, receives a
> metric for which it has no metadata, which may happen (for example) when
> the collector has been restarted since the leaf nodes have been
> collected, it sends out a request for metadata. This seems reasonable.
> However, it sends it out to the udp_recv_channel, not to the host which
> sent the metric. This, I think, would work with multicast configs, but
> in the case of unicast, gmond sends the metadata request to itself, and
> then throws it in the bitbucket when it receives it.
>
> When I found this problem, I added send_metadata_interval = 15 to my
> gmond.conf, and this seems to resolve the issue. It does so, however,
> at the cost of much network traffic.
>
Yep, you ran across the same dilemma I had when I wrote it :/ The problem is
that in unicast mode, there is no requirement for any of the agents to be
listening (ie. deaf = yes) since the individual nodes don't need to do anything
more than send their own current metric to the host node. So in this instance,
attempting to send a request for metadata back to the node wouldn't work. That
is why I ended up just implementing the send_metadata_interval directive. The
downside as you pointed out, is that more data is being passed needlessly on
the wire however the amount of data should be less than with the older scheme.
The reason why I say that is because under the old scheme, all meta data for
any gmetric or modular metric was sent with every value packet rather than
being sent independently. The intent was that the send_metadata_interval would
be set to something on the order of minutes rather than seconds. This would
mean that you might lose a few minutes of data if th
e host gmond were restarted, but the amount of useless metadata packets would
be much less.
> It is probably a good idea to do two things here:
>
> 1) make gmond request metadata from the host which sent the unknown
> metric, if it is not running in multicast mode.
>
> 2) document that there is a new requirement for a working unicast
> system: in version 3.0.5, IIRC, the only requirement for leaves is that
> they be able to send packets to the collector. In version 3.1.0, the
> collector must be able to get a packet back to it's leaf nodes, unless
> the leaf nodes are sending periodic metadata.
>
This could be done but it would require that the TCP port become interactive
which is currently not the case for gmond.
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
