Skip to content

Specification for Azure service granularity #661

@SylvainJuge

Description

@SylvainJuge

This is a follow-up of #646 to deal with Azure service specific parts:

  • for some other hosted NoSQL services like dynamodb, we use the cloud region name in place of the db.instance field.
  • for Azure services, the region name is usually not directly accessible, which means having access to this value might be hard or impossible when doing instrumentation.
  • this might not be specific to CosmosDB, thus we need to know if we can have a consistent strategy for all the Azure services (for example for Azure messaging services we always have a queue or topic name to use first, but the account name could be used as a common fallback when the queue or topic name is not available.

It seems however that the Account Name is usually always available as it's usually part of the remote service endpoint/URL.

Also, this common strategy is very likely to be used for storage spans: azureblob, azurefile and azuretable.

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions