What to do about config options & schema versions

[hannahramadan]

Looking for some guidance.

The OTel Ruby agent is adding a configuration option (and I believe already has some) that are tied to older semconv naming conventions. When introducing new configs options and perhaps cleaning up old ones, I'm looking for guidance on what the config should be named/ if both should be recognized.

For example, a config would exist if users wanted to receive information on the table name of sql queries. The old semantic convention for this is db.sql.table, and the new name is db.collection.name. The configuration might look like db_sql_table and db_collection_name, which the option to omit or include.

Should we support both db_sql_table and db_collection_name and have them named as such or is there a better path forward.

[trask]

hi @hannahramadan!

it sounds like OTEL_SEMCONV_STABILITY_OPT_IN is what you're look for, check out https://github.com/open-telemetry/semantic-conventions/blob/main/docs/database/README.md:

Existing database instrumentations that are using v1.24.0 of this document (or prior):

• SHOULD NOT change the version of the database conventions that they emit by default until the database semantic conventions are marked stable. Conventions include, but are not limited to, attributes, metric and span names, and unit of measure.
• SHOULD introduce an environment variable OTEL_SEMCONV_STABILITY_OPT_IN in the existing major version which is a comma-separated list of values. If the list of values includes:
  • database - emit the new, stable database conventions, and stop emitting the old experimental database conventions that the instrumentation emitted previously.
  • database/dup - emit both the old and the stable database conventions, allowing for a seamless transition.
  • The default behavior (in the absence of one of these values) is to continue emitting whatever version of the old experimental database conventions the instrumentation was emitting previously.
  • Note: database/dup has higher precedence than database in case both values are present
• SHOULD maintain (security patching at a minimum) the existing major version for at least six months after it starts emitting both sets of conventions.
• SHOULD drop the environment variable in the next major version.

[hannahramadan]

Thank you for the quick response @trask ◡̈

Outside of controlling which conventions to use for all database conventions, we want to provide users with a config option whether to send a specific attribute or not. The concern is around tying config options to a specific schema version.

Should users be able to configure, for example, both db_sql_table: omit or db_collection_name: omit and have the attribute omitted, no matter the schema version? We were weary of needing to create so many configs for both schema versions.

[trask]

We were weary of needing to create so many configs for both schema versions.

yeah, I'd personally suggest sticking with the simple OTEL_SEMCONV_STABILITY_OPT_IN, and users can always customize via span processors if they have really specific needs. this is what we're doing in Java at least.

[joaopgrassi]

It seems like OTEL_SEMCONV_STABILITY_OPT_IN is the way to go, and also agree with @trask about using others ways to filter that the user have to control/configure instead of the SDK.

@hannahramadan does that help you? Can we close this issue?