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 specifications.


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.

For more information, see Collector.

Language-specific API & SDK implementations

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.


In order to visualize and analyze your telemetry, you will need to export your data to an OpenTelemetry Collector or a backend such as Jaeger, Zipkin, Prometheus or a vendor-specific one.

As part of the language specific implementations you will find many exporters being available. Among them, the OpenTelemetry Protocol (OTLP) exporters provide the best experience for you as an end-user, since it is a general-purpose telemetry data delivery protocol designed in the scope of the OpenTelemetry project.

To learn more about the OTLP protocol, you can read the OTLP Specification.

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.

Resource Detectors

A resource represents the entity producing telemetry as resource attributes. For example, a process producing telemetry that is running in a container on Kubernetes has a Pod name, a namespace, and possibly a deployment name. All three of these attributes can be included in the resource.

The language specific implementations of OpenTelemetry provide resource detection from the environment variable OTEL_RESOURCE_DETECTION and for many common entities, like process runtime, service, host or operating system.

Cross Service Propagators

Propagation is the mechanism that moves data between services and processes. Although not limited to tracing, it is what allows traces to build causal information about a system across services that are arbitrarily distributed across process and network boundaries.

For the vast majority of the use cases, context propagation is done for you through Instrumentation Libraries. But, if needed you can use Propagators yourself to serialize and deserialize cross-cutting concerns such as the context of a span and baggage.


Sampling is a process that restricts the amount of traces that are generated by a system. The language-specific implementations offer several head samplers

For more information, see Sampling.

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.

Function as a Service assets

OpenTelemetry supports various methods of monitoring Function-as-a-Service provided by different cloud vendors The OpenTelemetry community currently provides pre-built Lambda layers able to auto-instrument your application as well as a the option of standalone Collector Lambda layer that can be used when instrumenting applications manually or automatically.

For more information, see Functions as a Service.