Hi,
some more info:
- udp_send_channel does not have a "bind" attribute, just forget my
comment below. Looking at the code sometimes helps.
- udp_recv_channel: if you specify "mcast_join" and "bind" with
different IP adresses, no unicast processing will take place (from the
gmond.conf man page)
And forget the comment about "localhost". It is a bit more complicated
like that....
Martin
--- Martin Knoblauch <[EMAIL PROTECTED]> wrote:
> Ramon, Markus,
>
> actually, below one works fine for me. The same config file is used
> on
> all gmond-hosts in the cluster (actually pretty beautiful :-).
>
> - host "172.17.17.103" receives the metrics from all participating
> gmonds.
> - all other hosts will report empty metrics if queried. If you want
> them to report their own metrics, add a upd_send_channel for
> "localhost.
> - host "172.17.33.108" is the only one allowed to query the TCP port.
> This is the host where gmetad would be running (no gmond necessary on
> this host). If you leave out the "acl" all hosts may query the TCP
> port.
>
> The "bind" in the udp_recv_channel maybe needed if you have more
> than
> one network interface and the traffic does not come on the first one.
> For the upd-send-channel, no bind should ever be *neccessary*. But I
> am
> really not sure about this.
>
>
> --------------------------------
> udp_send_channel {
> host = 172.17.17.103
> port = 9649
> }
>
> udp_recv_channel {
> port = 9649
> }
>
> tcp_accept_channel {
> acl {
> default = "deny"
> access {
> ip = 172.17.33.108
> mask = 32
> action = "allow"
> }
> }
> port = 9649
> }
> -------------------------
>
> Cheers
> Martin
>
> --- Ramon Bastiaans <[EMAIL PROTECTED]> wrote:
>
> > Actually, bind is needed to specify what local ip to bind to and
> > listen
> > on in a unicast setup.
> > mcast_join is used when listening to multicasting.
> >
> > However, why are you using 2 different ip adresses in the recv and
> > send
> > channel? This will never work.
> > You need to set you send channel to the same ip/port as your recv
> > channel.
> > Else you are sending the information to 1 place and listening for
> > that
> > information on another place.
> >
> > Kind regards,
> > - Ramon.
> >
> > Martin Knoblauch wrote:
> >
> > >Markus,
> > >
> > > if you want unicast, I would leave out the "bind" thing. That is
> > for
> > >multicast, AFAIK.
> > >
> > >telnet w.x.y.z 8649
> > >
> > >Should give you a correct list of metrices.
> > >
> > >Cheers
> > >Martin
> > >
> > >--- Markus Törnqvist <[EMAIL PROTECTED]> wrote:
> > >
> > >
> > >
> > >>Hi!
> > >>
> > >>I'm experiencing the weirdest issue here with unicasting; not
> even
> > >>the mail archives helped so I hope someone here can give me a
> hand.
> > >>
> > >>Shouldn't it suffice to have the config file look like this:
> > >>udp_send_channel {
> > >> host = w.x.y.z
> > >> port = 8649
> > >>}
> > >>
> > >>udp_recv_channel {
> > >> bind = w2.x2.y2.z2
> > >> port = 8649
> > >>}
> > >>
> > >>for those parts?
> > >>
> > >>Nothing anywhere that points to multicasts?
> > >>
> > >>Right now, with that kind of configuration, I get an empty result
> > >>set;
> > >><GANGLIA_XML VERSION="3.0.2" SOURCE="gmond">
> > >><CLUSTER NAME="unspecified" LOCALTIME="1133291540"
> > >>OWNER="unspecified" LATLONG="unspecified" URL="unspecified">
> > >></CLUSTER>
> > >></GANGLIA_XML>
> > >>Connection closed by foreign host.
> > >>
> > >>It's somewhat annoying because we can't use multicast really and
> > even
> > >>if
> > >>we did it seems some very faux IPs are sent back, which may be
> > >>another
> > >>error on my part, but irrelevant if it's due to multicasting..
> > >>
> > >>Any help is highly appreciated, thanks!
> > >>
> > >>--
> > >>mjt
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >------------------------------------------------------
> > >Martin Knoblauch
> > >email: k n o b i AT knobisoft DOT de
> > >www: http://www.knobisoft.de
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.net email is sponsored by: Splunk Inc. Do you grep through
> > log files
> > >for problems? Stop! Download the new AJAX search engine that
> makes
> > >searching your log files as easy as surfing the web. DOWNLOAD
> > SPLUNK!
> > >http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> > >_______________________________________________
> > >Ganglia-general mailing list
> > >[email protected]
> > >https://lists.sourceforge.net/lists/listinfo/ganglia-general
> > >
> > >
> >
> > --
> > .--------------------------------------------.
> > | ing. Ramon Bastiaans |
> > | HPC - Systems Programmer |
> > |--------------------------------------------|
> > | SARA - Computing and Networking Services |
> > | Kruislaan 415 PO Box 194613 |
> > | 1098 SJ Amsterdam 1090 GP Amsterdam |
> > |--------------------------------------------|
> > | Mail: bastiaans ( a t ) sara ( d o t ) nl |
> > | Web: http://www.sara.nl/ |
> > | Phone: +31 (0)20 592 80 19 |
> > | Fax: +31 (0)20 668 31 67 |
> > `--------------------------------------------'
> >
> >
>
>
> ------------------------------------------------------
> Martin Knoblauch
> email: k n o b i AT knobisoft DOT de
> www: http://www.knobisoft.de
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep through
> log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD
> SPLUNK!
> http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
> _______________________________________________
> Ganglia-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ganglia-general
>
>
------------------------------------------------------
Martin Knoblauch
email: k n o b i AT knobisoft DOT de
www: http://www.knobisoft.de
