AWS ECS detector should detect otel CloudRegion/CloudAccountID/CloudAvailabilityZone/CloudResourceID

[andrew-rowson-lseg]

Some applications rely on the otel non-vendored cloud tags being populated in metrics/traces. For ECS workloads, we can populate these from the data that's already returned from the ECS Metadata API, so this can be used to add to the resource's attributes.

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: andrew-rowson-lseg / name: Andrew Rowson (6d4ae22)

[MrAlias]

This looks like a duplicate of #4860

[andrew-rowson-lseg]

This looks like a duplicate of #4860

Ah, that PR didn't exist when I originally forked. If it does the same thing, then we should obviously do that one instead.

[mmanciop]

In #4860 I did not implement cloud.resource.id though. It's unclear to me whether it should be the Task ARN or the Container ARN. I know for a fact that there is no ECS detector out there for OTEL that has implemented cloud.resource_id, as I have been recently running around adding the other cloud.* tags. I am leaning towards the Task ARN for these reasons (now also represented by this issue). Does anybody have a firm opinion on the matter?

[andrew-rowson-lseg]

In #4860 I did not implement cloud.resource.id though. It's unclear to me whether it should be the Task ARN or the Container ARN. I know for a fact that there is no ECS detector out there for OTEL that has implemented cloud.resource_id, as I have been recently running around adding the other cloud.* tags. I am leaning towards the Task ARN for these reasons. Does anybody have a firm opinion on the matter?

My pitch is that it should be the containerId, because a task can contain multiple containers which may all be looking to publish otel data. ResourceId feels like it should represent the most granular ID of the metrics/trace/logs reporter. Not firmly wedded to this though!

(I'm unable to open slack in my current context, so apologies, can't see that URL).

[mmanciop]

In #4860 I did not implement cloud.resource.id though. It's unclear to me whether it should be the Task ARN or the Container ARN. I know for a fact that there is no ECS detector out there for OTEL that has implemented cloud.resource_id, as I have been recently running around adding the other cloud.* tags. I am leaning towards the Task ARN for these reasons. Does anybody have a firm opinion on the matter?

My pitch is that it should be the containerId, because a task can contain multiple containers which may all be looking to publish otel data. ResourceId feels like it should represent the most granular ID of the metrics/trace/logs reporter. Not firmly wedded to this though!

(I'm unable to open slack in my current context, so apologies, can't see that URL).

The #opentelemetry channel in the CNCF Slack was indeed not the best place to have this discussion.

I opened this issue on the open-telemetry/semantic-conventions to track the discussion. @andrew-rowson-lseg make your voice heard over there :-)

And by containerId, you mean ContainerARN, right?

For reference, using the metadata v4 examples by AWS:

Docker Id (Container Id): "ea32192c8553fbff06c9340478a2ff089b2bb5646fb718b4ee206641c9086d66"
Container ARN: "arn:aws:ecs:us-west-2:111122223333:container/0206b271-b33f-47ab-86c6-a0ba208a70a9"
Task ARN: "arn:aws:ecs:us-west-2:111122223333:task/default/8f03e41243824aea923aca126495f665"

[mmanciop]

@andrew-rowson-lseg I am opening a PR for cloud.resource_id in a few mins, care to close this one?

[MrAlias]

Closing in favor of #5091