Open Ma-Ba opened 2 years ago
invoked_region might not be the ideal name if we also want to use the attribute to e.g. record the region from which some FaaS invocation was triggered. Maybe cloud.peer_region or cloud.remote_region?
We might also want to consider the (invoked/peer/remote) account_id here as a complement to the callers cloud.account_id, but that might be considered a separate issue.
@jsuereth can this be added to open-telemetry/opentelemetry-specification#2753?
I'm coming here from
I would argue against documenting the current behaviour - aws.region is too similar to cloud.region and is incredibly confusing, especially for new users. I quite like the idea of having a cloud.peer_region attribute.
Thank you
We noticed that the AWS SDK instrumentation in various languages sets a (client) span attribute named
aws.region
which is currently not part of the spec.I found the following instrumenation libraries that set
aws.region
:Currently, the spec contains the
cloud.region
resource attribute intended for server-side spans andfaas.invoked_region
for client-side spans of FaaS invocations. The latter is therefore not suitable for e.g. calls to DynamoDB using the AWS SDK.I'd like to propose the following:
aws.region
in the spec as an existing legancy span attributecloud.invoked_region
that fits client spans for multiple cloud platforms and SDK call typesfaas.invoked_region
in favor of the new more generic attributeI am happy to create a PR after the discussion of this issue.