You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
otel-erlang creates a Tracer for every OTP application based on its name and version at boot. A Tracer contains the Instrumentation Scope which has this name and version. An issue comes up now that this Scope is getting a schema url added to it. This is an important change and simplifies a lot when it comes to integrating an application and its dependencies that may follow different versions of the semantic conventions. But where do we get this url from for the schema at boot for each application?
Easiest solution is to just look for it in the application env and then users set this value in src/<app>.app.src and mix.exs respectively.
This isn't ideal because it means the user manually syncing that value with the version of the schema they are actually using in code, but since that isn't done in a single place (it isn't simply the version of the semconv they depend on, esp since we only have one version of the semconv in a project) it depends on what semconv they actually reference in any place in their code.
A wild option would be to define current_tracer as:
otel-erlang creates a Tracer for every OTP application based on its name and version at boot. A Tracer contains the Instrumentation Scope which has this name and version. An issue comes up now that this Scope is getting a schema url added to it. This is an important change and simplifies a lot when it comes to integrating an application and its dependencies that may follow different versions of the semantic conventions. But where do we get this url from for the schema at boot for each application?
Easiest solution is to just look for it in the application env and then users set this value in
src/<app>.app.src
andmix.exs
respectively.This isn't ideal because it means the user manually syncing that value with the version of the schema they are actually using in code, but since that isn't done in a single place (it isn't simply the version of the semconv they depend on, esp since we only have one version of the semconv in a project) it depends on what semconv they actually reference in any place in their code.
A wild option would be to define
current_tracer
as:But then the user would always have to have included a header with
SCHEMA_URL
anywhere they use a tracer.We'd have to do a
_with_schema_url
prefix to every macro to do this optionally. Meh.The text was updated successfully, but these errors were encountered: