Agent Environment
Datadog Agent 7.82.2 (public.ecr.aws/datadog/agent:7.82.2-full), DDOT collector v0.155.0, running as a sidecar in an ECS Fargate task (eu-west-1, Datadog EU site).
Describe what happened
Telemetry exported through DDOT gets ecs_cluster_name set to the full ECS cluster ARN, while the Agent's own ECS Fargate check reports the bare cluster name for the same tasks. Both land in the same org, under the same tag key.
OTLP spans from the sidecar:
ecs_cluster_name:arn:aws:ecs:eu-west-1:<account>:cluster/my-cluster
ecs.fargate.* metrics from the Agent, same tasks, same cluster:
ecs_cluster_name:my-cluster
Any dashboard, monitor or grouping on ecs_cluster_name splits into two values for one cluster.
The cause looks like a mapping that copies the value unchanged:
https://github.com/DataDog/datadog-agent/blob/main/pkg/opentelemetry-mapping-go/otlp/attributes/attributes.go
string(semconv1_27.AWSECSClusterARNKey): "ecs_cluster_name",
The upstream resourcedetection ECS detector only exposes aws.ecs.cluster.arn; there is no cluster-name attribute available to map instead (documentation.md). So the ARN is the only input, and the tag ends up holding an ARN despite its name.
Describe what you expected
ecs_cluster_name to hold the cluster name on both paths, i.e. the segment after :cluster/ extracted from the ARN when mapping aws.ecs.cluster.arn, matching what the ECS Fargate check already produces.
Steps to reproduce the issue
- Run the Agent as an OTLP sidecar in an ECS Fargate task, with
resource_detection (detectors: [env, ecs]) and the datadog exporter.
- Send any span through it.
- Compare
ecs_cluster_name on the resulting spans with the same tag on ecs.fargate.* metrics from the Agent check in the same task.
Additional environment details
Current workaround on our side, a transform processor before export:
transform/ecs_cluster_name:
error_mode: ignore
trace_statements:
- replace_pattern(resource.attributes["aws.ecs.cluster.arn"], "^.*:cluster/", "")
This works, but it means every DDOT user on ECS has to know about the mismatch and repeat it in three pipelines. Extracting the name inside the mapping would make the two collection paths agree by default.
Agent Environment
Datadog Agent 7.82.2 (
public.ecr.aws/datadog/agent:7.82.2-full), DDOT collectorv0.155.0, running as a sidecar in an ECS Fargate task (eu-west-1, Datadog EU site).Describe what happened
Telemetry exported through DDOT gets
ecs_cluster_nameset to the full ECS cluster ARN, while the Agent's own ECS Fargate check reports the bare cluster name for the same tasks. Both land in the same org, under the same tag key.OTLP spans from the sidecar:
ecs.fargate.*metrics from the Agent, same tasks, same cluster:Any dashboard, monitor or grouping on
ecs_cluster_namesplits into two values for one cluster.The cause looks like a mapping that copies the value unchanged:
https://github.com/DataDog/datadog-agent/blob/main/pkg/opentelemetry-mapping-go/otlp/attributes/attributes.go
The upstream
resourcedetectionECS detector only exposesaws.ecs.cluster.arn; there is no cluster-name attribute available to map instead (documentation.md). So the ARN is the only input, and the tag ends up holding an ARN despite its name.Describe what you expected
ecs_cluster_nameto hold the cluster name on both paths, i.e. the segment after:cluster/extracted from the ARN when mappingaws.ecs.cluster.arn, matching what the ECS Fargate check already produces.Steps to reproduce the issue
resource_detection(detectors: [env, ecs]) and thedatadogexporter.ecs_cluster_nameon the resulting spans with the same tag onecs.fargate.*metrics from the Agent check in the same task.Additional environment details
Current workaround on our side, a
transformprocessor before export:This works, but it means every DDOT user on ECS has to know about the mismatch and repeat it in three pipelines. Extracting the name inside the mapping would make the two collection paths agree by default.