Adds c:<id> field holding the container ID so the agent can attach container tags.
Brief explanation of how the new container field is handled
If DD_ENTITY_ID is set, we ignore the container field
If DD_ENTITY_ID is not set and DD_ORIGIN_DETECTION_ENABLED is not explicitly set to false or the WithoutOriginDetection() is not invoked, we try to get the app container ID by parsing /proc/self/cgroup. In case of success, the container field in will be set to .
Motivation
More granular tags (container tags instead of pod tags)
Works for containers outside of Kubernetes (e.g ECS, Fargate)
The goal of not reusing dd.internal.entity_id is to avoid parsing the value and guess the prefix on the agent side (avoid costly operations in the hot path)
Notes
Users should explicitly enable container tagging in the agent otherwise the agent ignores the container field. So even if the client sends the field automatically, the tagging won't be done without explicitly enabling it in the agent.
Cgroup parsing logic is essentially the same as in dd-trace-go
The PR does the following
c:<id>
field holding the container ID so the agent can attach container tags.Brief explanation of how the new container field is handled
DD_ENTITY_ID
is set, we ignore the container fieldDD_ENTITY_ID
is not set andDD_ORIGIN_DETECTION_ENABLED
is not explicitly set tofalse
or theWithoutOriginDetection()
is not invoked, we try to get the app container ID by parsing/proc/self/cgroup
. In case of success, the container field in will be set toMotivation
dd.internal.entity_id
is to avoid parsing the value and guess the prefix on the agent side (avoid costly operations in the hot path)Notes