We are using udp unicast packets from our cluster to the gmond 'collector',
which gets polled by a gmetad server. My reasoning is mainly based on the
above scenario.
The reason gmond may do the lookups is that it is hierarchically closer
(cluster using NAT, own dns server?) in dns to the cluster, whereas the
Gmetad can be in a different dns zone or site. However, there could be an
option in the config files to state where name lookups need to be done.
In our case, it is not a bad idea for gmond to do the lookups, as long as it
could use a consistent scheme for lookups. Right now the library that gmond
plugs into seems to use dns for external ip's and /etc/hosts for its own ip.
I am not a programmer: While looking at the source code, I saw some
references to apr_getnameinfo, which calls getnameinfo. Man getnameinfo
gives no flag to force a FQDN response, but there is a flag to force a short
response. Perhaps FQDN response is the default, but then why would we get
the short version for the 'collector' gmond.
Snippet from manpage:
The flags argument modifies the behaviour of getnameinfo(3) as follows:
NI_NOFQDN
If set, return only the hostname part of the FQDN for local
hosts.
NI_NUMERICHOST
If set, then the numeric form of the hostname is returned.
(When not set, this will
still happen in case the node's name cannot be looked up.)
NI_NAMEREQD
If set, then a error is returned if the hostname cannot be
looked up.
NI_NUMERICSERV
If set, then the service address is returned in numeric
form, for example by its port
number.
NI_DGRAM
If set, then the service is datagram (UDP) based rather than
stream (TCP) based. This is
required for the few ports (512-514) that have different
services for UDP and TCP.
Utsav.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jason A.
Smith
Sent: Wednesday, August 17, 2005 9:16 AM
To: [EMAIL PROTECTED]
Cc: steven wagner; Ganglia General
Subject: Re: [Ganglia-general] gmond - fully qualified host lookup
I was thinking about this a little more, why does gmond need to resolve
IPs anyway? Convenience when debugging and to spare gmetad and possibly
other third party collectors of the xml data from doing the lookups.
Why not just let gmond keep the IPs only and then make gmetad resolve
the IPs?
One option that Matt suggested is to modify gmond and create a config
section where you could statically define names for IPs which gmond
would use to fill its internal hash table and therefore preventing it
from resolving those IPs.
Another option I was thinking of is to make a config setting in gmond
where it could specify if and what fqdn it should send out for itself,
like the location setting. This would also benefit multi-nic'd hosts so
you could specify the hostname you would like that node to be known as
if it happens to be different than what it is known by on its multicast
interface. For example, this would be useful if you are using a private
network for gmond's multicast but would like to have your nodes known by
their public name. The only drawback is that since gmond uses udp,
there is no guarantee of successful data delivery, so how do you handle
the case when there is no fqdn data for some nodes? Any thoughts?
~Jason
On Tue, 2005-08-16 at 18:29 -0400, Jason A. Smith wrote:
> This has come up a few times in the past I believe, once a few years ago
> when we had similar problems on some Solaris servers we were monitoring
> with a similar /etc/hosts file setup.
>
> I believe that ganglia just uses system calls like gethostbyaddr which
> rely on the OS/system libs to determine how to resolve names (for glibc
> see /etc/nsswitch.conf). To get consistent results you would probably
> have to force ganglia to always do DNS lookups (like changing it to use
> bind libs instead), but I think this might introduce some portability
> problems (or some people might not want to rely on DNS so this would
> have to be made a config option). We just ended up changing the format
> in our /etc/hosts files instead of opening up this can of worms.
>
> ~Jason
>
>
> On Tue, 2005-08-16 at 16:56 -0500, [EMAIL PROTECTED] wrote:
> > Steven,
> > Thanks for the response. It will not be practical to change the
/etc/hosts entry in a production environment. I am going to look at the
gmond source code. Any other pointers will be helpful.
> >
> > Thanks,
> > Utsav Agarwal
> >
> > ------------------------------------------------
> > On Tue, 16 Aug 2005 14:43:45 -0700, steven wagner <[EMAIL PROTECTED]>
wrote:
> >
> > > Change the order of the hosts entry to:
> > >
> > > <IP address> node1.domain.com node1 any-other-aliases
> > >
> > > That should do it...
> > >
> > > [EMAIL PROTECTED] wrote:
> > > > Hello all,
> > > > We have the following setup and issue:
> > > >
> > > > All cluster nodes send (unicast udp) data to node1 and the main
gmetad server collects data from node1. The XML stream obtained from node1
reports all nodes except itself in a fully qualified fashion. We would like
node1's gmond to report itself as fully qualified without changing
/etc/hosts file.
> > > >
> > > > On node1:
> > > > The command host <ip of node1> reports node1's FQDN.
> > > > The command hostname reports node1
> > > > In /etc/hosts, the entry is:
> > > > <ipadress> node1 node1.domain.com
> > > >
> > > > Any suggestions will be helpful.
> > > >
> > > > Thanks,
> > > > Utsav Agarwal
> > > >
> > > >
> > > > -------------------------------------------------------
> > > > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> > > > Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA
> > > > Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
> > > > _______________________________________________
> > > > Ganglia-general mailing list
> > > > Ganglia-general@lists.sourceforge.net
> > > > https://lists.sourceforge.net/lists/listinfo/ganglia-general
> > >
> > >
> > >
> > >
> > > -------------------------------------------------------
> > > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing
& QA
> > > Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
> > > _______________________________________________
> > > Ganglia-general mailing list
> > > Ganglia-general@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/ganglia-general
> > >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is Sponsored by the Better Software Conference & EXPO
> > September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> > Agile & Plan-Driven Development * Managing Projects & Teams * Testing &
QA
> > Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
> > _______________________________________________
> > Ganglia-general mailing list
> > Ganglia-general@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/ganglia-general
> >
> --
> /------------------------------------------------------------------\
> | Jason A. Smith Email: [EMAIL PROTECTED] |
> | Atlas Computing Facility, Bldg. 510M Phone: (631)344-4226 |
> | Brookhaven National Lab, P.O. Box 5000 Fax: (631)344-7616 |
> | Upton, NY 11973-5000 |
> \------------------------------------------------------------------/
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Ganglia-general mailing list
> Ganglia-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ganglia-general
>
--
/------------------------------------------------------------------\
| Jason A. Smith Email: [EMAIL PROTECTED] |
| Atlas Computing Facility, Bldg. 510M Phone: (631)344-4226 |
| Brookhaven National Lab, P.O. Box 5000 Fax: (631)344-7616 |
| Upton, NY 11973-5000 |
\------------------------------------------------------------------/
-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
_______________________________________________
Ganglia-general mailing list
Ganglia-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ganglia-general
