OpenTelemetry Collector for Cosmo Router | Cosmo by WunderGraph - WunderGraph
Route every telemetry signal through one OpenTelemetry Collector
The Cosmo Router exports to a single OTLP endpoint. The Collector handles pipelines, batching, credentials, and protocol translation to every backend you run.
OTLP via gRPC :4317 or HTTP :4318. Standard OpenTelemetry Collector.
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.
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 |
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
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.
Process
A batch processor groups signals before export. Default timeout 1s, default batch size 1024. Reduce outbound requests and bandwidth without changing application code.
Authenticate
Credentials for each backend live in the Collector. Rotate a token in one place, push, done. Applications keep their single local endpoint.
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
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.