Hi Taimur:

If all your hosts are in one multicast channel, your data_source line
in gmetad.conf should look like:

data_source "test" server1

You could add additional hosts for redundancy like:

data_source "test" server1 server2 server3

However this is not strictly necessary.

If you're still having problems, perhaps there is some communication
problem between server3 and the rest of the servers -- are the servers
on the same switch?  Does your switch support multicast?

You could telnet/nc to any of the host and you should be able to
retrieve metric information in XML format for *all* three hosts, eg.

# nc localhost 8649

on server1, should give you an XML stream of all three hosts with
metric information.

When in doubt, please post your stream to www.pastebin.com and
reference it here so we can have a look.

Cheers,

Bernard

On Thu, Jan 6, 2011 at 4:08 PM, Taimur Arif <[email protected]> wrote:
>
> ________________________________________
> From: Mark Wagner [[email protected]]
> Sent: Thursday, January 06, 2011 6:14 PM
> To: [email protected]
> Subject: Re: [Ganglia-general] Second host not showing up
>
> You may have a misunderstanding of how gmond and gmetad communicate.
>
> Any gmond node that gmetad consults must have the information for all
> nodes in that cluster.
>
> This is either accomplished by using multicast or configuring all the
> nodes to send their status to a subset of nodes in the cluster and have
> gmetad query that subset as data_sources.
>
> In your simple case you would need have server2 send (create a
> udp_send_channel) to server3 (with a udp_recv_channel) or vice versa.
>
> --
> Mark Wagner | [email protected]
> System Administrator | Intelius Inc.
>
> ------------------------------------------------------------------------------
>
> Hi Mark,
>
> Both hosts have the same exact gmond.conf using default multicast settings 
> below...
>
> /* The host section describes attributes of the host, like the location */
> host {
>  location = "unspecified"
> }
>
> /* Feel free to specify as many udp_send_channels as you like.  Gmond
>   used to only support having a single channel */
> udp_send_channel {
>  #bind_hostname = yes # Highly recommended, soon to be default.
>                       # This option tells gmond to use a source address
>                       # that resolves to the machine's hostname.  Without
>                       # this, the metrics may appear to come from any
>                       # interface and the DNS names associated with
>                       # those IPs will be used to create the RRDs.
>  mcast_join = 239.2.11.71
>  port = 8649
>  ttl = 1
> }
>
> /* You can specify as many udp_recv_channels as you like as well. */
> udp_recv_channel {
>  mcast_join = 239.2.11.71
>  port = 8649
>  bind = 239.2.11.71
> }
>
> ------------------------------------------------------------------------------
> Learn how Oracle Real Application Clusters (RAC) One Node allows customers
> to consolidate database storage, standardize their database environment, and,
> should the need arise, upgrade to a full multi-node Oracle RAC database
> without downtime or disruption
> http://p.sf.net/sfu/oracle-sfdevnl
> _______________________________________________
> Ganglia-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ganglia-general
>

------------------------------------------------------------------------------
Learn how Oracle Real Application Clusters (RAC) One Node allows customers
to consolidate database storage, standardize their database environment, and, 
should the need arise, upgrade to a full multi-node Oracle RAC database 
without downtime or disruption
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Ganglia-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ganglia-general

Reply via email to