What Is Open Telemetry? Guide and Best Practices

Introduction

As a developer, running an application connected to numerous different services and systems can cause challenges for tracking or tracing issues. Understanding what data to collect and how to collect it properly is fundamental to quickly addressing availability and performance issues. You’ll need data about the application, which usually starts with logs. Over time, you’ll add in metrics, and, at some point, you might add traces. With OpenTelemetry^®, you get all three with one tool.

What Is OpenTelemetry?

OpenTelemetry is an open-source observability tool allowing you to collect information about the performance of your application remotely. It creates all the data needed to understand your systems and where they’re going wrong or working correctly.

The Cloud Native Computing Foundation (CNCF) hosts OpenTelemetry (formed in 2018) as a standard way to generate telemetry data. The alpha and beta versions were released in 2019 and 2020, respectively. Currently, OpenTelemetry specification has reached general availability in some of the more popular languages.

OpenTelemetry began as a merger between OpenTracing, a standard for generating trace data, and OpenCensus, a standard for generating metrics. OpenTracing and OpenCensus were founded in 2016 and 2017, respectively. The creators of OpenTelemetry hope it will one day replace OpenCensus and OpenTracing.

The OpenTelemetry project features:

• Specifications to drive consistency across the various projects
• APIs containing interfaces and implementations based on the specifications
• Software development kit (SDK) referencing implementation of the APIs
• Exporters enabling you to send data to any back end system of your choice
• Collectors providing a vendor-agnostic implementation for processing and exporting telemetry data

Use Cases for OpenTelemetry

OpenTelemetry is used in back- and front-end applications.

At the front end of your application, OpenTelemetry can do the following:

• Detect faulty logic or incorrect user input, which can cause JavaScript^® errors
• Find poorly implemented JavaScript, which makes your UI extremely slow despite having fast APIs
• Locate geo-specific lag requiring geo-distribution

At the back end of your application, OpenTelemetry can do the following:

• Detect faulty logic or incorrect user input, which leads to exceptions being thrown
• Identify improperly implemented API calls to the back end—for example, requests to infrastructure like databases or downstream APIs—leading to longer response times
• Uncover poorly performing code on an API, which also leads to longer response time

For infrastructure, OpenTelemetry can be used to:

• Perform version audits to ensure zero vulnerabilities and make sure configurations are working
• Identify configuration changes leading to performance degeneration
• Check for misconfiguration with your domain name system (DNS), causing apps to be inaccessible

Benefits of OpenTelemetry

OpenTelemetry integrates with popular languages, frameworks, and applications and offers excellent language support for language integrations. It’s flexible to use, meaning you can modify and work with various components as you choose and roll back to an older version when required. It also performs fast, providing you with all the information you need.

OpenTelemetry offers end-to-end coverage, from client applications to services to infrastructure, using a single protocol.  OpenTelemetry can cover everything from client applications to the back end. For example, opentelemetry-js, which runs on web browsers, can capture data from your back-end services to the core infrastructure they’re hosted on. It can also be used to validate your software supply chain.

Limitations of OpenTelemetry

Deploying auto instrumentation can be complicated, especially if you’re working with it for the first time, as it adds more load to your application. Including OpenTelemetry in your application can increase your lines of code and attention to traces, creating an extra burden and requiring a change in the infrastructure your application is running on, meaning it’s going to change the way you deploy your application.

Companies Using OpenTelemetry

Shopify is one example of a company using OpenTelemetry with the collector at the core of its architecture. Some use cases for implementing the collector in their system include downsampling, custom tags, renaming spans, etc. Other companies using OpenTelemetry include Alibaba, Boomin, Hyperconnect, and Tucows.

How to Get Started With OpenTelemetry

There are three basic steps for getting started with OpenTelemetry:

• Integrate with your cloud provider. You can use your cloud provider-generated metrics, logs, and metadata within their services which are only available in Amazon^® CloudWatch^®, Google Cloud^™ operations, or Microsoft^® Azure^® Monitor.
• Deploy the collector. Here, you’ll push the collector to every VM and Kubernetes cluster, where it will capture the system and logs.
• Deploy the language bit. Use the OpenTelemetry SDKs or language agents to capture metrics and traces from the services. These will push data to the collector, sending it to the back end of your choice.

Various providers for distributors of the collector, SDK, etc., are available.

PureOS^® is the OpenTelemetry main open-source OS and is a common choice for the IT community. Users will need to include the right integrations (including FluentD^® for logs) and exporters, but it still provides the full observability cloud experience. Other options include AWS Distro for OpenTelemetry, Splunk, SolarWinds, or New Relic.

OpenTelemetry Best Practices

Working with OpenTelemetry for the first time can be challenging, but the benefits can outweigh the costs. As a developer, there are best practices to help you get the most out of your telemetry data, which can improve business and user satisfaction. In the end, you’ll want to generate traces for troubleshooting to understand your system. Here are a few guidelines to keep in mind:

• When instrumenting, focus on API operations having a significant impact on your business and users.
• Focus on the key services of your applications, especially ones slowing down or crashing your system.
• Track interaction with your database system to check whether your client-side and back-end applications are working correctly.
• Make sure the components you are planning to instrument are stable enough to avoid failed instrumentation and having to write new instrumentation code.
• Attach all generated traces to your test so when there are issues such as bugs in your testing, you’ll have enough details in your trace.
• Use your trace to measure critical KPIs in your application.
• Add a task to CI/CD processes to track your code so you can compare the traces between the older and newer releases of your application. This comparison helps evaluate significant changes.
• Make sure to report or update the state of your spans (getAdsspans.addEvents()) as errors.
• Design your traces with enough detail, but don’t include excessive or unnecessary data. Too much detail can make the traces difficult to view or consume.

Conclusion

Now you’ve learned the pros and cons of OpenTelemetry and how to get started. If you want to monitor and get log messages for your applications, try out SolarWinds^® Loggly^™. Loggly offers a fast, powerful searching function for massive volumes of data, allowing you to monitor logs at scale and quickly investigate and fix issues. It’s easy and fast to set up, with powerful integrations, team visibility, and more. Try it for free today.

This post was written by Jethro Magaji. Jethro is a front-end engineer passionate about the tech world and uses creative thinking to solve business problems with a user-centered approach.