OpenTelemetry (also known as OTel) is a popular open-source framework used to generate telemetry data for traces, metrics, events and logs.
In this guide, we are going to cover the best observability and application performance management tools that can be used alongside OpenTelemetry to transform telemetry data into responsive reporting dashboards.
Introduction To OpenTelemetry
The OpenTelemetry project is a collection of tools, APIs and SDKs that are used to instrument, generate, collect and export telemetry and provides you with everything you need to manage telemetry data.
Deciding upon a permanent instrumentation option for applications is becoming increasingly difficult for software engineers. By using an open-source solution such as the one provided by OpenTelemetry it is far easier to avoid being locked into using a single application to monitor and analyse your data.
By standardising traces, metrics, events and logs into telemetry data, we avoid being locked into using a single analysis tool in the long run and migrating to a different platform will not affect the accuracy of historic data.
OpenTelemetry provides everything developers and engineers need to standardise how to collect telemetry data so that you can send this data to any backend of your choosing. This provides a vendor-neutral path to instrumentation and allows you to change your backend easily without having to instrument your code again from scratch.
The OpenTelemetry collector is a key data pipeline component to have in any OpenTelemetry deployment so if you are collecting OpenTelemetry data you will have to run the OpenTelemetry collector either by yourself or through a vendor.
For a typical deployment, the OpenTelemetry SDK is installed in both services and when these services are sending data they will be sending it to the OpenTelemetry collector. The OpenTelemetry collector will then fetch this data and distribute it to any destination you’ve configured, such as Jaeger or a proprietary service (like the ones included in this guide).
There are multiple responsibilities that the OpenTelemetry collector handles, the first of these is that the collector is responsible for receiving the data in the right protocol in the right format. Its second responsibility would be to export this data to the right destination in the same format. In between, we will have a processing mechanism that is going to allow you to filter the data, buffer the data, and alter the data in between receiving and exporting the data.
In the event that you are not running the OpenTelemetry collector yourself, you will still likely have an OpenTelemetry SDK in place, either a native one or one belonging to a proprietary service, from here data will be sent to the vendor's collector.
A collector contains pipelines which include specific processing for metrics, traces and logs, just a few of the main data types that OpenTelemetry can ingest.
Harnessing Telemetry Data
Once data is collected and transferred using OTel it will then need to be processed using another analysis tool to provide insights in a readily consumable format.
When you are selecting a compatible backend to where you want to send telemetry data, whether it is another open-source tool or a proprietary service you will want to make sure that it is able to support the use of the OTLP (OpenTelemetry protocol) format.
In this guide, we are going to provide an overview of some of the biggest observability and APM vendors that have already declared their full support for OpenTelemetry and have taken steps to support OTLP.
Spunk's native support for OpenTelemetry has been built in mind with making OpenTelemetry the defacto way that all users will eventually send data to Splunk. As some of OpenTelemetry's very own standards have been proposed by Splunk employees themselves, it would be an understatement to say that this vendor is heavily invested in the success of this open-source project.
Dynatrace is fully compatible with OpenTelemetry in addition to out-of-the-box integration. The Dynatrace platform also offers automatic capturing of transactions and completely automatic instrumentation.
If you wish to handle your OpenTelemetry data in an external analysis tool then a platform such as Logit.io for OpenTelemetry provides complete cross-compatibility to handle telemetry data.
Logit.io is fully able to relay any captured telemetry data from the OpenTelemetry OTLP standard format so that you can use this data to create reports, dashboards and alerts.
AppDynamics for OpenTelemetry offers a fully compatible backend for ingesting trace data which can then be viewed easily in the UI of the AppDynamics controller. AppDynamics delivers an agentless experience for harnessing OpenTelemetry so that users can make use of the libraries that are best suited to their particular data use case.
New Relic's capabilities for handling telemetry data mean that you can instrument your application once to send telemetry data to this observability platform. This saves engineers time who may have had to repeatedly instrument their data to experience the full benefits of OpenTelemetry. Before getting started, it may be worth reading through the documentation provided by New Relic, as a number of features that their agent provides are duplicated with the addition of using OpenTelemetry's collectors.
Datadog is able to leverage and process telemetry data via its agent that is fully compatible with the OTLP. As Datadog is already highly rated for its ability to integrate with a wealth of different data sources, this native support for OpenTelemetry will only make new users integrate even easier with the platform.
AWS Distro For OTel is a production-ready distribution of the OpenTelemetry project that provides instrumentation of applications which only needs to be configured one time. Metrics support was added relatively late for this OpenTelemetry-based project, with AWS announcing the general availability of support for metrics ingestion in late May 2022.
Honeycomb and OpenTelemetry work hand in hand to allow users to ingest their telemetry data with ease. In addition to supporting the vendor-agnostic collector, Honeycomb's OpenTelemetry Distribution wraps the project's native SDK to offer additional features. These additional features include additional options for instrumentation and deterministic sampling for spans.
Lightstep’s compatibility with OpenTelemetry ensures that users can capture distributed metrics and traces from their applications. Lightstep has also actively contributed to the wider OpenTelemetry community by creating an AWS Lambda extension that was built to monitor serverless applications.
To see even more vendors that support OpenTelemetry check out this official resource from the original creators of the project.