If you’ve been following Instana, you probably know about Robot-Shop, which is a microservice demo application that’s easy to launch and makes for a good showcase for Instana.
Robot-Shop got a little sibling: OTel-Shop. OTel-Shop is a direct adaption of Robot-Shop – just based on OpenTelemetry. It showcases how to apply OpenTelemetry instrumentation to services in varying programming language environments.
Reusing 0pen-source instrumentation
OpenTelemetry aims to provide a vendor-neutral toolkit for harvesting traces, metrics and logs from services. The project is under a shared governance in the CNCF and everyone is invited to participate. With Instana, you have the choice: Rely on our AutoTrace components, or use OpenTelemetry artifacts.
The OTel-Shop example application is using OpenTelemetry OSS components exclusively for in-process data collection and will then use our very own Instana Agent to augment the data collected with the deep infrastructure knowledge that our Instana Agent is collecting.
Best of both worlds
This example application uses OpenTelemetry tracing, metrics and our host agent as a collector.
That way you can leverage our existing infrastructure observations and augment them with new signals generated by OpenTelemetry components.
For metrics, we leverage our existing Custom Metrics mechanic to show OpenTelemetry metrics in-context of their creation.
For traces, Instana does as well enable full infrastructure insights. We detect the emitting process and enable direct navigation from the server span generated by the OpenTelemetry Java instrumentation to the process that generated it.
How do I apply OpenTelemetry to my service landscape?
The OTel-Shop example application highlights how some of the modifications you would do look like. Most of them are pretty straight-forward!
For NodeJS for example, we need to boot up the SDK and configure the output. By modifying the Dockerfile of the service to require the tracer.js file before the server is executed, we make sure the tracer is actually loaded and going.
When looking closely at the code, you can see that the SDK is configured to automatically apply instrumentations to known code paths. This includes for example HTTP servers like express.
For Java on the other hand, the first step is to include the OpenTelemetry JavaAgent in your JVM process. This can be done without further modifications on the service code itself. For Java, the OpenTelemetry artifact does some byte-code modifications once initialized and will start generating traces right away.
OTel Shop has more examples in store:
- The dispatch service is a GoLang application
- The front service uses nginx and the OpenTelemetry CPP module
- The payment service is a Python application
- ratings is a PHP service that uses a Symfony Bundle from opentelemetry-php-contrib
- The web service is a Apache2 webserver which servers static assets
Compatibility with Instana AutoTrace
Instana in-process collectors are tuned to understand, assume and propagate the w3c trace-context correlation information to to provide seamless integration between the two worlds.
So as long as your OpenTelemetry services are configured to enable w3c trace-context propagators (which they are by default), you can enjoy full trace-continuity over HTTP.
Summary
We think OpenTelemetry has a bright future ahead! Many pieces are into place right now that enable seamless usage of OpenTelemetry components with Instanas AutoTrace technology.
That in return enables you to use the full Instana toolkit available when involving OpenTelemetry for instrumentation.
Try out Instana with a guided tour in our Play With environment.
