Components

OpenTelemetry is currently made up of several main components:

• Specification
• Collector
• Language-specific API & SDK implementations
  • Instrumentation Libraries
  • Exporters
  • Zero-Code Instrumentation
  • Resource Detectors
  • Cross Service Propagators
  • Samplers
• Kubernetes operator
• Function as a Service assets

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

Specification

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.

Collector

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 generate data about those requests.

An aspirational goal of OpenTelemetry is that all popular libraries are built to be observable by default, so that separate dependencies are not required.

For more information, see Instrumenting libraries.

Exporters

Send telemetry to the OpenTelemetry Collector to make sure it’s exported correctly. Using the Collector in production environments is a best practice. To visualize your telemetry, export it to a backend such as Jaeger, Zipkin, Prometheus, or a vendor-specific backend.

The registry contains the list of language specific exporters.

Among exporters, OpenTelemetry Protocol (OTLP) exporters are designed with the OpenTelemetry data model in mind, emitting OTel data without any loss of information. Furthermore, many tools that operate on telemetry data support OTLP (such as Prometheus, Jaeger, and most vendors), providing you with a high degree of flexibility when you need it. To learn more about OTLP, see OTLP Specification.

Zero-code instrumentation

If applicable, a language specific implementation of OpenTelemetry provides a way to instrument your application without touching your source code. While the underlying mechanism depends on the language, zero-code instrumentation adds the OpenTelemetry API and SDK capabilities to your application. Additionally, it might add a set of instrumentation libraries and exporter dependencies.

For more information, see Zero-code instrumentation.

Resource detectors

A resource represents the entity producing telemetry as resource attributes. For example, a process that produces telemetry that is running in a container on Kubernetes has a Pod name, a namespace, and possibly a deployment name. You can include all these attributes in the resource.

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

For more information, see Resources.

Cross-service propagators

Propagation is the mechanism that moves data between services and processes. Although not limited to tracing, propagation 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 happens through instrumentation libraries. If needed, you can use propagators yourself to serialize and deserialize cross-cutting concerns such as the context of a span and baggage.

Samplers

Sampling is a process that restricts the amount of traces that are generated by a system. Each language-specific implementation of OpenTelemetry offers several head samplers.

For more information, see Sampling.

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