Ensure the correctness of how we process metrics over DogStatsD.

[tobz]

Context

Currently, we have basic support for running an end-to-end DogStatsD pipeline:

• accept metrics using the DogStatsD protocol over UDP, and Unix domain sockets in both datagram and stream mode
• enrich metrics based on their detected origin (via SO_PASSCRED over UDS, the "container ID" extension in DogStatsD, or the dd.internal.entity_id tag)
• aggregate those metrics
• send them to the Datadog platform with close to optimal batching

However, we don't know what we don't know. We don't have or run an end-to-end testing harness against ADP and we lack the same number of unit/integration tests that the Datadog Agent itself has. In order to develop more confidence that we're "doing" DogStatsD correctly, we want to build confidence in the correctness of our solution.

Outstanding items

(this list is non-exhaustive and subject to grow/change over time)

• Ensure that our aggregation behavior matches that of the Datadog Agent. #157
• Adjust the red zone threshold for the compression estimator to be a little more conservative. #158
• Add support for splitting oversized payloads in the Datadog Metrics destination. #159
• Check for any differences in behavior between DDSketch implementation in Saluki and Datadog Agent. #160
• Determine if/how duplicate tags should be handled when resolving a context. #161