DB Span name format with alternating attributes

[gregkalapos]

Currently the spec for db span names defines the span name in the format of {db.operation.name} {target} with a specific list in prioritized order.

That works very well when within an instrumentation all spans have always the same attributes. However it's possible that some spans have the highest priority {target}, and some don't. That'd lead to traces where e.g. some have span names like search Users and others with names like search myDb:9200. This is specifically an issue in the Elasticsearch instrumentation, but may be relevant to others as well.

We discussed this with @jack-berg and @trask in the last DB stabilisation working group.

A few potential resolutions to this problem that came up so far:

1. We let Elasticsearch define its own naming scheme, which will be similar to the general DB span names, but differ a bit. Specifically: it'd allow just setting {db.operation.name} as the span name, when db.collection.name is not present. This is relevant, because some queries may have a specific index name, but some target all (or none) indices, so there will be some spans with just the {db.operation.name}.
2. We force Elasticsearch to stick to the current naming schema potentially resulting in mixed span names when db.operation.name is not present.
3. We introduce a common db.operation.name value for cases when we know that the instrumentation in general would be able to capture it, but for the give query it can't set it - this would result in the same span name format. Question is, do we add this to the general DB spec, or to the DB specific one?

The list is open ended - there may be better solutions.

Above I focus on Elasticsearch, but similar issue can happen with other databases, so I feel we can generalise this. Somewhat related is the HTTP span name - although in its current form this is less relevant, but as the {target} list may grow in the future, similar issue can arise there.

[gregkalapos]

From SIG:

4. Extend the general spec for db span names to suggest that once an instrumentation picked an item from the target list, then it'll always use that and if there is no value for a given span from whatever reason, then it's ok to drop the target part of the span name instead of picking the next attribute from the list. That'd avoid mixing span name format as well.