[FEATURE REQ] Distributed tracing: set az.namespace attribute

[lmolkova]

[FEATURE REQ] Distributed tracing: set az.namespace attribute

OpenCensus/OpenTelemetry exporters (such as Azure Monitor exporter) may need to reliably know which that call is made against certain Azure service.

Azure Monitor exporter will use this information to navigate to corresponding Azure resource from AzMon UX and show proper icons.

Describe the solution you'd like
Add 'az.namespace' attribute on all spans (convenience and http/physical), with value set to one of the Azure resource provider namespaces on this list.

If 'component' attribute is set on convenience layer spans ( e.g. for eventhubs) - remove it.

Examples

0. Calling KeyVault with KeyVault SDK: set az.namespace attribute to Microsoft.KeyVault on all spans sent by KeyVault SDK.

1. Calling Blob Storage with SDK: set az.namespace to Microsoft.Storage on both public API span and HTTP/protocol span.
   Supporting different resource types (e.g. Blob/Queue/Table/Files) seems useful, but let's keep it for the future when we get more feedback on it. We can provide more info with extra attributes when needed.

2. SDK that could be used for different services: set az.namespace according to the best of its knowledge. E.g. Microsoft.Azure.Cosmos.Table library would use Microsoft.DocumentDb even when used with Azure Table Storage service.

3. Calling Management APIs: When calling pure ARM APIs - use Microsoft.Resources. When calling APIs specific to service (e.g. KeyVault) with service-specific management SDK, use Microsoft.KeyVault.

4. Calling something that can route or redirect call. set az.namespace according to the best of SDK knowledge. If target service is onboarded onto distributed tracing, it may provide additional telemetry on where this will be routed. Infra pieces such as load balancers, gateways or proxies are not usually visible to caller and should not require any special handling.

Describe alternatives you've considered
There are several approaches for this problem:

• Today Azure Monitor uses URL parsing for endpoints (e.g. core.windows.net is storage). This does not scale well and put extra perf pressure on the exporter (or AzMon backend) to parse them. This also does not work well on-prem and with custom endpoints.
• We could use convention via span name (add namespace) or reuse existing 'component' attribute. Such convention will still require standard list of possible services/SDKs. Span name would require parsing, 'component' will conflict with OTel component that does not solve problem of recognizing azure services (it's rather used as a protocol hint).

Additional context
Motivation for the resource provider namespace (e.g. Microsoft.Storage) is that there will be multiple parties setting/reading this property:

• Azure SDKs in 4+ languages
• Azure services which do not use client SDK to talk to other Azure services (or use old ones)
• Azure Services telemetry is identified with resourceId that includes this namespace already.

It’s much easier to standardize around existing and well known list.

Information Checklist
Kindly make sure that you have added all the following information above and checkoff the required fields otherwise we will treat the issuer as an incomplete report

• Description Added
• Expected solution specified

[maggiepint]

@johanste is this on your radar? Not sure how you want this issue categorized.

[lmazuel]

Closing this issue as I feel it's definitely not on the radar of anyone at the moment. If one day it becomes necessary, I have no doubt the discussion will restart again.

[lzchen]

Bumping this issue. Azure monitor exporter needs this to differentiate from different azure resources. The experience on Azure monitor (particularly the UX) depends on a type field to be populated from the Azure monitor exporters which can only be identified and derived from a az.namespace attribute.

[github-actions]

Hi @lmolkova, we deeply appreciate your input into this project. Regrettably, this issue has remained inactive for over 2 years, leading us to the decision to close it. We've implemented this policy to maintain the relevance of our issue queue and facilitate easier navigation for new contributors. If you still believe this topic requires attention, please feel free to create a new issue, referencing this one. Thank you for your understanding and ongoing support.