Comments (17)
Yeah, I know of some LightStep customers that use it. Presumably others do as well via Envoy/Veneur/Istio/etc. I'll see if we can get it codified into a spec somehow.
Alternately, I think it'd be fine if this was only supported by the opentracing bridge as a legacy protocol. That might be the most straightforward way to handle it.
from opentelemetry-specification.
Related to the first point, what about x-ot
headers? Maybe have the API support a list of propagators with a default implementation of the W3C spec in SDK, then support B3/Jaeger/etc. through contrib?
from opentelemetry-specification.
Where is x-ot header defined?
from opentelemetry-specification.
I don't think it's actually defined anywhere (and whoops, it's actually ot-tracer-*
), but there's quite a few usages of it: https://github.com/search?q=ot-tracer-traceid&type=Code (although a lot of these seem like they're just gists...)
I'll see if I can find a canonical reference for it, might just be something that got decided in issues when talking about mock/noop tracer implementations.
from opentelemetry-specification.
So if there is a specification of these protocol, we can definitely support it (without a specification we cannot support it).
Do you know if anyone uses this in real production or is just define for no-op testing Tracers?
from opentelemetry-specification.
I talked this over internally and our consensus is that ot-tracer
headers shouldn't be supported in the core API/SDK, so no need to consider them for this. I think, from a maintainability perspective, it makes the most sense to have a single blessed W3C implementation in core and then address B3 and others in contrib.
from opentelemetry-specification.
re: where exporters should live - my inclination would be to put W3C support as close to core as makes sense, e.g., a standalone library that is also exposed as the default by SDKs. Anything "non-standard" - B3, Jaeger, legacy protocols, etc. - should not be part of the core SDK, so that versioning (especially deprecating!) is decoupled.
from opentelemetry-specification.
I'm not sure I understand what's the difference between W3C format and other formats, other than it being standard. As a user, why would I want to always pull W3C if I'm not going to use it for example?
from opentelemetry-specification.
Note that the Go repo recently moved propagators into the API. This may make it difficult to remove support for these formats in the future: open-telemetry/opentelemetry-go#362
from opentelemetry-specification.
API vs SDK
I like the original list, as far as SDK support. I also don't see an issue with expanding it to include more as people request them - but only in the SDK. It does not seem like these need to be in the API? I'd like to see examples of why that would be necessary. If we are putting constructors for some of these in the API, it should be a very short list - I would only suggest B3 and W3C. Otherwise, every implementation will have to implement an old Jaeger format until the end of time.
Some addition headers to consider supporting
There are headers defined in Envoy, which I'm not a fan of. But we need to either get envoy to retire them, or we need to support them: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#config-http-conn-man-headers-x-ot-span-context
@austinlparker FWIW the "ot-tracer-*" headers have their origin in the OpenTracing "basic tracers." LightStep also uses them. https://github.com/opentracing/basictracer-go/blob/master/propagation_ot.go#L22
from opentelemetry-specification.
Should the API just define an interface for propagators (inject and extract), and maybe the propagator stack, and then all implementations live in the SDK?
from opentelemetry-specification.
@austinlparker yes that's how I imagined it would work. Whether something is B3 vs TraceContext only arises in the constructor - the interfaces propagator interfaces are all in the API.
from opentelemetry-specification.
Somehow I feel we should put the Names of these standard propagation formats into the API and the Implementations in the SDK.
from opentelemetry-specification.
Btw, if we happen to provide out-of-the-box propagation with the default no-op Tracer (and Meter?), we might need to have at least W3C TraceContext in the API.
from opentelemetry-specification.
I would be happy to state that I think a NoOp implementation should be a true no-op. If the user wants to disable tracing and metrics but continue propagating context in a pass-through way, they could install a propagate-only SDK with support for all the propagators they like.
from opentelemetry-specification.
Somehow I feel we should put the Names of these standard propagation formats into the API and the Implementations in the SDK.
This feels like it'd be great except for when people want to implement their own - for instance, what if someone writes a propagator for X-Amzn-*
? We'd need to update the API, or provide a way to pass arbitrary names to the SDK.
from opentelemetry-specification.
I have proposed we think of "named" propagators, yes:
open-telemetry/oteps#66 (comment)
from opentelemetry-specification.
Related Issues (20)
- Profiling SIG: No place for decodable auxiliary/binary data for further detailed analysis HOT 11
- pkg/translator/jaeger: Copy the Jeager exporter docs from the specification HOT 1
- [configuration] Environment variable substitution syntax is hard to extend HOT 7
- Clarify how array attributes should be turned into prometheus attributes HOT 5
- Should tracers/loggers/meters be enabled by default HOT 7
- Add ability to reset metrics with Otel HOT 5
- Documentation for creating a custom Instrumentation class. HOT 3
- Give samplers the span ID HOT 18
- Schema transformation: type mismatch/conversion should be specified
- how can I convert resource attributes to data point attributes in metrics HOT 1
- Stabilize Telemetry Stability document HOT 1
- Stable instrumentations can change produced telemetry for bugfixes HOT 1
- No limits for log record body HOT 4
- Add specs for proxy support in exporters HOT 3
- Logs: Allow the registered processor to be an independent pipeline HOT 11
- Project Tracking: Sampling HOT 1
- Log section of spec compliance matrix is inconsistent
- Environment variable to set metrics producers HOT 2
- No clear API defined for resource detector libraries HOT 4
- Use ABNF syntax instead of PCRE2 in file configuration env var substitution syntax
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-specification.