140 lines
5.7 KiB
Markdown
140 lines
5.7 KiB
Markdown
---
|
|
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/).
|