The short answer I provided is that, yes, it will fail. This might prompt some of you to use the IP in the address line of a host definition. I'd like to advise against that though for several reasons:
1) DNS is a "good thing"
Simply put, DNS is good and proper. There's a reason that it was implemented. With any network of substantial size, it will simply become LESS efficient to try and refer to everything by IP than by a DNS entry. Obviously this falls apart if you try, like most people do at first, to be "witty" with DNS names. When I was at Bellsouth DCS, we had some networked printers. Not a stretch, I know. They had 4 networked printers throughout the building. Each printer was named after a season i.e. winter,spring,summer and fall. This obviously worked for quite sometime. However, once they added that fifth printer, all of the memory that everyone had around printer names went to pot. Now they realized they had to rename all the printers and this caused no end to confusion for end users. Printers aren't such a big deal but when it's servers, it gets dangerous. Was xavier.mydomain.com the production server or was it qa? I thought wolverine.mydomain.com was qa so I made my changes there.
It's also important to use names are descriptive. dbs-0X.mydomain.com (where X is a random number) is a good start but again, was dbs-01 the production database or the development database? Personally, I'm a fan of using an additional descriptor in the DNS entry:
- devdbs-01.mydomain.com
- qadbs-01.mydomain.com
- proddbs-01.mydomain.com
The company I'm with now actually uses an interesting hybrid and follows the second method I mentioned but with good reason - servers are interchangeable. At any given point, all the applications on app-04 can be moved to app-07 to balance resources and app-04 could be repurposed as a QA server. In this environment, servers are nothing more than part of a pool of resources. In this case, EXTENSIVE use of DNS is made and production applications never share physical collocation with nonproduction applications. If one production application is running on a server then every other application on that server is production.
2) FQDN are more flexible
Simply put, it's easier to change an IP in one place than 5.
3) DNS failures can be good
Many times, because we defined address as a FQDN, I knew about failures in DNS before Nagios had even polled my DNS server.
Having said all of that, if you insist on using IP addresses or mixing them up (because of service checks against virtual hosts for instance), let me suggest the following:
Use a FQDN in host_name and the IP in address.
Using Nagios macros, you can easily modify a service or host check to use the hostname as opposed to the IP by changing the check command to use $HOSTNAME$ instead of $HOSTADDRESS$. The Nagios macro $HOSTNAME$ pulls from host_name while $HOSTADDRESS$ pulls from address.
No comments:
Post a Comment