Open zkanda opened 6 years ago
@zkanda could you please provide more information on what you're hoping to achieve with OpenTracing integration?
The reason I ask, is that today OpenTracing simply defines an instrumentation API and doesn't define a context (trace ID, parent ID, etc.) or backend data format. This implies that in theory the instrumentation library could be swapped between vendors and everything should still work as expected. However, in reality given the differences in the context and backend data formats between vendors this simply isn't possible unless you're open to swapping out the SDK's.
We would love to better understand your use case in order to provide or recommend a solution.
It might help adoption to at least support the Opentracing terminology (namely spans instead of segments) and keep the api compatible in terms of span generation and propagation. But this might need to be discussed at a cross language level at Amazon.
unless you're open to swapping out the SDK's
swapping out the implementation of an interface (one line of code, from new X()
to new Y()
) is quite different from rewriting all your own (and your frameworks) code that uses that interface.
@yurishkuro thank you for the feedback. We would love to see the OpenTracing community take a lead on this work as subject matter experts on the OpenTracing API. We would be happy to work with the community towards a solution similar to the exporter for X-Ray provided by OpenCensus
We continue to be very interested in the issue of standardized tracing data format and APIs as a topic and working with the community to evolve X-Ray over time.
Is there a plan to integrate it with some vendor neutral like opentracing?