The Future of Observability with OpenTelemetry

Chapter 5. OpenTelemetry: An Architectural Overview

Chapter 2 describes the data model needed to enable automated analysis, and Chapter 4 describes additional requirements to support native OSS instrumentation and empower autonomy among roles (application owner, operator, and responder). This is our conceptual model for modern observability.

In the remainder of this report, we describe a real-world implementation of this new model, OpenTelemetry. This chapter describes all of the individual components that constitute the OpenTelemetry telemetry pipeline. Subsequent chapters will describe the stability guarantees, suggested setups, and deployment strategies for real-world adoption of OpenTelemetry. Further details about the project can be found in the appendixes.

Signals

OpenTelemetry specification is organized into distinct types of telemetry, which we call signals. The primary signal is tracing. Logs and metrics are other examples. Signals are the most fundamental unit of design in OpenTelemetry.

Each additional signal is first developed independently and then integrated with tracing and other relevant signals. This separation allows new, experimental signals to be developed without affecting the compatibility guarantees of signals that have already become stable.

OpenTelemetry is a cross-cutting concern that follows the execution of a transaction as it passes through each library and service. To accomplish this, all signals are built on top of a lower-level context propagation ...