The Best Practices Guide to OpenTelemetry for Developers

Published on by

The Best Practices Guide to OpenTelemetry for Developers image

OpenTelemetry is a free and open-source software initiative with the objective of supplying software developers with the means to create distributed systems.

OpenTelemetry was developed by engineers at Google, and developers have the ability to utilize it to create a standard foundation for the construction of distributed systems.

The goal is to enable developers to write code once and then deploy it in any location of their choosing. There is no need to be concerned with the various operating systems and languages.

The Current State of OpenTelemetry

OpenTelemetry works collectively with separate groups focusing on different aspects of telemetry. Each group focuses on a different aspect: distributed tracing, logging, metrics, or programming language-specific clients.

They're each independent, but they share some standard features. As a result, release cadences are group-specific. Different parts of OpenTelemetries may be at different stages in the maturity cycle.

  • Draft components have not been added to the specification yet. They're still in the planning stage.
  • Experimental components have been released but are only available for beta testing.
  • Stable components are backward compatible and covered under long-term support.
  • Deprecated components may be removed in the future, though they are stable.

The current situation with regard to the tracking of baggage, metrics, and traceability is stable. However, it is now in the draft stage of the logging process. In addition, there are strategies in place to enhance both the quality and accessibility of the instruments.

The OpenTelemetry definition was updated to version 1.0 in April 2020, at which time the team also initiated work on the process of adding log messages.

As of May 2019, there were currently no plans to implement any further kinds of telemetry.

Instrumentation Concepts

OpenTelemetry is a new approach to instrumenting applications. It's based on a simple idea: instead of writing code that runs in your application, you write code that runs outside your application and reports back information about what it sees inside it.

You can use any programming language or framework you want for your project. Modifying your existing code is unnecessary – this is the future of instrumentation.

Deep and wide

You have access to a wide variety of materials when using OpenTelemetry.

Because it is open-source, you can take advantage of the work of more than 100,000 contributors.

Enhanced protection, heightened adaptability, and ubiquity are the hallmarks of this system – this is one of the promises of OpenTelemetry.


In addition, you also get complete visibility across all of your systems. OpenTelemetry is designed to work with a wide variety of programming languages, frameworks, and library formats.

Because of the standard instrumentation, you will have the ability to reliably get rid of blind spots and data silos in your observability.


OpenTelemetry is not tied to any vendor. It doesn’t require a specific technology stack. It has no dependencies on an operating system. It’s completely agnostic to the underlying infrastructure. And it allows you to choose which technologies you want to use. That means you have total flexibility over your backend observability.

Emergent technologies

With OpenTelemetry, there's no need to worry about changes as new technologies emerge. Your instrumentation will continue to work even if the underlying platform changes.


Finally, OpenTelemetry makes it easy to get started. You can start collecting telemetry data right away. There's no need to wait for your traditional APM tool to add support. Just download the client library, plug in some configuration options, and start sending telemetry. Unlike traditional APM, OpenTelemetry-supported tools can provide application monitoring with logs and metrics in a single place.

Automatic vs. Manual Instrumentation

You have the option of both automatic and manual instrumentation in OpenTelemetry.

Automatic instrumentation

OpenTelemetry automatic instrumentation is a tool that can be used to automatically generate telemetry data from your application. The generated telemetry data will then be sent to the OpenTelemetry server for storage and further analysis.

This ensures that the OpenTelemetry server is always monitoring your application. In addition, collected telemetry data is stored in the OpenTelemetry database.

Manual instrumentation

The OpenTelemetry Manual Instrumentation tool is a command-line tool that developers can use to manually generate telemetry data from their applications. Developers can use this tool to generate telemetry data when they want to monitor their applications. They can also use this tool to send the generated telemetry data to the OpenTelemetry Server.

Similarities and key differences

To begin with, these tools provide similar features. For example, both tools can collect different types of telemetry data such as traces, counters, gauges, and histograms. In addition, both tools can export these data into various formats such as JSON, CSV, YAML, etc.

However, the way the two perform their tasks is the difference between these two tools. For example, the OpenTelemetry automatic instrumentation uses pre-defined rules to analyze your source code and determine whether your program needs to be instrumented. If so, the instrumentation process starts.

On the other hand, OpenTelemetry manual instrumentation requires you to write custom scripts or programs to create your own instrumentation rules. The instrumentation engine then executes these rules to generate telemetry data.

Which should I use?

That’s up to you. Automatic instrumentation is undoubtedly easier to use and leaves little room for error. However, it means that you cannot control precisely what gets instrumented. It may cause problems if you need to know exactly where your telemetry data comes from. Also, since the automated instrumentation relies heavily on static analysis, it may miss out on certain dynamic aspects of your application.

Manual instrumentation provides more control but takes time to set up. You must first understand the instrumentation requirements of your application before writing any instrumentation rules. Then, once you have written those rules, you must run them against your codebase using the manual instrumentation tool. Next, you must ensure that all the required instrumentation rules exist in your codebase. Finally, you must verify that the instrumentation works correctly.

It's a tough call, dependent on what you want from the instrumentation. Choosing instrumentation can also depend on your time and skills resources. Short on time or skills? Automatic is the answer. In need of a more customized solution? Manual will be the way forward.

