You’ve Already Instrumented for Lightstep
by Eric O'Rear
Picture a Tesla. Let’s go with the Model S. Are you thinking of the smooth lines and impressive 0-60 performance? The heads up displays? How about the ergonomic seats, self-driving capabilities, and range-boosting software updates? Or is it the je ne sais quoi of sitting in the spaceship-like interior?
You know what you are probably not thinking about? The complex web of wires and sensors working together “under the hood” to make the rich experience possible.
Your observability solution is a Tesla, and code instrumentation is the myriad of sensors, wires, and microprocessors enabling the dream of end-to-end observability –– and I don’t know if you’ve ever worked on automotive electronics, but it can be tedious, uncomfortable, and significantly less glamorous than the end result that they create.
What does instrumentation look like in your software? Adding spans. Developing this instrumentation is the ‘automotive electronics’ of observability, and is no small investment of effort for a development team or software organization.
As the value of distributed tracing and observability practices have become clearer, and implementations have multiplied, matured, and specialized, stakeholders considering options have more choices than ever for integrating distributed tracing into their observability flow.
There are a lot of instrumentation options available, including:
- OpenTelemetry: soon to be in beta, and the next major version of both OpenCensus and OpenTracing
No one should feel locked-in to a platform with proprietary instrumentation. The solution? Rely on open source.
To make sure our users can choose the best instrumentation for their business, Lightstep offers out-of-the-box support for a wide range of distributed tracing implementations. What does this mean for you? If you are developing or managing a service instrumented for distributed tracing, you’ve already instrumented for Lightstep.
In distributed systems, there is a non-negligible amount of code production happening in parallel and across teams that may or may not be in communication about the tools they are using for their services –– tracing instrumentation is no exception to this phenomenon. It is not unheard of for there to be multiple instrumentation implementations coexisting in a stack.
Communication challenges aside, many companies implementing tracing use different tools from different frameworks. For example, an organization might use OpenTracing for their traces, and manage their collection and export with an OpenTelemetry Collector and a Jaeger Exporter.
Don’t worry, if your team fits this bill, this doesn’t have to be a conflict that is going to send everyone back into the meeting room and chew up valuable development time. Simply tell Lightstep what instrumentation protocols to expect, and your variably-instrumented telemetry can be ingested and analyzed seamlessly.
Whether you’ve already instrumented dozens of services or are still thinking about how to view your observability data for the first time, Lightstep is ready for data from all major distributed tracing frameworks, with in-product flows that help you configure and get started in minutes.
Take Lightstep for a test drive and experience observability, today.
Interested in joining our team? See our open positions here.