From 77f2ea4067e70a6b2a7ead8e53ee6f136e11929a Mon Sep 17 00:00:00 2001 From: Eric Abbott Date: Sat, 10 Mar 2012 09:31:50 -0500 Subject: [PATCH] Added note about DNS --- README.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/README.md b/README.md index 519e01b2..54016d0e 100644 --- a/README.md +++ b/README.md @@ -132,3 +132,11 @@ You can instrument class methods, just like instance methods, using the metaprog AWS::S3::Base.singleton_class.extend StatsD::Instrument AWS::S3::Base.singleton_class.statsd_measure :request, 'S3.request' ``` + +## Reliance on DNS +Out of the box StatsD is set up to be unidirectional fire-and-forget over UDP. Configuring the StatsD host to be a non-ip will trigger a DNS lookup (ie synchronous round trip network call) for each metric sent. This can be particularly problematic in clouds that have a shared DNS infrastructure such as AWS. + +### Common Workarounds +1. Using an IP avoids the DNS lookup but generally requires an application deploy to change. +2. Hardcoding the DNS/IP pair in /etc/hosts allows the IP to change without redeploying your application but fails to scale as the number of servers increases. +3. Installing caching software such as nscd that uses the DNS TTL avoids most DNS lookups but makes the exact moment of change indeterminate.