Skip to content

Beginner2 min read

OpenTelemetry, step by step: who gains what?

The journey of an OpenTelemetry signal in five steps, from the application to storage, read by six roles: what happens at each step and what the engineer, the manager, the business or leadership gain from it.

For: engineers and SREs · architects · team managers · business and product · finance, risk and compliance · executives and CIOsPrerequisites: None.

Reading mode

An illustrative scenario: in a purchasing meeting, a vendor says its product is “OpenTelemetry compatible”. The architect hears “our data will stay portable”. The CFO hears “we can switch providers without redoing everything”. The vendor’s salesperson simply meant “we can receive your data”. All three understood different things, because they were not looking at the same step.

OpenTelemetry is an open standard that defines how an application produces and ships its operational signals: measurements, request traces, logs. It is often introduced through its components. This diagram introduces it instead as the journey of a letter. You write it (instrumentation, the code that describes what the application does). You put it in an envelope (the SDK, the library that assembles and sends). It travels in a postal format everyone shares (OTLP, the transport protocol). It goes through a sorting center (the Collector). It finally reaches the archive where people come to consult it and make decisions (storage).

At each step, pick a role: the text says what that person gains or has to decide there. The six roles are those of the crossroads on the home page.

Read the journey as

What happens

  1. Follow the journey once as the engineer, with the “Walk through” button. This first pass sets the vocabulary: instrumentation, SDK, OTLP, Collector, storage.
  2. Stay on the Collector step and switch roles. The same component is a pipeline for the engineer, a control point for the architect, an ownership question for the manager, a line on the bill for leadership.
  3. Compare the OTLP step as seen by the architect, then by sales. This is where the misunderstanding in the scenario lives: “OpenTelemetry compatible” does not mean the same thing to the person who designs and to the person who buys or sells.
  4. Look for the step where your own words enter the data. For the business, it is the first one, when you decide how to name a customer, an order or a journey. Those words only come back as an answer at the last one.

OpenTelemetry produces and transports. It does not store or display. Everything before storage belongs to an open standard your organization can own. Everything after it (queries, dashboards, alerts) depends on the chosen tool, unless you take care to keep those items in a repository of your own. That is the question to ask the vendor who claims compatibility.

Going further: OpenTelemetry end to end follows a real span through these steps, the animated Collector pipeline details the fourth one and the OpenTelemetry section follows the changes in the project.