What to do about instrumentation-specific span attributes?

[trask]

We currently capture lots of instrumentation-specific span attributes that are not defined by semantic conventions.

Questions:

• Should we only capture span attributes that are defined by semantic conventions?
• Should we propose instrumentation-specific span attributes (e.g. for aws-sdk, elasticsearch, etc) in an attempt to have consistency for these across languages?
• Is there naming convention we should follow for instrumentation-specific span attributes (e.g. standard prefixing like elasticsearch.*)?

[anuraaga]

I think the reality is we'll need instrumentation-specific attributes to capture instrumentation domain-specific issues that are important for observability. Prefixing seems like a good idea (e.g., agree that the kafka instrumentation should do kafka.tombstone instead of just tombstone. Having these spec'd would be even nicer to allow them to be consistent across languages, I've already seen the x-ray instrumentation for AWS SDK have different naming strategies which results in pain like this

https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/master/exporter/awsxrayexporter/translator/aws.go#L30

[iNikem]

Below is my understanding of the ideal world:

• All attributes have a clear use-case explaining their existence
• All attributes are defined in semantic convention
• All attributes are documented

While point 2 from above is harder to achieve, point 1 and 3 are more under our control. So in order to bring new attribute in we have to understand the use-case and then document it.

[anuraaga]

Definitely +1 to all attributes are documented, it's a clear bar to set and will naturally lend to point 1 and maybe point 2 depending on the attribute.

[anuraaga]

Filed spec issue open-telemetry/opentelemetry-specification#968

[iNikem]

@anuraaga can I assign this issue to you then? It would be nice to have assignees for P1 issues

[iNikem]

@anuraaga I think we can close this issue, right? This discussion is concluded and we seem to have an answer from Spec.