The main components that make up OpenTelemetry

OpenTelemetry is currently made up of several main components:

OpenTelemetry lets you replace the need for vendor-specific SDKs and tools for generating and exporting telemetry data.


Describes the cross-language requirements and expectations for all implementations. Beyond a definition of terms, the specification defines the following:

  • API: Defines data types and operations for generating and correlating tracing, metrics, and logging data.
  • SDK: Defines requirements for a language-specific implementation of the API. Configuration, data processing, and exporting concepts are also defined here.
  • Data: Defines the OpenTelemetry Protocol (OTLP) and vendor-agnostic semantic conventions that a telemetry backend can provide support for.

For more information, see the specification.

Additionally, extensively-commented protobuf interface files for API concepts can be found in the proto repository.


The OpenTelemetry Collector is a vendor-agnostic proxy that can receive, process, and export telemetry data. It supports receiving telemetry data in multiple formats (for example, OTLP, Jaeger, Prometheus, as well as many commercial/proprietary tools) and sending data to one or more backends. It also supports processing and filtering telemetry data before it gets exported. Collector contrib packages bring support for more data formats and vendor backends.

For more information, see Collector.

Language SDKs

OpenTelemetry also has language SDKs that let you use the OpenTelemetry API to generate telemetry data with your language of choice and export that data to a preferred backend. These SDKs also let you incorporate instrumentation libraries for common libraries and frameworks that you can use to connect to manual instrumentation in your application.

For more information, see Instrumenting.

Instrumentation Libraries

OpenTelemetry supports a broad number of components that generate relevant telemetry data from popular libraries and frameworks for supported languages. For example, inbound and outbound HTTP requests from an HTTP library will generate data about those requests.

It is a long-term goal that popular libraries are authored to be observable out of the box, such that pulling in a separate component is not required.

For more information, see Instrumenting Libraries.

Automatic Instrumentation

If applicable a language specific implementation of OpenTelemetry will provide a way to instrument your application without touching your source code. While the underlying mechanism depends on the language, at a minimum this will add the OpenTelemetry API and SDK capabilities to your application. Additionally they may add a set of Instrumentation Libraries and exporter dependencies.

For more information, see Instrumenting.

K8s operator

The OpenTelemetry Operator is an implementation of a Kubernetes Operator. The operator manages the OpenTelemetry Collector and auto-instrumentation of the workloads using OpenTelemetry.

For more information, see K8s Operator.