So how does the gmetad server know that there is a new cluster out there
with hosts in it to start to enumerate in the web frontend?

Ron Cavallo 
Sr. Director, Infrastructure
Saks Fifth Avenue / Saks Direct
12 East 49th Street
New York, NY 10017
212-451-3807 (O)
212-940-5079 (fax) 
646-315-0119(C) 
www.saks.com
 

-----Original Message-----
From: Jesse Becker [mailto:becker...@mail.nih.gov] 
Sent: Wednesday, March 23, 2011 1:30 PM
To: Ron Cavallo
Cc: Xavier Stevens; ganglia-general@lists.sourceforge.net
Subject: Re: [Ganglia-general] Need help configuring clusters to use
separate multicast IP

On Wed, Mar 23, 2011 at 01:27:06PM -0400, Ron Cavallo wrote:
>How does the GMETAD server KNOW to listen to multiple multicast address
>is my real question. Where do you tell the server to look at that
>address?

Gmetad only talks to gmond or other gmetad processes, and does not
speak multicast.

>
>Ron Cavallo
>Sr. Director, Infrastructure
>Saks Fifth Avenue / Saks Direct
>12 East 49th Street
>New York, NY 10017
>212-451-3807 (O)
>212-940-5079 (fax)
>646-315-0119(C)
>www.saks.com
>
>
>-----Original Message-----
>From: Xavier Stevens [mailto:xstev...@mozilla.com]
>Sent: Wednesday, March 23, 2011 12:27 PM
>To: Ron Cavallo
>Cc: ganglia-general@lists.sourceforge.net
>Subject: Re: [Ganglia-general] Need help configuring clusters to use
>separate multicast IP
>
>Hey Ron,
>
>Your gmond on the gmetad server shouldn't have anything special in it.
>It should just be like any other gmond. Ours gmetad runs on one of the
>"Application Servers" so the gmond.conf on that machine would look the
>same as below. If your gmetad server is on its own you could set it up
>with a basic non-multicast gmond setup.
>
>So here's the relevant sections from gmond.conf:
>
>cluster {
>  name = "Application Servers"
>  owner = "Mozilla Metrics"
>}
>
>/* 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.76
>  mcast_if = eth0
>  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.76
>  port = 8649
>  bind = 239.2.11.76
>}
>
>/* You can specify as many tcp_accept_channels as you like to share
>   an xml description of the state of the cluster */
>tcp_accept_channel {
>  port = 8649
>}
>
>
>On 3/23/11 8:51 AM, Ron Cavallo wrote:
>> Thank you Xavier.
>>
>> Can you give me an example of the gmond.conf that is located on the
>> cluster "Application Servers"?
>>
>> Are there any changes needed in the gmond.conf on the gmetad server
to
>> allow "Application Servers" to be collected?
>>
>> I think we are getting closer to my problem... thanks all for the
>help.
>>
>> Ron Cavallo
>> Sr. Director, Infrastructure
>> Saks Fifth Avenue / Saks Direct
>> 12 East 49th Street
>> New York, NY 10017
>> 212-451-3807 (O)
>> 212-940-5079 (fax)
>> 646-315-0119(C)
>> www.saks.com
>>
>>
>> -----Original Message-----
>> From: Xavier Stevens [mailto:xstev...@mozilla.com]
>> Sent: Wednesday, March 23, 2011 11:25 AM
>> To: ganglia-general@lists.sourceforge.net
>> Subject: Re: [Ganglia-general] Need help configuring clusters to use
>> separate multicast IP
>>
>> Ron,
>>
>> You will probably want to configure it to check more than 1 machine
>per
>> cluster. That way if that machine is the one that goes down you don't
>> lose visibility into the whole cluster.
>>
>> So here's an example I pulled from our gmetad server (changed the
>> hostnames of course):
>>
>> data_source "Application Servers" app1
>> data_source "Databases" db1
>> data_source "ETL" etl1
>> data_source "Elastic Search Cluster" elasticsearch1 elasticsearch2
>> data_source "Research Cluster" admin1 admin2
>> gridname "Mozilla Metrics"
>>
>> I should note that each data source is on different multicast
>channels,
>> but we always use the default port (8649) for gmond.
>>
>> Hopefully this helps!
>>
>> Cheers,
>>
>>
>> -Xavier
>>
>>
>> On 3/23/11 8:12 AM, Ron Cavallo wrote:
>>> I see. So I need a separate IP AND A SEPARATE PORT. Got it.
>>>
>>> Also, I use a single gmond in each cluster to aggregate the single
>>> cluster. I configure the gmetad to talk to only gmond from each
>> cluster.
>>> Is that wrong?
>>>
>>> -RC
>>>
>>> Ron Cavallo
>>> Sr. Director, Infrastructure
>>> Saks Fifth Avenue / Saks Direct
>>> 12 East 49th Street
>>> New York, NY 10017
>>> 212-451-3807 (O)
>>> 212-940-5079 (fax)
>>> 646-315-0119(C)
>>> www.saks.com
>>>
>>>
>>> -----Original Message-----
>>> From: Seth Graham [mailto:set...@fnal.gov]
>>> Sent: Wednesday, March 23, 2011 11:06 AM
>>> To: Ron Cavallo
>>> Cc: Bernard Li; ganglia-general@lists.sourceforge.net
>>> Subject: Re: [Ganglia-general] Need help configuring clusters to use
>>> separate multicast IP
>>>
>>>
>>> That might work, but I don't think anyone sets up their ganglia so
>> that
>>> a single gmond is trying aggregate all clusters. That's what the
>> gmetad
>>> daemon is for.
>>>
>>> Also note that even though you have a separate multicast address for
>>> each cluster, the port still has to be unique. The port is what
>gmetad
>>> and the web frontend use to distinguish between clusters. You get
>> really
>>> weird results if multiple data_source lines use the same port.
>>>
>>>
>>> An ideal configuration might be:
>>>
>>> Each of the 5 clusters has a unique gmond.conf, with its own
>multicast
>>> address and port number.
>>>
>>> The gmetad host has 5 data_source lines to query one host from each
>of
>>> the 5 clusters.
>>>
>>>
>>>
>>>
>>> On Mar 23, 2011, at 9:52 AM, Ron Cavallo wrote:
>>>
>>>> I need some help. I am trying to configure my gmetad to collect
from
>>>> different clusters on different IP's. I have 5 clusters. This is my
>>>> gmetad collections server's local gmond.conf configuration:
>>>>
>>>>
>>>> /* Feel free to specify as many udp_send_channels as you like.
>Gmond
>>>>   used to only support having a single channel */
>>>> udp_send_channel {
>>>>  mcast_join = 239.2.11.72
>>>>  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
>>>> }
>>>>
>>>> udp_recv_channel {
>>>>  mcast_join = 239.2.11.72
>>>>  port = 8649
>>>>  bind = 239.2.11.72
>>>> }
>>>>
>>>> udp_recv_channel {
>>>>  mcast_join = 239.2.11.73
>>>>  port = 8649
>>>>  bind = 239.2.11.73
>>>> }
>>>>
>>>> udp_recv_channel {
>>>>  mcast_join = 239.2.11.74
>>>>  port = 8649
>>>>  bind = 239.2.11.74
>>>> }
>>>>
>>>> udp_recv_channel {
>>>>  mcast_join = 239.2.11.75
>>>>  port = 8649
>>>>  bind = 239.2.11.75
>>>> }
>>>>
>>>> udp_recv_channel {
>>>>  port = 8649
>>>> }
>>>>
>>>> This is an excerpt from ONE OF THE CLUSTERS ABOVE (the .74 cluster)
>>>>
>>>> /* Feel free to specify as many udp_send_channels as you like.
>Gmond
>>>>   used to only support having a single channel */
>>>> udp_send_channel {
>>>>  mcast_join = 239.2.11.74
>>>>  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.74
>>>>  port = 8649
>>>>  bind = 239.2.11.74
>>>> }
>>>>
>>>> I configure only one server in a cluster to be polled from the
>gmetad
>>>> since that server has all of the cluster members information in it
>>>> anyway. Here is how I have it configured to talk to the one gmond
>>> shown
>>>> directly above:
>>>>
>>>> data_source "SaksGoldApps" 45 sd1mzp01lx.saksdirect.com:8649
>>>>
>>>>
>>
>-----------------------------------------------------------------------
-
>>> ------
>>>> Enable your software for Intel(R) Active Management Technology to
>> meet
>>> the
>>>> growing manageability and security demands of your customers.
>>> Businesses
>>>> are taking advantage of Intel(R) vPro (TM) technology - will your
>>> software
>>>> be a part of the solution? Download the Intel(R) Manageability
>> Checker
>>>> today! http://p.sf.net/sfu/intel-dev2devmar
>>>> _______________________________________________
>>>> Ganglia-general mailing list
>>>> Ganglia-general@lists.sourceforge.net
>>>> https://lists.sourceforge.net/lists/listinfo/ganglia-general
>>>
>>
>-----------------------------------------------------------------------
-
>> ------
>>> Enable your software for Intel(R) Active Management Technology to
>meet
>> the
>>> growing manageability and security demands of your customers.
>> Businesses
>>> are taking advantage of Intel(R) vPro (TM) technology - will your
>> software
>>> be a part of the solution? Download the Intel(R) Manageability
>Checker
>>> today! http://p.sf.net/sfu/intel-dev2devmar
>>> _______________________________________________
>>> Ganglia-general mailing list
>>> Ganglia-general@lists.sourceforge.net
>>> https://lists.sourceforge.net/lists/listinfo/ganglia-general
>>
>-----------------------------------------------------------------------
-
>> ------
>> Enable your software for Intel(R) Active Management Technology to
meet
>> the
>> growing manageability and security demands of your customers.
>Businesses
>> are taking advantage of Intel(R) vPro (TM) technology - will your
>> software
>> be a part of the solution? Download the Intel(R) Manageability
Checker
>
>> today! http://p.sf.net/sfu/intel-dev2devmar
>> _______________________________________________
>> Ganglia-general mailing list
>> Ganglia-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/ganglia-general
>
>-----------------------------------------------------------------------
-------
>Enable your software for Intel(R) Active Management Technology to meet
the
>growing manageability and security demands of your customers.
Businesses
>are taking advantage of Intel(R) vPro (TM) technology - will your
software
>be a part of the solution? Download the Intel(R) Manageability Checker
>today! http://p.sf.net/sfu/intel-dev2devmar
>_______________________________________________
>Ganglia-general mailing list
>Ganglia-general@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/ganglia-general

-- 
Jesse Becker
NHGRI Linux support (Digicon Contractor)

------------------------------------------------------------------------------
Enable your software for Intel(R) Active Management Technology to meet the
growing manageability and security demands of your customers. Businesses
are taking advantage of Intel(R) vPro (TM) technology - will your software 
be a part of the solution? Download the Intel(R) Manageability Checker 
today! http://p.sf.net/sfu/intel-dev2devmar
_______________________________________________
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general

Reply via email to