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.


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

const instana = require('instana-nodejs-sensor');

// 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.

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 out advanced analysis and processing, adding the appropriate OpenTracing tags to your spans allows Instana to best analyze incoming traces.

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.


Path Templates: Visual Grouping of HTTP Endpoints

Instana supports automatic grouping of endpoints with path templates. This is supported out of the box with Instana tracing for many frameworks. With OpenTracing, an additional step is required as described below.

Various frameworks usually have a REST path pattern similar to the following:


These similar endpoints can be grouped by reporting a http.path_tpl key in your HTTP spans with the value /api/query/{birthdate}/{name}, Instana will use this template to automatically group endpoints that match the supplied pattern. In your Instana dashbboard, the HTTP endpoints will then be grouped as as single endpoint:


See the following for an example in Go:

span := ot.GlobalTracer().StartSpan("myTemplatedSpan", ext.RPCServerOption(incomingContext))
span.SetTag("http.path_tpl", "/api/query/{birthdate}/{name}")
span.SetTag(string(ext.SpanKind), string(ext.SpanKindRPCServerEnum))
span.SetTag(string(ext.HTTPUrl), req.URL.Path)
span.SetTag(string(ext.HTTPMethod), req.Method)
span.SetTag(string(ext.HTTPStatusCode), 200)

Note that this feature is Instana specific and not OpenTracing compliant.

More Resources & Examples

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

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:

See Also