Is OpenTelemetry supported natively in Cosmo Router?

Yes. The Cosmo Router uses the OpenTelemetry Go SDK to emit traces and metrics. No additional agent or instrumentation library is required.

Which transport protocols does the OTEL exporter use?

The router exports OTLP over HTTP or gRPC. Configure the protocol per exporter; multiple exporters can run side-by-side with different endpoints.

Can I send telemetry to multiple backends at once?

Yes. Define multiple exporters in the router configuration. The same traces and metrics can land in Cosmo Cloud and another OTEL-compatible backend such as Datadog or Jaeger in the same request lifecycle.

What propagation formats are supported?

W3C Trace Context is the default. Jaeger, B3, and Baggage propagation are available as options for compatibility with existing tracing stacks.

How do I add a custom attribute to every span?

Use resource attributes for static service-level values and dynamic attributes for request-scoped values. Dynamic attributes can be pulled from request headers or computed with template expressions. Custom attributes require Cosmo Router 0.92.0 or later.

How does the router prevent metric cardinality explosion?

A default cardinality limit of 2000 unique combinations per metric is built in. Once the limit is reached, further datapoints are stored without attributes rather than dropped. You can also remove specific high-cardinality labels or metrics entirely with regex-based exclusion patterns.

What is the default OTEL export interval?

The default export interval is 15 seconds. It is configurable per metric pipeline if you need to push or pull data more or less aggressively.

OpenTelemetry for Federated GraphQL | Cosmo by WunderGraph

The problem

GraphQL observability is hard to build and harder to maintain

Federated GraphQL needs traces and metrics that carry operation, subgraph, and client context. Generic HTTP telemetry does not.

Custom GraphQL instrumentation is its own product to maintain

Teams need traces and metrics for federated GraphQL, but rolling their own spans and label schemes ends in drift, gaps, and bespoke exporters in every service.

One backend is rarely the whole story

Production observability often spans GraphQL-specific analytics in one platform and company-wide dashboards in another. Configuring two exporters per service multiplies surface area.

High-cardinality labels break the monitoring stack

Without exclusion patterns or a cardinality limit, GraphQL operation labels can overwhelm metrics backends. Teams strip the dimensions that made the data useful in the first place.

Our solution

OpenTelemetry, built into the router

The router emits OTLP traces and metrics through the OpenTelemetry Go SDK. Configure exporters in router YAML. Enrich signals with attributes from headers or expressions. Control cardinality with built-in limits and regex exclusions.

What happens on every request

The Cosmo Router uses the OpenTelemetry Go SDK to instrument every GraphQL operation.
Traces capture parsing, validation, planning, and execution across each subgraph; metrics follow the R.E.D. method.
Data is exported over OTLP (HTTP or gRPC) to any OTEL-compatible backend.
Multiple exporters can run side-by-side, so the same telemetry can land in Cosmo Cloud, Datadog, Jaeger, and more at once.
W3C Trace Context propagates by default; Jaeger, B3, and Baggage propagation are available as options.
Static resource attributes and dynamic attributes from request headers or expressions enrich every signal.

One router, one config, every OTEL-compatible backend.

OpenTelemetry

Before & After

Before Cosmo	With Cosmo
Custom instrumentation and exporters in every service	Native OTEL Go SDK in the router, zero application code changes
One backend per service or duplicated exporter config	Multiple OTLP exporters in one router config, side-by-side
GraphQL operation labels overwhelm metrics backends	Built-in cardinality limit (2000) and regex exclusions
Generic HTTP telemetry without federated GraphQL context	Spans for parse, plan, and subgraph execution with GraphQL-aware dimensions

Cardinality controls

How metric cardinality is kept in check

Two layers protect your metrics backend from runaway label growth:

2000 combinations per metric. A built-in default cardinality limit. Once reached, further datapoints are stored without attributes.
Regex exclusions. Remove specific labels or whole metrics by pattern.

Configure once in the router; cardinality stays bounded for every exporter downstream.

How OpenTelemetry works in Cosmo Router

01

Zero-code OTEL spans for federated traffic.

Instrument

The router auto-instruments every GraphQL operation with the OpenTelemetry Go SDK. Spans cover parsing, validation, planning, and subgraph execution. No application code changes.

02

One router, many backends, no per-app exporter.

Export

Configure HTTP or gRPC exporters in the router config. Multiple exporters run side-by-side, so the same data can land in Cosmo Cloud, Datadog, Jaeger, and other OTEL-compatible backends at once.

03

Custom attributes from headers and expressions.

Enrich

Static resource attributes identify the service; dynamic attributes pull from request headers or expressions. Add environment, region, or client version without touching application code.

04

2000-combination cap; excess stored without labels.

Control

A default cardinality limit of 2000 unique combinations per metric bounds label growth. Once the limit is reached, further datapoints are stored without attributes. Regex exclusions remove specific labels or metrics you do not want to ship.

Examples

OTLP export to Cosmo Cloud

A single telemetry block configures traces and metrics. Add exporters explicitly, or omit them to use the Cosmo Cloud default.

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

Full exporter and attribute reference in the OpenTelemetry documentation.

Telemetry controls

Transport, propagation, and export tuning

Configure protocol, trace propagation, attributes, and export intervals per pipeline, all in router YAML.

Transport

OTLP over HTTP or gRPC. Pick the transport per exporter. Use HTTP for backends behind standard reverse proxies and gRPC for high-throughput pipelines.

Propagation

W3C Trace Context propagates by default. Jaeger, B3, and Baggage are available as options for compatibility with existing tracing stacks.

Attributes

Static resource attributes identify the service. Dynamic attributes pull from request headers or expressions. Custom attributes require Cosmo Router 0.92.0 or later.

Export interval

Metrics export at a default interval of 15 seconds. Configurable per pipeline if you need to push or pull data more or less aggressively.

Ship OTEL from the router, not every service

One telemetry block, multiple exporters, GraphQL-aware spans, configured once in router YAML.

Start Free Read the Docs

Ship federated GraphQL telemetry to any OpenTelemetry backend