Tracer, span and context implementations and how to configure them about opentelemetry-erlang HOT 5 CLOSED

If we stick with the dynamic span and ctx modules I think it is best to change how they are called from ot_tracer_sdk. This part is mainly to @hauleth because he initially brought up not having empty behaviour modules and moving persistent term macro usage to the respective modules.

Since the span and ctx module should be set as part of the tracer config it doesn't make sense to have ot_span and ot_ctx be the home of the persistent terms and have functions like:

-define(ctx, (persistent_term:get({opentelemetry, ctx}))).

get(Key) ->
    ?ctx:get(Key).

This should instead go back into ot_tracer_sdk. Then we'll have behaviours ot_span_api and ot_ctx_api that won't have implementations.

from opentelemetry-erlang.

I've updated PR #7 to move setup to ot_tracer_sdk.

from opentelemetry-erlang.

I'm not following the text well this morning, so I'll zoom out.

I still see some value for defining behaviours for how contexts are tracked per process. Strong yes. As covered elsewhere, though, I've given up on needing to provide for more than one.

I'm not feeling as much value for defining behaviours for how span data is stored, but I bet that's because I'm not trying to work with this at scale yet. I'll round that up to another yes.

I'm less enthused about compile-time configuration for performance optimisation than I am for run-time configuration. Either way, let's benchmark it so we know how expensive it is to track spans.

Whatever the behaviours and configuration are, let's provide an implementation of the behaviour that people can call to invoke the currently configured behaviour. Otherwise, package authors are bound to call the default directly or reverse-engineer it and use its techniques directly. In either case, our users then won't be able to change the configuration without breaking something.

I suspect we should also use that public implementation ourselves to reach the configured behaviours unless benchmarking shows it's too expensive and we have to optimise it somehow.

How does that all match your changed thinking on the API layout, @tsloughter?

from opentelemetry-erlang.

@garthk I'm no longer concerned about optimization for why the context and span implementation would be hard coded, instead it is an issue of what does setting a tracer mean?

Should selecting a tracer be for selecting how context is stored and spans are stored? Or should both of those be configurable within the tracer.

I've gone for the latter for my current PR.

This means the same tracer can be used for any impl of ctx or span and only when more fundamental tracing changes (not sure what those would be) require writing a custom tracer impl.

from opentelemetry-erlang.

Closing this. I think it was covered by recent changes and the split into an API and SDK repo.

from opentelemetry-erlang.