On Tue, Sep 09, 2008 at 01:07:10PM -0500, Ryan Robertson wrote:
> My goal was to have multiple nodes reporting to a central location
> (10.50.54.31) also running gmond and reporting info on itself as well.
then you need all gmond configured with the same cluster name and setup to
use unicast with 10.50.54.31 as the collector.
the only one that should need to have "tcp_accept_channel" so you can query it
in TCP/8649 (what gmetad will do) will be the collector.
> To accomplish this, wouldn't I configure the clients that will be sending
> data something to this effect:
> ----------------------------------
> /* Feel free to specify as many udp_send_channels as you like. Gmond
> used to only support having a single channel */
> udp_send_channel {
> host = 10.50.54.31
> port = 8649
> ttl = 1
> mcast_if = en2
> }
> ----------------------------------
no you are missing unicast and multicast in that configuration (which probably
shouldn't be allowed to work but does anyway as explained before). you need
instead :
udp_send_channel {
host = 10.50.54.31
port = 8649
}
> The 10.50.54.31 was the original gmond.conf posted.
because this one has to collect all data send to him from the other nodes it
also needs :
udp_recv_channel {
port = 8649
}
and because it is the only one that has all the nodes information and will be
queried from gmetad from it it should also have :
tcp_accept_channel {
port = 8649
timeout = -1
}
> I'm assuming the
> gmetad server (10.50.54.48) reaches out to the nodes defined in
> gmetad.conf for information.
in a unicast configuration it should only point to the collector gmond,
because that is the only one collecting all metrics from the cluster with
something like :
data_source "ganglia" 10.50.54.31
where "ganglia" hopefully describes the use of your cluster and matches what
you configured in your gmond.conf as the cluster name with something like :
cluster {
name = "ganglia"
}
> Is there a method in which they only are
> aware of their own information?
not sure what you mean here, but if you use each node as its own collector
then will only have their own information, but also by definition they will
be also their own independent cluster (even if the cluster name is the
same on all of them) and you will have no way to collect them in a single
view in the frontend, because gmetad doesn't aggregate data from multiple
sources.
> Lastly, I have a few nodes where HACMP is in place using IP Aliasing on a
> single interface. In these cases, i need to bind gmond.conf to a
> particular IP.
if you are using unicast you won't need to do that, if you are using multicast
you will need to stay with 3.0.7 or wait for 3.1.2 to be able to use mcast_if,
or change your routing table to ensure that multicast is routed through the
virtual interface.
also remember that you can't mix 3.0 and 3.1 gmond in the same cluster so
you have to use the same version in all nodes (including the collector)
look at the previous reply with examples and gmond.conf(5) for more details
on configuring ganglia.
Carlo
-------------------------------------------------------------------------
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-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-general
