On Fri, Nov 12, 2010 at 11:34 PM, Martin Knoblauch <kn...@knobisoft.de> wrote: > ----- Original Message ---- > >> From: David Birdsong <david.birds...@gmail.com> >> To: Whit Blauvelt <w...@transpect.com> >> Cc: Martin Knoblauch <kn...@knobisoft.de>; >>ganglia-gene...@lists.sourceforge.net >> Sent: Fri, November 12, 2010 9:56:26 PM >> Subject: Re: [Ganglia-general] How can gmetad be configured for 2 clusters? >> >> On Fri, Nov 12, 2010 at 9:19 AM, Whit Blauvelt <w...@transpect.com> wrote: >> > On Fri, Nov 12, 2010 at 08:35:44AM -0800, Martin Knoblauch wrote: >> > >> >> In order to separate the two clusters, they need to run on different >>ports. >> >> >> >> In addition: when you list more than one node on the data_source, this >>does not >> >> define the cluster. I just adds failover capability. "gmetad" will only >>talk to >> >> one of the hosts at a time. If that fails, it will try the next on the >>list. >> > >> > Thanks Martin. That was the whole trick. I was making the assumption that >> > gmetad, being "meta," would be the gatherer of data from the nodes. >> > Understanding that the gmonds go ahead and consolidate that changes the >> > picture entirely. As my five-year-old sometimes says, "Silly me." >> > >> > Whit >> > >> While I can't argue against something that clearly fixed this for you, >> this doesn't sound correct and it would be nice to hear this >> clarified. >> >> Sure every host would have info about every other host, but each >> host's xml tree should have all the nodes in a nested in their >> corresponding cluster tags. Gmetad could hit any host and pick up >> info about both clusters on any host, but it should know to distribute >> the updates from the xml stream to the correct clusters and not 'cross >> pollinate' the two. >> > > As far as I know, every gmond just puts all the information it has inside its > own "cluster" tags. It does not care about the cluster tags it receives from > other gmonds. It has always been the task of gmetad to build up the correct > XML > for the complete grid. Therefore it is vital that the gmond configuration for > multiple clusters is "correct". half right i think.
any gmond can receive data about any machine; each gmond will include it's cluster info as it sends metrics out. i think this is done in XDR format. the gmond that receives this info will store it in memory and export it on demand as a well-formatted xml tree wrapping machine data inside of a cluster tag as it was received in XDR format. gmetad doesn't separate data by cluster, it's already done by gmond....just telnet to a gmond's tcp_accept channel port and look at the output. default port is 8649 i think. i think any host's metric data that is not part of a cluster would still be wrapped inside of a cluster tag with a default cluster name--not sure about this though. my point is that gmetad shouldn't be confused about which host is in which cluster regardless of it's gmetad.conf. i just started with a company where the gmetad.conf was completely wrong about data sources and clusters. while the gmond.conf's on the end nodes specified the clusters as they'd intended. despite this misconfiguration it still just worked in the end because the xml tree on any of the gmond's was still correct--each host's metrics were wrapped in the cluster tags as intended. anyway, i may be dragging this out, but i figure it's good to clarify as this conversation will probably turn up in ganglia search results by some sys admin looking for answers a few months from now. > One could argue that this behaviour of "gmond" needs improvement. One > solution > could be that it aggregates only data coming from the "cluster". On the other > hand, the "cluster" tag is just optional. What should a gmond without such a > tag > do about data from tagged gmonds? I still favor correct configuration. In any > case, I am adding ganglia developers to CC. > > But the confusion shows, that documentation might be lacking ... > > Cheers > Martin > > ------------------------------------------------------------------------------ Centralized Desktop Delivery: Dell and VMware Reference Architecture Simplifying enterprise desktop deployment and management using Dell EqualLogic storage and VMware View: A highly scalable, end-to-end client virtualization framework. Read more! http://p.sf.net/sfu/dell-eql-dev2dev _______________________________________________ Ganglia-developers mailing list Ganglia-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ganglia-developers
