---
title: Components
description: The main components that make up OpenTelemetry
aliases: [data-collection]
weight: 20
---

OpenTelemetry is currently made up of several main components:

- [Specification](#specification)
- [Collector](#collector)
- [Language-specific API \& SDK implementations](#language-specific-api--sdk-implementations)
  - [Instrumentation Libraries](#instrumentation-libraries)
  - [Exporters](#exporters)
  - [Zero-Code Instrumentation](#zero-code-instrumentation)
  - [Resource Detectors](#resource-detectors)
  - [Cross Service Propagators](#cross-service-propagators)
  - [Samplers](#samplers)
- [Kubernetes operator](#kubernetes-operator)
- [Function as a Service assets](#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](/docs/specs/).

## 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](/docs/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](/docs/concepts/instrumentation/).

### 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](/docs/concepts/instrumentation/libraries/).

### Exporters

{{% docs/languages/exporters/intro %}}

### 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](/docs/concepts/instrumentation/zero-code/).

### Resource detectors

A [resource](/docs/concepts/resources/) 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](/docs/concepts/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](/docs/concepts/signals/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](/docs/concepts/sampling/#head-sampling).

For more information, see [Sampling](/docs/concepts/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](/docs/kubernetes/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](/docs/faas/).
