Hey there 👋

Once you get why observability is so crucial, the next question is usually:

how do we actually implement it in a clean, modern way without getting locked into a specific vendor?

This is exactly where OpenTelemetry steps in.

If observability is the approach to understanding your system, then OpenTelemetry is one of the technical foundations that helps us make that approach a reality in actual apps.

What is OpenTelemetry?

OpenTelemetry, often just called OTel, is an open standard for generating, collecting, and exporting telemetry data from your applications.

This telemetry data includes:

  • traces
  • metrics
  • logs

The goal is to let apps send observability data using a more consistent format and approach, without heavily relying on a single vendor.

In other words, OpenTelemetry helps engineers instrument their apps in a way that's more portable and future-friendly.

Why Do We Need OpenTelemetry?

Before standard approaches like OpenTelemetry came along, observability teams faced issues like:

  • every vendor had their own agents and formats
  • observability implementations became inconsistent
  • migrating between vendors was a massive headache
  • app instrumentation often had to be rewritten when switching tools

For example, a team might start with one observability backend, then a few months later decide to try another platform. Without a solid standard, a change like that could mean a ton of rework on the application side.

OpenTelemetry is here to ease that pain.

Telemetry Data: What Are We Actually Collecting?

To make things clearer, let's look at the three main types of data usually discussed in modern observability.

1. Traces

Traces are used to follow a single request's journey as it passes through multiple components in a system.

For example:

  • request hits the API gateway
  • gets passed to the auth service
  • gets passed to the user service
  • user service queries the database
  • response goes back to the client

With a trace, we can see that request's flow end-to-end.

2. Metrics

Metrics are numbers that describe the system's condition over time.

For example:

  • latency
  • throughput
  • error rates
  • CPU usage
  • memory usage

Metrics are super useful for alerting, trend analysis, and monitoring dashboards.

3. Logs

Logs are detailed records of events happening inside the system.

For example:

  • request received
  • invalid token
  • query failed
  • panic recovered
  • background job finished

In practice, logs, metrics, and traces all complement each other.

Is OpenTelemetry a Tool or a Standard?

A lot of people new to observability think OpenTelemetry is a dashboard or a UI app. It's actually not.

OpenTelemetry isn't a visualization tool like Grafana, and it's not a tracing UI like Jaeger.

OpenTelemetry is better understood as a:

  • standard
  • API
  • SDK
  • instrumentation ecosystem

So, OpenTelemetry helps an app generate and send telemetry data.
To actually store and display that data, we usually still need another observability backend.

Core Components of OpenTelemetry

To make it easier to grasp, here are a few key components in the OpenTelemetry ecosystem.

API

The API is the interface developers use when instrumenting their code.

For instance, when we want to create a trace or a span in our code, we interact with this API.

SDK

The SDK handles the technical implementation of that telemetry data.

This is usually where the logic lives for things like:

  • how spans are created
  • how data is collected
  • how sampling is done
  • how data is exported

Instrumentation

Instrumentation is the process of adding observability capabilities to an app.

It can be done in two ways:

  • manual instrumentation Developers add spans, events, or attributes directly in the code.

  • automatic instrumentation Specific libraries or frameworks are instrumented automatically.

Exporter

An Exporter is responsible for sending telemetry data to a specific destination.

For example, trace data can be exported to a tracing backend or a collector.

Collector

The OpenTelemetry Collector is a separate component that can receive, process, and then forward telemetry data to various backends.

The Collector is often used so that the app doesn't have to talk directly to multiple observability systems at once.

How Does the Flow Work?

Simply put, the OpenTelemetry workflow looks something like this:

  1. app generates telemetry data
  2. data is processed by the OpenTelemetry SDK
  3. data is sent via an exporter or collector
  4. the observability backend receives and displays the data

The mental model goes like this:

Application → OpenTelemetry → Collector / Exporter → Observability Backend

The backend can vary depending on your needs. The important part is that the app is already instrumented using a more standardized approach.

Why is OpenTelemetry Becoming So Important?

There are a few reasons why OpenTelemetry is getting more relevant, especially for backend engineers and SRE teams.

1. Vendor-neutral

OpenTelemetry isn't built to lock users into one specific platform. This is huge for avoiding vendor lock-in.

2. Consistent instrumentation

With a standardized approach, instrumentation across different services and languages becomes way more consistent.

3. Great for modern architectures

In systems made up of lots of services, containers, and different runtimes, a consistent standard is a lifesaver.

4. Easier to scale

As a system grows, observability needs usually grow with it. OpenTelemetry provides a flexible foundation for long-term needs.

OpenTelemetry and Distributed Tracing

One of the most popular use cases for OpenTelemetry is distributed tracing.

Why?

Because distributed tracing answers one of the most common problems in modern systems:
how do you track a single request that passes through multiple services?

OpenTelemetry allows each part of the system to add context to that request's journey, so we can see the flow clearly.

Later on, these traces can be sent to a backend like Jaeger to be visualized.

OpenTelemetry vs Jaeger: What's the Difference?

This is a question that pops up all the time.

The short answer is:

  • OpenTelemetry: the standard and tooling for generating and exporting telemetry data.
  • Jaeger: the backend / UI for storing and displaying traces.

So, they aren't direct competitors.
In fact, they're often used together.

OpenTelemetry helps your app create traces.
Jaeger helps you look at those traces.

When Should Engineers Learn OpenTelemetry?

If you work in areas like these, OpenTelemetry is definitely worth learning:

  • backend development
  • microservices
  • platform engineering
  • cloud-native systems
  • SRE
  • performance troubleshooting
  • incident investigation

Even in apps that aren't massive yet, understanding OpenTelemetry early on can help you build a much better observability foundation.

Wrapping Up

OpenTelemetry is a crucial foundation in modern observability.

It's not a dashboard, not a vendor, and not just another tracing library. OpenTelemetry is an open standard that helps apps generate telemetry data more consistently, portably, and ready to be shipped to various observability backends.

If observability helps us understand what's happening inside a system, then OpenTelemetry helps applications speak a more standard language so that understanding becomes possible.

In the next article, we'll dive deeper into distributed tracing: what a trace is, what a span is, and how a request can be tracked from one service to another.

Happy reading 🚀