Opentelemetry-specification: Database table / collection semantic conventions

[jamal]

What are you trying to achieve?

Use a database table or collection name as a dimension to search, filter, or aggregate spans by.

What did you expect to see?

An database semantic convention around db.table or similar. It looks like there is a mongodb specific attribute for this, db.mongodb.collection but this is a fairly common attribute for most databases.

Additional context.

There is already a PR to introduce something similar on the metrics side in #1076 as db.table, so it would make sense to be consistent. Many drivers / ORMs have a concept of the table / collection they are querying so it would be possible to provide those as part of those integrations. That being said, for cases where this is difficult it would make sense to recommend avoiding client-side parsing (similar to the rule for db.operation).

For systems where this concept doesn't exist (redis, for instance), cases where there are multiple tables in one query (sql join), or where it is difficult for the instrumentation to determine this without additional parsing, the field could be omitted and the trace storage could classify this as some default value (such as "unknown" or "other"). For these cases, db.name would become a much more relevant attribute.

[justinfoote]

:heavy_plus_sign: I'm definitely in favor of this addition. When I wrote the metrics PR, I mention this in the PR description:

But in my experience, these values are frequently available from an ORM library without
requiring SQL string parsing, and if this instrumentation may be eventually written into
those ORM libraries, I'd like to encourage them to provide this information on the
metric instruments.

But I didn't include anything like this in the spec itself.
So I have two questions:

1. Should we include this guidance in the spec itself? (Something like: provide the db.table if it's convenient, but don't do any client-side statement parsing to figure it out, and omit it if it doesn't make sense)
2. Would you like me to open a parallel PR to the trace spec with the same wording in it?

[jamal]

Thanks so much, very excited to see this in the spec! :D