Restore Dogstatsd exporter

[jmacd]

This imports the code that was removed in open-telemetry/opentelemetry-go#591 without significant changes.

There was a report that the default MaxPacketSize is too large, which I was able to reproduce on my development machine. I've set it to 9216, which is Jumbo ethernet size. Another good default would be 1500. (This is configurable.)

[jmacd]

@chrisleavoy

[jmacd]

I fixed the known problem, but there is still a defect where if the MaxPacketSize is too large, data won't be sent. I tested on an OS X machine that the call to Write() returns 0 bytes written when the packet is too large. So the only way to avoid MTU-too-small errors is to dynamically adjust the packet size when we see the "message too long" error. I'll leave that up for discussion and/or another PR.

[zlozano]

Does the default packet size take into account the UDP header size + max IP header size? I only raise this since the Datadog client leaves room in its max buffer size (1500 - 8 - 60)

https://github.com/DataDog/datadog-go/blob/master/statsd/statsd.go#L42

[zlozano]

Also, it seems like the safer default would be the more conservative option of 1500 (minus room for header bytes). This seems to be the more widely accepted default configuration [1]

[1] https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/network_mtu.html

[kconwayinvision]

I fixed the known problem, but there is still a defect where if the MaxPacketSize is too large, data won't be sent. I tested on an OS X machine that the call to Write() returns 0 bytes written when the packet is too large. So the only way to avoid MTU-too-small errors is to dynamically adjust the packet size when we see the "message too long" error. I'll leave that up for discussion and/or another PR.

Getting an error back from a UDP write is highly depending on the system and system configuration. For example, Ubunut/Debian builds have a max UDP packet size of 65535 bytes whereas OSX uses 9216 bytes. It's less of an error that the packet is too big for the network and more of an error that the network stack on that machine considers the packet too large. It's much more likely that the number of bytes being written is will be considered valid from the perspective of the network stack and silently dropped by the networking infrastructure in between.

To make matters more difficult, the features required for path MTU discovery are usually disabled by default in most infrastructures. Some, like AWS and GCP, allow you to enable ICMP traffic for cases like this but I don't believe the added complexity of dynamic MTU is worth the value. I believe the most reasonable thing to do is choose a default value that works with all systems and cloud providers and defer the cost and complexity of optimization to folks who have custom infrastructures that diverge from the standard.

[jmacd]

(I had a default of 64kB because that used to work at my last employer.)

I take it 1432 is the value we want? Done.