What is the OpenTelemetry Collector?

The OpenTelemetry Collector is a separate service (container or process) that receives telemetry data and routes it to one or more backends. It supports OTLP via gRPC and HTTP and runs pipelines of receivers, processors, and exporters.

Why put a Collector between the router and the backend?

Three reasons. Multi-destination export: send the same data to many backends without duplicating exporters per service. Centralized credential management: keep backend tokens in one place. Data processing: batch, transform, or filter signals before they leave the network.

Which protocols does the Collector use?

OTLP over gRPC on port 4317 and OTLP over HTTP on port 4318. The router can export over either; the Collector forwards using the protocol each backend needs.

How does the batch processor work?

The batch processor groups signals together before export. Default settings are a timeout of 1s and a send_batch_size of 1024. Both are configurable per pipeline.

Does the Collector add latency?

No measurable latency for normal traffic. The Collector is designed for high throughput, and batch processing actually reduces overall network overhead by reducing the number of outbound requests.

Can I use a custom Collector build?

Yes. The OpenTelemetry project supports custom Collector builds with only the components you need. See the OpenTelemetry custom-collector documentation for the procedure.

OpenTelemetry Collector for Cosmo Router | Cosmo by WunderGraph

Q: What is the endpoint for Cosmo Cloud's OTLP receiver?

https://cosmo-otel.wundergraph.com:443. Add an Authorization header with your Cosmo token in the Collector exporter configuration.

The problem

Per-application exporters do not scale

Every backend you add means another exporter in every service. Every credential rotation means a deploy. Every protocol difference means custom code.

Per-app exporters multiply credentials

Configuring exporters in every service means storing tokens, certificates, and endpoints in every deployment. Each new backend is another change rolled across every app.

Some backends need protocol translation

Different backends speak slightly different OTLP dialects or expect specific header conventions. Handling that in application code adds drift.

High-volume telemetry needs batching

Without batching, each signal becomes its own outbound request. That works in development; it does not work under production load.

Our solution

The Collector handles fan-out, you handle one config

The router targets a single OTLP endpoint. The Collector receives, processes, and forwards. Add or remove backends by editing the Collector configuration; application configuration does not change.

How the pipeline runs

Deploy an OpenTelemetry Collector (container or process) between the router and your backends.
The Collector receives OTLP over gRPC (port 4317) or HTTP (port 4318).
The router exports to one Collector endpoint instead of each backend directly.
Pipelines route data through receivers, processors, and exporters.
A batch processor groups data before export, reducing request count and bandwidth.
Exporters fan out to Cosmo Cloud, Jaeger, Prometheus, Datadog, or any OTEL-compatible backend at once.

One application config. Any number of backends.

OTEL Collector

Before & After

Before Cosmo	With Cosmo
Exporter credentials duplicated in every service	One router OTLP endpoint; tokens live in the Collector
Some backends need protocol or format translation	Collector processors handle batching and conversion centrally
High-volume telemetry overwhelms downstream APIs	Batching and sampling at the Collector before export
Adding a backend means redeploying applications	Edit Collector exporters only; router config unchanged

Credentials

Centralized credential management

Tokens for Cosmo Cloud, Datadog, and any other backend live in the Collector. Applications keep one local endpoint and never carry production credentials.

How the OTEL Collector integrates with Cosmo Router

01

OTLP gRPC :4317 · HTTP :4318

Receive

The Collector listens for OTLP on gRPC port 4317 and HTTP port 4318. The router exports to a single endpoint and stops worrying about backend protocols.

02

Batch · 1s timeout, 1024 size.

Process

A batch processor groups signals before export. Default timeout 1s, default batch size 1024. Reduce outbound requests and bandwidth without changing application code.

03

One place for backend credentials.

Authenticate

Credentials for each backend live in the Collector. Rotate a token in one place, push, done. Applications keep their single local endpoint.

04

One Collector, any number of backends.

Fan out

Exporters target Cosmo Cloud, Jaeger, Prometheus, Datadog, and any OTEL-compatible backend. Each pipeline can mix and match receivers, processors, and exporters.

Telemetry controls

Pipelines, auth, and fan-out

Receivers, processors, and exporters: credentials stay in the Collector, not in app config.

OTLP receivers

gRPC on 4317 and HTTP on 4318. The router can send to either; pick the one your network favors.

Batch processor

Default timeout 1s, default send_batch_size 1024. Both are configurable per pipeline.

Cosmo Cloud endpoint

https://cosmo-otel.wundergraph.com:443. Add an Authorization header with your Cosmo token in the Collector exporter config.

Custom builds

Custom Collector builds are available for specific deployment needs. See the OpenTelemetry custom-collector docs for the build procedure.

Centralize telemetry export

Point the router at one Collector endpoint. Fan out to every backend from Collector config.

Start Free Read the Docs

Route every telemetry signal through one OpenTelemetry Collector