OpenTracing is an open and vendor neutral API for tracing, which enables users to avoid vendor lock-in, by allowing to switch the OpenTracing implementer at any time. It also enables developers of frameworks to provide tracing functionality in a standard fashion to enable better insights into framework behavior when using any OpenTracing implementation. Web-scale companies like Uber, Apple, and Yelp are using OpenTracing to get deeper visibility into their highly distributed and dynamic applications. The reason for using an SDK-based approach in favor of an agent based approach is that architects often want to have 100% control of what is traced to improve the feedback precision.

Instana needs high quality data in order to extract information about quality of service and application health by utilizing machine learning technologies. Therefore OpenTracing can be a high quality source of data, as developers normally know very well which data is useful to trace and analyze problem situations.

OpenTracing and Instana Built In Tracing

Instana strives to give customers flexibility on how traces are captured by our system. We treat any trace, regardless of its origin, equally. OpenTracing is an option for those customers who want higher control and flexibility of exactly what is traced.

It should be noted that Instana supports OpenTracing as defined in the OpenTracing specification. As as result, OpenTracing and other tracing strategies are always independent from each other. Although you can use each simultaneously and independently, the strategies themselves cannot be combined to contribute to individual traces. Each tracing strategy always generates traces independently from each other.

OpenTracing Compliant Tracers

Our OpenTracing tracer implementations can be found as open source on GitHub and can be easily used by following a few simple steps. OpenTracing code examples for other supported languages are available in the Github repositories of the respective languages:


The following example shows how to use Instana OpenTracing for Node.js.

const instana = require('@instana/collector');

// Always initialize the sensor as the first module inside the application.
  tracing: {
    enabled: true

const opentracing = require('opentracing');

// optionally use the opentracing provided singleton tracer wrapper

// retrieve the tracer instance from the opentracing tracer wrapper
const tracer = opentracing.globalTracer();

// start a new trace with an operation name
const span = tracer.startSpan('auth');

// mark operation as failed
span.setTag(opentracing.Tags.ERROR, true);

// finish the span and schedule it for transmission to instana

Best Practices

This section outlines best practices when using OpenTracing to fully utilize your Instana dashboard.

Note: This section lists best practices specific to OpenTracing. Please see also the Custom Tracing Best Practices which describes important steps agnostic to tracing strategy.

OpenTracing tags for better processing

Instana performs advanced processing and analysis on all incoming data to best monitor, learn from and alert on your applications and infrastructure. This includes OpenTracing spans.

To get the most benefit out this analysis and processing, adding the appropriate OpenTracing tags to your spans allows Instana to best analyze and act upon incoming spans.

For example, the following Python OpenTracing code provides very little information:

import opentracing

with opentracing.tracer.start_active_span('vanilla') as pscope:
  # ...
  # do something that takes 50ms
  # ...
  pscope.span.log_kv({"foo": "bar"})  

From this code, we know only that it is a span named vanilla that took 50ms of time. We don’t know the type of span it was such as an HTTP, RPC or Messaging span. We don’t know what happened during that time (such as communicating with any other component in your infrastructure).

Instead, if you provide the appropriate contextual OpenTracing tags, Instana can better analyze and extract information from that span to act on.

import opentracing
import opentracing.ext.tags as ext

with opentracing.tracer.start_active_span('webserver') as pscope:
    pscope.span.set_tag(ext.SPAN_KIND, "entry")
    pscope.span.set_tag(ext.PEER_HOSTNAME, "localhost")
    pscope.span.set_tag(ext.HTTP_URL, "/python/simple/two")
    pscope.span.set_tag(ext.HTTP_METHOD, "POST")
    pscope.span.log_kv({"foo": "bar"})

    # ...
    # work that took 50ms
    # ...

    pscope.span.set_tag(ext.HTTP_STATUS_CODE, 204)

This well annotated span tells Instana much more about what happened in the context of this span. From the tags provided we know that this is an incoming webserver request to /python/simple/two and the resulting HTTP status code was 204.

A well annotated span such as above allows Instana to extract services, monitor connections (and their health) and overall provide a richer experience in your dashboard.

See the OpenTracing specification which defines the authoritative list of all supported OpenTracing tags.

peer.service is Optional

Setting the peer.service tag is best when you don’t know if the remote side is instrumented but in general it’s not needed as long as the remote side is instrumented. In that case, it will automatically have a service name set. If peer.service is set in the client call and the server is instrumented and has a custom service name, the results are currently undefined.

More Resources & Examples

See the OpenTracing portal for more explanations, quick start guides and more.

See Also