⚙️ OpenTelemetry Collector’s Hidden Helpers: Key Components Outside the Pipeline

Sep 25, 2026

—

If you’ve used the OpenTelemetry (OTel) Collector, you’re probably familiar with the concept of a Pipeline. It’s the core flow that defines how data comes in (Receivers), how it’s processed (Processors), and where it goes out (Exporters). 🚀

However, if you look closely at the Collector’s configuration file, you’ll find other important elements that operate independently of the pipeline. While they don’t directly participate in the data flow, they play an essential role in extending the Collector’s functionality and enhancing its stability.

Today, we’ll delve into these components that are not part of the pipeline but provide powerful capabilities to the Collector: Extensions. 🤔

🏭 What are Extensions?

An Extension, as its name suggests, is a component that extends the basic functionality of the OpenTelemetry Collector.

Its most significant characteristic is that it does not belong to the data pipeline. This means it does not directly receive, process, or export collected telemetry data (Traces, Metrics, Logs).

Instead, it provides auxiliary functions necessary for the Collector’s own operation and management. To draw an analogy, if the pipeline is an ‘assembly line’ producing products, extensions are like the ‘security system 🔐’, ‘health monitoring system 🩺’, or ‘power management system ⚡️’ that ensure the assembly line runs smoothly.

✨ Why are Extensions needed? To make the Collector more powerful!

Extensions add the following important functionalities to the Collector:

Health Checks: Provides an endpoint that allows external systems to verify if the Collector is operating normally. This is very useful when configuring livenessProbe or readinessProbe in a Kubernetes environment.
Performance Profiling: Offers capabilities to analyze the Collector’s CPU and memory usage and diagnose bottlenecks. Extensions like pprof can optimize the Collector’s performance.
Authentication & Authorization: Handles authentication (e.g., OAuth2, basic auth) required when a Receiver receives data or an Exporter sends data. It plays a crucial role in strengthening the Collector’s security.
Service Discovery: Can provide functionality to automatically detect monitoring targets in dynamically changing environments (e.g., cloud, container environments).

In this way, extensions transform the Collector from a simple data pipeline into a more robust, secure, and easily manageable operating system.

🛠️ Examples of Actual Extension Components

Let’s look at some extensions commonly used in real-world environments:

health_check: Exposes an HTTP endpoint to check the Collector’s status. It is one of the most basic and essential extensions.
pprof: Activates the pprof functionality, a standard profiling tool for the Go language, allowing you to debug performance issues in the Collector.
zpages: Provides debugging web pages to view real-time Trace and RPC statistics within the Collector.
oauth2client: Handles OAuth2 client authentication required when the Collector, as a client, sends data to external services (e.g., OTLP/HTTP endpoints).
basicauth: Adds basic username/password-based authentication for incoming requests to a Receiver.

📝 Configuration Method: config.yaml

Extensions are defined in the extensions section of the Collector’s configuration file and activated in the service section. You can see that they are completely separated from the pipeline.

# 1. Define the extensions to be used.
extensions:
  health_check:
    # Provide a health check endpoint at the /health path
  pprof:
    # Provide a pprof endpoint on port 1777
    endpoint: 0.0.0.0:1777
  oauth2client:
    client_id: "my-client-id"
    client_secret: "my-client-secret"
    token_url: "https://example.com/oauth2/token"

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  otlphttp:
    endpoint: "https://api.example.com/v1/traces"
    # Authenticate using the oauth2client extension
    auth:
      authenticator: oauth2client

# 2. Specify the extensions to be enabled at the service level.
service:
  extensions: [health_check, pprof, oauth2client] # Add the list of extensions to enable here
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlphttp]

As shown in the example above, after defining the detailed settings for each extension in the extensions block, you activate them by adding their names to the service.extensions array. You can also see the otlphttp exporter using the oauth2client extension through the auth setting.

Wrapping Up

The OpenTelemetry Collector’s pipeline is like the heart that defines the data flow. However, Extensions are essential devices that help that heart beat stably, securely, and efficiently. 🌟

If you need Collector status monitoring, performance tuning, or enhanced security, be sure to explore these powerful ‘extension’ features beyond the pipeline. They will elevate your Observability environment to a whole new level!