OpenTelemetry Backends
Which vendor should you choose?
Introduction
In this series of blog posts, we are looking at the following OpenTelemetry backends.
(I might add more vendors here later)
For a more storage alternatives, checkout the Awesome OpenTelemetry repository.
We will talk about OpenTelemetry Backends and showcase how you simultaneously can use OpenTelemetry to send data to different systems/backends with ease. Once the data is stored, we will explore the traces using each vendors UI to visualize and analyze the data.
In this blog post, we will use an existing Kubernetes cluster together with an OpenTelemetry collector and an OpenTelemetry instrumented Golang application, that we used in our OpenTelemetry on Kubernetes post.
What is OpenTelemetry?
OpenTelemetry is a collection of tools, APIs, and SDKs.
In an earlier post “A beginner’s guide to OpenTelemetry”, we went through what you need to know to get started with OpenTelemetry. In that post we wrote that OpenTelemetry gives us the tools to create trace data, and that it provides a vendor agnostic standard for observability as it aims to standardise the generation of traces.
OpenTelemetry Backend
The traces that are sent from your application are stored in a storage backend. Even though the OpenTelemetry collector does not provides their own backend, by using it, we are not tied to any tool or vendor. Not only can we use any programming language we want, but we can also pick and choose the storage backend. Since it is vendor agnostic, we can easily switch to another backend/vendor, by just configure another exporter.
What is an Exporter?
In order to visualize and analyze your telemetry you will need to use an exporter. An exporter is a component of OpenTelemetry and is how data gets sent to different systems/back-ends.
Generally, an exporter translates the internal format into another defined format, so you can send different types of data to different backends. For example, you can send metrics (i.e Prometheus) to one backend and traces to another.
Which exporter should I use?
A common exporter to start with and that is very useful for development and debugging tasks is the console exporter.
The OTLP exporter is used to send data to an OTLP endpoint or the OpenTelemetry Collector. We will use this exporter most in the common blog posts.
The Jaeger exporter is used to send data to Jaeger.
The Logging exporter is very useful when troubleshooting as it exports data to the console
You can find a full list of supported exporters here.
How to get started?
We will use an existing OpenTelemetry collector that is deployed in a Kubernetes cluster (I’m using Kind) and then use an OTEL instrumented Golang application to send traces to the OpenTelemetry collector.
To get started, I suggest that you jump over to the OpenTelemetry on Kubernetes. By the end of that post, you will have an OpenTelemetry collector that is exporting traces directly to Jaeger using a Jaeger exporter.
The architecture from that post showed the following flow between the application, OpenTelemetry collector and Jaeger.
In the upcoming posts, next to exporting traces to Jaeger, we will see how we can export traces to other backends.
Conclusion
In this blog post, we talked about OpenTelemetry and in particular the exporter component of the OTEL collector. We also discussed what the exporter is and why we need it to send traces to backends.
Additional resources
Choosing an OpenTelemetry backend — Things to keep in mind | SigNoz
GitHub — open-telemetry/opentelemetry-collector: OpenTelemetry Collector
Processing and Exporting Data | OpenTelemetry
GitHub — magsther/awesome-opentelemetry: A curated list of OpenTelemetry resources
If you find this helpful, please click the clap 👏 button below a few times to show your support for the author 👇
