There are many ways to create tracing data. The following is a comparison of two popular implementations: OpenCensus and OpenTracing. In the following examples, both were set up to send data to Honeycomb and to Zipkin.
OpenCensus: A vendor-agnostic tool that provides metrics collection and tracing for your services.
OpenTracing is a vendor-neutral standard for distributed tracing data.
Zipkin: A distributed tracing system. For any Zipkin implementation, you need to have a Zipkin server running to receive the data.
All of the tracing instrumentation APIs produce the same trace data. Here is an example of the output in Honeycomb:
Zipkin and Honeycomb have pretty similar waterfall diagrams. Instrumenting them both with OpenCensus was incredibly easy. In fact, switching from one to the other is just a matter of changing the initial configuration. Below, you can see a line-for-line comparison of the differences between the two setups:
We ran the same example app for both Zipkin and Honeycomb, but with different Docker processes running. The resulting output is the same as with OpenCensus.
Below is a comparison of instrumenting traces with OpenCensus versus OpenTracing:
StartSpan and OpenTracing’s
StartSpanFromContext functions take a context as the first parameter. Under the hood, this looks into the context to see if there is an existing span there. If not, a new span is added to the context. If there is an existing span, a new child span is added, a bit like nesting dolls. In the above example, the root (or parent as it’s sometimes called) span is added in the first line of
readEvaluateProcess, and then child and sibling spans are added in
processLine. Child spans can have their own child spans, creating very deep nests, but in this very simple example the root span has two sibling child spans.
The instrumentation of OpenTracing and OpenCensus is very similar, and either implementation can send data to Honeycomb.