Opened up a conversation in Gitter, was recommended by @clutchski to open up an offline, trackable discussion here.
We have a ton of different systems, implemented in all manners and languages (go, c, c++, perl, python, java, scala, elixir, erlang). You name it, we have it.
We believe that the main value to opentracing has to do with creating an industry standard around the following:
- Inter-process propagation. This can be by any means (HTTP being the most common). Standard way to pass the payload so to speak. This includes all shapes and manners of flags in addition to baggage (or even if baggage goes inter-process)
- "Wire" format for the actual span data so it can be easily consumed. For example, in XML there would be an XSD. In JSON, we can provide a schema for guidance. Same with avro.
- Sampling implications - there is the standard "shouldSample: true | false", but there may be the need for dynamic sampling algorithms. I would love to explore these use cases and that would help pound out some of the additional inter-process propagation stuff
Once you have a standard way to propagate through all of the things, and you have a standard way to "emit" spans so they can be analyzed / stored, then the world opens up for all kinds of systems to be built up from that standard.
A little background, just conveying these thoughts wrt "we should standardize on in-process propagation", which imo is less valuable than the above.
For an instrumentation library to be widely supported, it would have to have "adapters" to each of the inbound/outbound propagation formats (as well as emission formats for sending actual span data). If we all talked the same way, then I could write my library once.
Tracing is not all that difficult, there are just subtle rules to play by.
For example, it is great if I have a java web server and can use a jax-rs or servlet filter to parse the incoming trace context.
For a smaller system / microservice, I may have a few endpoints, talk to one backend and a database. It is very trivial in that instance to do my own tracing thing.
If I am writing an akka-http application, I might have a custom directive for parsing headers. For a finch application, similarly easy to have an Endpoint I can compose to pull out the trace.
My point is, I can imagine a thousand small libraries, many of which overlap with slightly different usage. Having a standard interchange format and output format (or rules) makes the development of those libraries easier while at the same time facilitating the rest of the ecosystem around collectors, aggregators, storage layers, visualization, and applications.