Comments (3)
This proposal stands as a counterpoint to #68.
Counterpoint or counterpart?
The main objective of #68 was to stop passing Span in the Context. One strong motivation for that is that SpanContext needs to be accessed in multiple places, whereas Span is quite often localized to a single scope where it is created, populated, and finished (there are, of course, exceptions with asymmetrical one-way interceptors).
I don't see Span as == SpanContext, because there is one important distinction: Span must keep an internal reference to the Tracer in order to be writeable, but SpanContext does not. If we always need a Tracer to get a Span, and Span is almost always local to a certain scope, then Span becomes just a convenience interface for write operations instead of having the same operations defined directly on the Tracer with SpanContext as an argument. However, if Span interface is the only way to capture data, then we're again forcing memory allocation regardless of the sampling state.
from oteps.
@yurishkuro Thanks. I mistook your statement that removing Span
"simplifies memory management" to be about managing Span state in the process, which is an SDK elective to do (or not do) in the current API.
Now I understand your concern is about memory allocations that could result from making Context Propagation independent of the Tracing SDK. Your point about the internal reference to a Tracer is well taken. I had written "span is essentially just a context with the addition of a process-wide sequence number", but that "essentially" masked an internal reference to the Tracer. I was thinking that two allocations (one for a Context
, one for a Span=={Tracer,Context}
) would be OK because it is O(1) memory per span either way, but you're right that we should be counting allocations particularly when, because of sampling, a span is not recorded. We wouldn't want to allocate unnecessary memory in that case. (As a tangent, in the OTel-Go repo we're slipping on this point.)
Now that I understand your concern better, I still think that Span == SpanContext
if it weren't for this not-minor detail about having a Tracer
reference. I think removing the Span
from the API is an ergonomic loss, so I have few related suggestions:
- Let the active
Tracer
be a part of the context. You wrote "whereas Span is quite often localized to a single scope where it is created, populated, and finished" and it's true. If the currentTracer
was implied by the context, thenSpan == SpanContext
holds. (h/t to @iredelmeier who made an equivalent proposal in heropentelemetry-playground
repo. - If the aim is to avoid memory allocations when spans are un-sampled, then the Get Context API is problematic in its own right. I support removing this method from the
Span
interface to address this concern. - In OTEP #66 we are talking about "separating" the Context Propagation API from the Tracing API. I believe in this separation logically, but I don't believe we should actually decouple these members so completely that they are truly independent. We'll end up with more memory allocations. I would say they are "logically separate". An example technique might be to let the Context internally leave some storage for Tracer implementations to use. Let's suppose in the common case only one Tracer is active per Context, then a single field in the Context for the Tracer to use would be sufficient to avoid memory allocations and maintain
Span == SpanContext
.
from oteps.
While we would have had the chance to do this with OTEP66, I think it's too late now. Can we close this?
from oteps.
Related Issues (20)
- Proposal: Reduce clock-skew issues in mobile and other client-side trace sources HOT 5
- Proposal: Supporting Real User Monitoring Events in OpenTelemetry HOT 27
- Proposal: Add Sensitive Data Labels HOT 15
- Proposal: Remote Sampling
- Proposal: "Plugable backend" Tracing Client/Query library HOT 16
- Proposal: Add support for Elastic Common Schema (ECS) in OpenTelemetry HOT 6
- Proposal: specify how opentelemetry will deal with idle metrics no longer being reported
- Add link to opentelemetry.io under About section HOT 1
- Proposal: Support ML Monitoring HOT 6
- Proposal: Dynamic configuration of metrics HOT 2
- Proposal: clarify behavior when retrieving non-existent currently active span HOT 13
- Proposal: The OpenTelemetry Spec should allow SDKs to export all the spans regardless of their sampled flag
- Proposal: OpenTelemetry Sandbox HOT 12
- Proposal: TraceID just being hex value doesnt help with decision making at tracing backend. Is there a possibility to encode additional metadata such as timestamp, region etc. HOT 4
- Proposal: Service renaming HOT 4
- Add a "not implemented" stage to maturity levels HOT 3
- Group maturity status into experimental and stable HOT 2
- How to convert Java Flight Recorder (JFR) file to Profiling Data Model v2 HOT 5
- profiles/follow up: location references in sample HOT 11
- profiles/follow up: consistent time format HOT 5
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 oteps.