Everyone loves hooking up 42 different types of observability tooling to all of their infrastructure and apps, right? No? Me neither, and this is why I’m so excited about OpenTelemetry. Not only is OpenTelemetry a specification that all of the observability/monitoring/APM vendors appear to be rallying around, it’s also a framework of standardized tools, APIs and SDKs. This truly has the potential to be the one observability standard to rule them all!
Accordingly, we are excited to announce an OpenTelemetry integration in the K8s Initializer project to enable observable application-ready Kubernetes playgrounds. Although the OpenTelemetry observability framework has not yet been given the generally available (GA) label, it’s anticipated exit of beta is just around the corner. We were keen to play around with this tech, and figured you would be too.
Experimenting with the Future of Kubernetes Observability
We believe OpenTelemetry will shape the future of the observability landscape for years to come, so we couldn’t wait for the official 1.0 release before offering it to our community.
Whether you are looking for a safe way to experiment with OpenTelemetry’s advanced and ground-breaking features such as tail-based sampling, aggregation of trace data from multiple application stacks, trialing different storage and visualization backends for your generated telemetry data, or you simply want to dip your toes and learn about this promising piece of technology, the K8s Initializer has got you covered.
One of the easiest ways to begin to understand your system is by adding tracing to Ingress, as it not only gives you an idea of how long requests take from your user’s perspective, but it also provides trace context throughout all your services running in Kubernetes, making it easy to extend your traces deeper into your code — this makes Ambassador a natural place to start traces from. Exploring this in a sandbox is a low-risk and fairly painless, way to start.
Spin up a Sandbox Environment
The K8s Initializer gives you one-click options to enable OpenTelemetry for your new Kubernetes environment. After selecting the mandatory ingress-controller configuration for our cluster, adding OpenTelemetry for distributed tracing into the mix is trivial:
Here, you can appreciate how easy it is to configure the OpenTelemetry collector. We currently offer the possibility to install, store and visualize distributed traces in Jaeger, running in our cluster.
Observe All-The-Things: Integrations Made Easy
Deploying the OpenTelemetry collector from scratch or hot-swapping your existing trace collector for OpenTelemetry gives you a similar experience thanks to the API portability and aggregation capabilities. You’ll be able to use the OpenTelemetry collector with your existing application instrumentation, given OpenTelemetry supports popular protocols such as Zipkin, Jaeger (over Thrift or gRPC), and of course, OpenTelemetry’s own API.
But collecting and reconciling trace data from multiple sources and formats is not enough. OpenTelemetry has the capability of exporting your application telemetry and data points to multiple destinations at once: Zipkin and Jaeger are supported of course, but why not give Lightstep a trial too?
As more and more providers and vendors add support for OpenTelemetry, this will give you, as an end-user, the power to trial and choose the tools that best support your organization’s growing needs for observability without dedicating engineering effort to re-instrument legacy applications with the latest trending libraries.
You can get started exploring OpenTelemetry and tracing in a Kubernetes sandbox environment with just a few clicks in the K8s Initializer. Check it out now!
To learn more about OpenTelemetry and Kubernetes playgrounds, we recommend checking out the following resources:
If you have any questions about Lightstep Community (or want to chat about OpenTelemetry and observability), join the Lightstep Community Discord!