Specification for Azure service granularity

[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.

[SylvainJuge]

Hi @gregkalapos, did you had the chance to make progress on this issue ? Is there anything I could help with (for example testing assumptions you might have with .Net implementation with the Java equivalents) ?