Comments (5)
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.
Related Issues (20)
- Injecting and extracting traceparent for distributed tracing HOT 8
- Update exemplar random seleection
- Metric Filters
- Metric cardinality limits
- Metric sync gauge
- Metrics: Investigate using metrics key with bucket index for histograms
- Exponential histogram
- Use a sorted list for attributes in metrics HOT 1
- Wrong seen count in exemplars test HOT 1
- broken typespec for otel_span:start_opts HOT 1
- Histogram metric with cumulative temporality HOT 19
- Histogram transient test failure
- Flapping exemplars test failure
- Codecov always fail
- breaking changes in recent version HOT 6
- opentelemetry_finch handler is failing and detaching HOT 2
- Logs are using incorrect trace and span id
- API design question for metrics instrument usage HOT 5
- Spans not being closed when parent process exits HOT 1
- otel_tracer_noop:with_span/5 doesn't restore context properly
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from opentelemetry-erlang.