Opentelemetry-specification: Semantic convention for database driver name needed

[Oberon00]

For all existing semantic conventions, the component attribute is set to a fixed strings ("http" , "grpc"). But the database component should be

Database driver name or database name (when known) "JDBI", "jdbc", "odbc", "postgreSQL".

This is inconsistent. I suggest changing this to

• component: Always the string "db" (or leave it out entirely)
• db.name: The database name (when known) (Should be more explicitly specified)
• db.clienttech: The name of the database client library (e.g. JDBC driver name, Python module name, ...) which is used.

[cbandy]

Agreed. The database semantics seem rather different from the others.

• component: Always the string "db" (or leave it out entirely)

I like consistency of the value in component being a prefix/section of related attributes.

• db.name: The database name (when known) (Should be more explicitly specified)

This sounds a bit like the already defined db.instance and similar/related peer.service.

(off topic: not all databases have this concept, so it should probably be an optional attribute. e.g. a MySQL server allows a single TCP connection access multiple "databases;" PostgreSQL, on the other hand, limits a single TCP connection to a single "database.")

• db.clienttech: The name of the database client library (e.g. JDBC driver name, Python module name, ...) which is used.

1. This idea of "client library" feels sufficiently general enough that it might not need to be limited to db attributes.
2. Elsewhere in the semantic convention document, two-word attributes are separated by an underscore, e.g. http.status_code.

[Oberon00]

FYI: I'm currently working on resolving this, and generally upgrading the semantic conventions. After we hash this out internally a bit more here at Dynatrace, we will submit a PR (expected to land tomorrow (late Friday CEST) or next Monday.)

[tedsuo]

I agree with this change. I wonder: how do you see the component tag relating to the new named tracer components?

[Oberon00]

Not related at all. EDIT: The term "component" was removed from the named tracer spec/OTEP to avoid confusion.

[SergeyKanzhelev]

@tedsuo there is a similar comment here: https://github.com/open-telemetry/opentelemetry-specification/pull/264/files#r330156117 I wonder if this is something that can be unified.

[jmacd]

I propose that component be set to the name of the named Tracer or Meter. I can't imagine why we would want to specify a list of these values, they are intended as just names of a piece of code. OpenTracing specifies these as: "The software package, framework, library, or module that generated the associated Span. E.g., "grpc", "django", "JDBI"."

[SergeyKanzhelev]

@jmacd one thing though. Do we need a property saying "it's definitely HTTP". So consumer will expect certain attributes. While component may say "OKHTTP" for java. Or we will go with some sort of namespacing for component?

[kbrockhoff]

The existing approach for component is very useful in branching logic of code handling trace data. Requiring the value to be 'db' for database spans makes this branching much easier.

[bogdandrutu]

271 decided to remove the component attribute, so this will become obsolete after.

[Oberon00]

@bogdandrutu I disagree. While that does affect this issue, it leaves the question open where to store the info that is stored there for DB now (because it is not a constant string for db).

[dyladan]

Perhaps rename this issue to "semantic convention for database driver name" or similar so it is not confused?

[carlosalberto]

Hey @Oberon00 would you mind changing the name of this issue (probably going with the suggestion done by Dylan) so we can track this one?

Also, moving it to the next milestone.