How to connect to a Server. If omitted, we'll try to connect to a UDP server on localhost:8125.

There are many different statistic products out there, that all speak the StatsD protocol, or at least some variant of it. This property allows us to select different StatD dialects, which could unlock some new features, and may also change some subtle features behind-the-scenes to work better with this server. (Like how tags get normalized, for example.)

Valid dialects:

• "statsd": The official StatsD server, written by Etsy with Node.js.
• "datadog": The version of StatsD supported by DogStatD, the Datadog stat server.

The sampling rate we'll use for metrics. This should be a value between 0 and 1, inclusive.

For example, if this value is set to 0.1, then 1 out of 10 calls to .count() will actually result in a counter being sent to the server. HOWEVER, the server will then increase the counter by 10x the amount it normally would have been increased. This will result in less data being sent over the wire, but with mostly the same ending values. (Albeit with a bit more error.)

StatsD occasionally has some erratic behaviors when dealing with sampleRates. For example, relative gauges don't have any sampleRate corrections on the server-side, and so would result in the wrong number of adjustments being made to the data. Same with sets: the wrong number of unique values will be reported if sampleRates are used.

This setting, when true, will cause us to ignore the sampleRate in metrics that wouldn't handle it well. (Relative gauges, and Sets.)

When we get a metric to send, we'll wait (at most) this number of milliseconds before actually sending it. This gives us some time for other metrics to be queued up, so we can send them all at once, in the same packet. We may decide to send the packet sooner (like if it gets too big for the MTU) but in general, this is the maximum amount of time that your metric will be delayed.

Tags are key-value pairs that are appended to each metric.

This library will not log anything by default. However, if you'd get a little more feedback about how the StatsD connection is going, you can get that by providing a logger object here. The type of this parameter is pretty vague, but should be compatible with most versions of the std library's logger: