[dsd] Support container ID field from dogstatsd 1.2

[ahmed-mez]

What does this PR do?

Extend origin detection on by supporting a new field in the dsd protocol, the new field c:<id> holds the container ID discovered by the client.

Motivation

• More granular tags (container tags instead of pod tags)
• Not limited to Kubernetes, and can be a good alternative in environments where origin detection on UDS is not an option (e.g Fargate)

Additional Notes

Possible Drawbacks / Trade-offs

Describe how to test/QA your changes

Deploy the agent with DD_DOGSTATSD_ORIGIN_DETECTION_CLIENT=true

echo -n "testing.dsd.container:1|g|#foo:bar,dd.internal.card:high|c:<container id>" | nc -u -w1 <Agent IP> 8125

You should be able to see container tags attached to the testing.dsd.container metric on the app.

Reviewer's Checklist

• If known, an appropriate milestone has been selected; otherwise the Triage milestone is set.
• The appropriate team/.. label has been applied, if known.
• Use the major_change label if your change either has a major impact on the code base, is impacting multiple teams or is changing important well-established internals of the Agent. This label will be use during QA to make sure each team pay extra attention to the changed behavior. For any customer facing change use a releasenote.
• A release note has been added or the changelog/no-changelog label has been applied.
• Changed code has automated tests for its functionality.
• Adequate QA/testing plan information is provided if the qa/skip-qa label is not applied.
• If applicable, docs team has been notified or an issue has been opened on the documentation repo.
• If applicable, the need-change/operator and need-change/helm labels have been applied.
• If applicable, the config template has been updated.

[maycmlee]

Small edit.

[hush-hush]

Looking good overall. We would need to update our official documentation here to add a new section for version 1.2.

[hush-hush]

Added a nit-pick on the release note. Looks good otherwise

[vickenty]

Would it make sense to c

[vickenty]

Should we skip originFromUDS if we are going to use originFromMsg? It would be nice to avoid tagging metrics with two container tags if a proxy is using UDS to send metrics on behalf of another container.

[ahmed-mez]

UDS origin detection is opt-in and not enabled by default, I'd rather let the user have control.

[vickenty]

This feature would probably interest users that use origin detection today, so they may be inclined to have both options enabled: use uds to tag traffic on older clients, while using benefits of client-side origin detection with newer clients. Unless double-tagging is a use case we explicitly want to support, I think it would make more sense to assign only one origin per metric.

[ahmed-mez]

I'd rather keep it simple as is currently and not make any assumptions.
We agreed that extending the protocol is always an option in the future, so if we want to turn on and off UDS origin detection on-demand it would be best to let the client do it via a new field.