Consider not turning instrumentation_scope.name into library.name

[cartermp]

We currently do this today. It's going to get super confusing for people using OTTL because they'll see a library.name value in honeycomb, decide they wanna filter on it, go into the collector, put that in their expression, and realize it's not doing anything.

However, if we do this, it does mean that there will be a time (60ish days) where any existing query based on library.name will now return different results. Customers will need to know about this in advance and then write a COALESCE derived column to keep their queries intact for that time period. Docs would also need a change.

If we decide to do this, then (IMO) the earlier the better. The impact of the difference will only get worse each day.

[TylerHelmuth]

@robbkidd suggested updating husky to allow both values. Is there a reason we should not do that in the interim?

[cartermp]

so emit two attributes rather than just one?

[TylerHelmuth]

Not permanently but during the transition period to avoid a derived column requirement.

[robbkidd]

I need to refresh my memory on the particulars of which OTLP proto versions tinker with this field. I recall some talk of library.(name|version) coming back as a field somehow, but I don't recall if it is as full-fledged field in the proto definition or as a possible attribute (maybe even set at the InstrumentationScope level). 😕

For a transition, I think we could dual write:

• The proto field formerly-known-as-library-name-but-now-is-instrumentation-scope-name gets added to the data point husky produces as "instrumentation_scope.name".
• If there isn't already a "library.name" attribute on the incoming span (at whatever level it might appear), we'll add it with the value from instrumentation_scope.name.
• (ditto scope/library.version)

[cartermp]

It'd require a DC one way or another. I guess while we do both we could encourage people to not use library.name for things, but at some point if we drop one of them, there will be all kinds of people who still use it, and would need to write that DC.

[robbkidd]

At the moment, this spec doc on transforming OTel data to non-OTLP formats says we should be writing to both (scope and library) and that we ought to prefix the field name for OTel:

• dual write proto's InstrumentationScope.name field to otel.scope.name and otel.library.name
• dual write proto's InstrumentationScope.version field to otel.scope.version and otel.library.version