140 lines
5.6 KiB
Markdown
140 lines
5.6 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)
|
|
- [Sampler](#sampler)
|
|
- [K8s operator](#k8s-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 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](/docs/concepts/instrumentation/libraries/).
|
|
|
|
### Exporters
|
|
|
|
{{% docs/languages/exporters/intro %}}
|
|
|
|
### Zero-Code 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
|
|
[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 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_ATTRIBUTES` 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, 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](/docs/concepts/signals/baggage/).
|
|
|
|
### Sampler
|
|
|
|
Sampling is a process that restricts the amount of traces that are generated by
|
|
a system. The language-specific implementations offer several
|
|
[head samplers](/docs/concepts/sampling/#head-sampling)
|
|
|
|
For more information, see [Sampling](/docs/concepts/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](/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/).
|