add schemaUrl support

[ericmustin]

just adding to track work around SchemaUrl (from opentelemetry-go)

The schema URL defines the version of semantic conventions used in resource. Each version of semantic conventions will export a unique schema URL that defines the form of the semantic conventions and the transforms to others.

Now that OTEP-152 spec changes have been added to the specification it would be useful to add for ruby.

There are a number of use cases / benefits that impact instrumentations+resource detectors/processors/and backends. For end-users, many of these use cases can be adopted incrementally, ie, schemaUrl support can be added to span's emitted by instrumentation before it's added to a datastore or UI-layer for handling those spans.

For additional context, an example YAML file found by making a request to the schemaUrl is in the OTEP's appendix. OpenTelemetry-Go also contains an implementation.

Also worth nothing that there's a opentelemetry-collector-contrib issue about the "transformation processor" mentioned in the OTEP , and that processor work isn't started as far as i can tell. Of course, it's possible to do the "span transformation processor"-ing via either a custom library that manipulates span/metric/log/event and resource processors yaml config, or via backend custom processing. It would be nice to see standard tooling be written here of course, but not blocking as far I can tell from having schemaUrl supported in opentelemetry-ruby.

[arielvalentin]

@ericmustin Does this mean that we need all of the auto-instrumenation to emit attributes locked to a certain schema?

To also include some constrains around what minimal semantic conventions schema version the instrumentation and SDK are emitting, unless we intend to support normalizing all fields starting from the earliest version of the schema.

WDYT?

[ericmustin]

@arielvalentin Re:

Does this mean that we need all of the auto-instrumenation to emit attributes locked to a certain schema?

I think the technical answer currently is, Yes, but only if we want to add schema_url to an instrumentation (because these instrumentations are not 1.0)

This behavior is indeed a bit constraining, and imo, i think specified incorrectly in it's current form. Some other community has recognized this as well, see: open-telemetry/opentelemetry-go#2341

It's unclear what the next steps are for this feature, I think they're trying to determine what the merge behavior ought to be, where that ought to happen, and how to determine whats mergeable and what isn't.

For now I think we should just make sure we have schema_url support in our api/sdk and export, but not necessarily populate it ootb since in practice this will create lots of Resource.merge errors.

[ahayworth]

I added schema url support in #1237, although I didn't bother adding it to any instrumentation.

It's unclear what the next steps are for this feature, I think they're trying to determine what the merge behavior ought to be, where that ought to happen, and how to determine whats mergeable and what isn't.

The resolution was "implementation dependent" 😆 - see the PR for how I chose to resolve it, we can do whatever we think is right in this instance.

[github-actions]

👋 This issue has been marked as stale because it has been open with no activity. You can: comment on the issue or remove the stale label to hold stale off for a while, add the keep label to hold stale off permanently, or do nothing. If you do nothing this issue will be closed eventually by the stale bot.