search

opentracing / specification

A place to document (and discuss) the OpenTracing specification. 🛑 This project is DEPRECATED! https://github.com/opentracing/specification/issues/163
http://opentracing.io/spec
Apache License 2.0
1.17k stars 182 forks source link

Binary format requirement is too vague #88

Open ocharles opened 7 years ago

ocharles commented 7 years ago

The specification states:

All of the following formats must be supported by all Tracer implementations.

  • Binary: a (single) arbitrary binary blob representing a SpanContext

I interpret this as "a tracer must be able to inject and extract from an arbitrary binary blob". This means given any binary, I should be able to inject and (potentially) extract. But I don't think this is is what is meant, as that's fundamentally un-implementable.

I think what the specification is really saying is that that a Tracer should be able to serialize a SpanContext to binary, in whatever format it chooses, and should be able to deserialize from that same encoding.

yurishkuro commented 7 years ago

Yes. The same applies to other formats, TextMap and HTTPHeaders. Feel free to put a PR that clarifies it better - the Format controls the encoding, but the Tracer controls the actual data in that encoding.

ocharles commented 7 years ago

Thanks, I didn't actually realise that exactly what the HTTP headers were was also implementation specific. Considering the case where I have two microservices in different languages that I would like to show up in the same trace, I have to configure their respective tracers to use the same headers -- should the specification indicate that this must be configurable? Without that requirement, there's no guarantee that tracing actually spans across the system - which is kinda the point :)

yurishkuro commented 7 years ago

The interop between different tracing systems is not the goal of OpenTracing, it's up to the implementations of OpenTracing API. You as an application developer do not need to care, your objective is to instrument your application, which is what OpenTracing gives you an API for. Currently to guarantee uninterrupted traces, you need to run the same Tracer implementation in each service (even if they are in multiple languages - OpenTracing compliant tracing systems typically support multiple languages).

There is a separate initiative that addresses the interop question between tracing systems - https://github.com/TraceContext/tracecontext-spec. The good news is once that spec is finalized, you won't need to change instrumentation in your application, you'd simply need to upgrade to compatible Tracer.

ocharles commented 7 years ago

Awesome, thanks for helping bring me up to speed!

yurishkuro commented 7 years ago

@ocharles do you want to close this issue?

ocharles commented 7 years ago

I'll leave it open, I've made a note to try and provide a PR to address the wording.