Supported Frameworks and Languages

The OpenTelemetry SDK supports 11 programming languages: Java, Go, Python, C#, Ruby, NodeJS, PHP, Swift, Rust, Haskell, and Erlang. Each one has its own specific API.

The OpenTelemetry SDKs allow you to generate telemetry data with the help of the instrumentation engine. They also allow you to integrate OpenTelemetry with existing systems.

API allows you to define and add new instrumentation rules to the instrumentation engine. It also allows you to retrieve the latest version of the instrumentation rules via HTTP requests.

The OpenTelemetry collector receives, processes, and exports telemetry data to various destinations, and then the OpenTelemetry collector uses it. Finally, the OTLP protocol is for shipping the telemetry data.

Best Practices

Once you've decided to go with OpenTelemetry, you should follow some best practices to get the most out of your user experience. Here are three tips:

Use the right versions

In addition to using the correct SDK and API for your programming language, you need to use the correct SDK for your operating system. There are SDKs for Windows, Linux, macOS, Android, iOS, and Raspberry Pi. Ensure you're using the correct and latest versions.

Use semantic attributes

You can use semantic attributes to give meaning to the data collected by your application. These attributes are appended to the telemetry data collected by the SDK and make it easier to understand what's happening in your application.

Focus on service levels

When collecting telemetry data, focus on service levels rather than individual events. For example, don't just record the error message when tracking an error event. Instead, track the context around the error and its impact on the user. If possible, try to collect this information at the request level.


We began by examining what OpenTelemetry is, then proceeded to determine its condition, and finally moved on to investigating its instrumentation. After that, we went over some recommended procedures.

If you're looking for a future-proof advanced monitoring tool, we recommend giving TelemetryHub a try, which is supported by OpenTelemetry. On the other hand, if you're looking to monitor your systems but don't know where to get started, Scout APM is built by developers for developers.

Eric L. Barnes photo

Eric is the creator of Laravel News and has been covering Laravel since 2012.

Filed in:

Laravel Newsletter

Join 40k+ other developers and never miss out on new tips, tutorials, and more.

Laravel Forge

Easily create and manage your servers and deploy your Laravel applications in seconds.

Visit Laravel Forge
Laravel Forge logo

Laravel Forge

Easily create and manage your servers and deploy your Laravel applications in seconds.

Laravel Forge
Tinkerwell logo


The must-have code runner for Laravel developers. Tinker with AI, autocompletion and instant feedback on local and production environments.

No Compromises logo

No Compromises

Joel and Aaron, the two seasoned devs from the No Compromises podcast, are now available to hire for your Laravel project. ⬧ Flat rate of $7500/mo. ⬧ No lengthy sales process. ⬧ No contracts. ⬧ 100% money back guarantee.

No Compromises
Kirschbaum logo


Providing innovation and stability to ensure your web application succeeds.

Shift logo


Running an old Laravel version? Instant, automated Laravel upgrades and code modernization to keep your applications fresh.

Bacancy logo


Supercharge your project with a seasoned Laravel developer with 4-6 years of experience for just $2500/month. Get 160 hours of dedicated expertise & a risk-free 15-day trial. Schedule a call now!

Lucky Media logo

Lucky Media

Bespoke software solutions built for your business. We ♥ Laravel

Lucky Media
Lunar: Laravel E-Commerce logo

Lunar: Laravel E-Commerce

E-Commerce for Laravel. An open-source package that brings the power of modern headless e-commerce functionality to Laravel.

Lunar: Laravel E-Commerce
LaraJobs logo


The official Laravel job board

Larafast: Laravel SaaS Starter Kit logo

Larafast: Laravel SaaS Starter Kit

Larafast is a Laravel SaaS Starter Kit with ready-to-go features for Payments, Auth, Admin, Blog, SEO, and beautiful themes. Available with Vue and Livewire stacks.

Larafast: Laravel SaaS Starter Kit
SaaSykit: Laravel SaaS Starter Kit logo

SaaSykit: Laravel SaaS Starter Kit

SaaSykit is a Laravel SaaS Starter Kit that comes with all features required to run a modern SaaS. Payments, Beautiful Checkout, Admin Panel, User dashboard, Auth, Ready Components, Stats, Blog, Docs and more.

SaaSykit: Laravel SaaS Starter Kit
Rector logo


Your partner for seamless Laravel upgrades, cutting costs, and accelerating innovation for successful companies


The latest

View all →
New Proposed Array Find Functions in PHP 8.4 image

New Proposed Array Find Functions in PHP 8.4

Read article
Laracon AU 2024 tickets are now on sale image

Laracon AU 2024 tickets are now on sale

Read article
Dash UI is a Laravel Blade Component Library Inspired by Shopify Polaris image

Dash UI is a Laravel Blade Component Library Inspired by Shopify Polaris

Read article
A Look at What's Coming to PHP 8.4 image

A Look at What's Coming to PHP 8.4

Read article
Is class instantiation without extra parenthesis coming to PHP 8.4? image

Is class instantiation without extra parenthesis coming to PHP 8.4?

Read article
Validation Errors Card for Laravel Pulse image

Validation Errors Card for Laravel Pulse

Read article