OpenTelemetry is becoming a common standard for telemetry in distributed systems. What makes it useful? Let’s look at the project and its main ideas.
What is OpenTelemetry?
OpenTelemetry, often shortened to OTel, is an open-source framework that standardizes how applications collect and manage telemetry data. It grew out of the OpenCensus and OpenTracing projects and is now part of the CNCF ecosystem.
Its goal is to provide standard APIs, SDKs, and tools for collecting telemetry independently of the vendor that stores or displays it.
Traces, metrics, and logs
OpenTelemetry works with three core telemetry signals:
- Traces follow a request through services in a distributed system.
- Metrics record numerical measurements such as counters, gauges, and histograms.
- Logs record individual events in the system.
Related concepts include Baggage, metadata propagated with a request, and Profiles, which help analyze where code spends its time.
Why is OpenTelemetry useful?
1. Vendor neutrality
Before OpenTelemetry, monitoring products often required their own APIs or SDKs. Switching providers could mean changing application code. With OpenTelemetry, you can instrument an application once and send its telemetry to different compatible backends.
2. Standardization
OpenTelemetry defines semantic conventions for attributes and measurement names. These help keep telemetry consistent across programming languages and environments.
3. A connected view
Traces, metrics, and logs can be correlated. Together, they give a clearer picture of a system’s behavior and performance than isolated signals.
4. Broad adoption
OpenTelemetry has support across many languages, frameworks, and observability products, making it a practical choice for teams that use more than one tool.
Architecture at a glance
The main building blocks are:
- API: interfaces used to instrument code.
- SDK: implementations that process and export telemetry.
- Collector: a component that receives, processes, and exports telemetry.
- Instrumentation libraries: integrations that collect data from common frameworks and libraries.
Who should use OpenTelemetry?
It is particularly helpful when you:
- Run a microservices architecture.
- Want to change a monitoring provider without rewriting instrumentation.
- Need consistent telemetry across teams or projects.
- Want to correlate different telemetry signals.
A practical example
Imagine an e-commerce application whose checkout pages suddenly become slow. Without correlated telemetry, you might inspect application logs, server metrics, the database, and payment services separately. You would then have to reconstruct the sequence of events yourself.
With OpenTelemetry:
- A trace shows the entire request path and reveals a delay in a fraud-check service.
- Related metrics show that this service is under increased load.
- Its logs, linked to the same trace, reveal repeated attempts to connect to a database.
The connected view makes the investigation more focused and helps you find the cause faster.
Conclusion
OpenTelemetry changes how teams collect and use telemetry. Its vendor-neutral approach and broad ecosystem make it useful for building observable systems.
In the next article of the series, we will look more closely at telemetry signals and how a single user request can produce related traces, metrics, and logs.
Want to try OpenTelemetry in .NET? See the step-by-step .NET tutorial (in Italian).