On Thu, Aug 18, 2005 at 05:05:58PM -0500, Utsav Agarwal wrote: > The solution we came up with is to change the code to report only the > hostname part of the FQDN. That solves our current problem. However, I > wonder what will happen if the gmond 'collector' cannot resolve hostnames > (dns down...which admittedly is a bad situation). The rrd files will now be > created by the node's IP?
Yes. You can fix it by fixing DNS, shutting down gmetad, and then renaming the directory to the correct name. -- Brooks > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Jason A. > Smith > Sent: Wednesday, August 17, 2005 10:30 AM > To: Utsav Agarwal > Cc: Ganglia General > Subject: RE: [Ganglia-general] gmond - fully qualified host lookup > > I don't think you can force functions like getnameinfo(3) to use DNS > instead of /etc/hosts, because they rely on the system configuration to > determine how to resolve things. For example, on Linux look at the > glibc config file /etc/nsswitch.conf, a lot of systems will probably > have a line like: > > hosts: files dns > > which means all glibc functions, like getnameinfo, will first > try /etc/hosts and then dns if it is not found in the local file. If > you want to force gmond to always use dns then you would have to replace > getnameinfo with some dns client library function, possibly from bind or > some other library. This might introduce portability problems though, > and some people might not want that behavior so it might have to be made > configurable. > > ~Jason > > > On Wed, 2005-08-17 at 10:00 -0500, Utsav Agarwal wrote: > > 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 > > > > ------------------------------------------------------- > 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 -- Any statement of the form "X is the one, true Y" is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4
pgpp24I7sT8F6.pgp
Description: PGP signature
