Skip to main content
In this lesson we examine the primary components of the OpenTelemetry ecosystem from a high-level, practical perspective. OpenTelemetry standardizes how telemetry is created, transported, and processed so you can reliably instrument applications and route observability data to backends. Understanding these layers and how they connect helps you design robust observability pipelines for traces, metrics, and logs.

​
Foundational standards (what defines behavior)

These core specifications govern behavior across the OpenTelemetry ecosystem:
  • Specifications — Define expected behavior for APIs and SDKs (API surface, SDK responsibilities, semantics for errors and exceptions).
  • OpenTelemetry Protocol (OTLP) — The standard wire format and transport protocol for sending traces, metrics, and logs.
  • Semantic Conventions — Standard attribute names and conventions for common telemetry types (HTTP spans, database calls, resource attributes).
The image is an overview of OpenTelemetry components, highlighting Specification, OpenTelemetry Protocol (OTLP), and Semantic Conventions as key elements in defining behaviors, standards, and formats for telemetry data.

​
Code-level tooling (how telemetry is created)

This layer includes the libraries and runtime components you use to produce telemetry from applications:
ComponentPurposeWhen to use
APIsLanguage-specific interfaces and helpers to create spans, metrics, and logsWhen writing manual instrumentation or calling SDKs
SDKsImplementations of the API that configure exporters, processors, and batchingIn your application runtime to collect and export telemetry
Instrumentation librariesPre-built integrations for frameworks (e.g., Flask, Express) to minimize code changesTo quickly instrument common frameworks and libraries
Auto-instrumentation agents & wrappersRuntime agents (e.g., Java agent) that instrument apps without source changesFor rapid deployment or when source modification is not desired
The API and SDK are intentionally separated so instrumentation code remains stable while implementations evolve.

​
Processing and routing (the Collector)

Telemetry often needs to be transformed, filtered, or routed before reaching a backend. The central component for this is:
  • OpenTelemetry Collector — A vendor-agnostic, configurable service that receives, processes, and exports telemetry. The Collector supports batching, retries, transformations, filtering, and multi-destination routing, and can act as a gateway between instrumented applications and backends.
The Collector centralizes processing logic (filtering, batching, and exporting), reducing the need for exporter implementations inside each application and enabling consistent telemetry handling across environments.

​
Deployment, distributions, and ecosystem tooling

Beyond the core components, the OpenTelemetry ecosystem includes tools to deploy and extend your observability stack:
  • Operator & deployment tools: OpenTelemetry Operator, Helm charts, and other utilities to run Collector and agents in Kubernetes and cloud environments.
  • Community distributions: Project-specific or vendor-provided distributions that bundle collectors, exporters, and preconfigured pipelines.
  • Integrations & platform tooling: Support for serverless platforms, CI/CD pipelines, and language-specific helpers.
After processing in the Collector (or directly from SDK exporters), telemetry is sent to one or more backends for storage, analysis, and visualization.
The image provides an overview of OpenTelemetry components, showing a flow from software systems through data generation and processing to the backend, with a focus on the OpenTelemetry Collector and supporting tools.

​
How the pieces fit together

  • Left side (producers): Applications instrumented via APIs/SDKs, instrumentation libraries, or auto-instrumentation agents generate telemetry.
  • Middle (processing): The Collector aggregates, processes, and routes telemetry—applying transformations, batching, or sampling as configured.
  • Right side (consumers): Backends and observability platforms receive OTLP or other exporter data for long-term storage, querying, and visualization.
Together, these components form a consistent, extensible pipeline for generating, transporting, and processing observability data across diverse environments.

​
Quick reference & further reading

Watch Video