Skip to main content
Connectors in the OpenTelemetry Collector enable cross-pipeline telemetry flows and lightweight transformations without changing application SDKs. This article explains what connectors are, where they sit in Collector pipelines, why they’re useful, and how to configure common connectors: count, spanmetrics, servicegraph, routing, forward, sum, and exceptions. Each example uses YAML for the Collector configuration and includes typical use cases and wiring patterns.
The image shows an agenda with four items related to connectors, covering their introduction, placement, usefulness, and configuration.
What is a connector?
  • A connector acts as an exporter on a source pipeline and as a receiver on a target pipeline.
  • This lets the Collector derive new telemetry (for example, metrics from traces) or route/fan out data without changing application or SDK code.
  • Connectors are useful for SRE metrics (RED/SLIs), topology graphs, routing, aggregation, and error extraction.
The image illustrates an OpenTelemetry Collector setup, showing two pipelines—Traces and Metrics—connected by a connector. Each pipeline includes Receivers, Processors, and Exporters.
Connectors bridge pipelines by appearing as an exporter on the source pipeline and as a receiver on the target pipeline. This allows the Collector to derive new telemetry (for example, metrics from spans) without changing application or SDK code.
Connector placement and flow
  • A connector receives telemetry already processed by a pipeline, optionally performs computation (derive metrics, count, sum, build graphs), and emits data into another pipeline for further processing/export.
  • Typical flow: receiver → processors → connector (acts as exporter) → metrics/other pipeline (connector acts as receiver) → exporters.
The image illustrates the placement of connectors within a data pipeline, showing the flow from receivers to processors and exporters, and emphasizing the connector's role in emitting derived metrics.
Common use cases
  • Fan-out / reuse telemetry across multiple pipelines.
  • Derive metrics from traces (RED metrics, SLIs, latency histograms).
  • Build service dependency graphs and detect unexpected edges.
  • Conditionally route telemetry based on attributes.
  • Aggregate counts or sums into time-series for KPIs.
Common connectors
  • spanmetrics — derive latency, error, and rate metrics from spans.
  • servicegraph — build service dependency/topology metrics.
  • routing — OTTL rules to route telemetry to pipelines.
  • count — convert span events/logs into simple counts.
  • sum — aggregate numeric attributes into time-series.
  • forward — merge/split pipelines without transforming telemetry.
  • exceptions — extract exception data for logging/alerting.
The image lists four common connectors: SpanMetrics, ServiceGraph, Routing, and Count, each with a brief description of their functions related to metrics and traces.
Connector comparison (quick reference)
ConnectorPrimary purposeTypical source signalExample outcome
spanmetricsDerive RED metrics, histograms, exemplarsTracesLatency histograms, error rates
servicegraphBuild service dependency graphTracesService-to-service edge metrics
routingRoute/fan-out based on OTTL rulesAny (resource/span/log/metric)Environment-based pipelines
countCount matched eventsSpans / LogsTime-series pulse metrics
sumAggregate numeric attributesSpansKPI time-series (order totals)
forwardMerge/split pipelinesAnyCombined or branched pipelines
exceptionsExtract exception dataTraces (exceptions)Correlated logs with trace/span IDs

​
Count connector (example)

The Count connector converts span events or logs into simple time-series counts based on matching conditions. It operates as an exporter on the traces/logs pipeline and as a receiver on the metrics pipeline. Example: count span events named “prodevent” coming from environment “prod” and emit metrics to the metrics pipeline, which exports to debug:
How it works:
  • Traces arrive via OTLP → processed → exported to count.
  • The connector checks each span event against the conditions.
  • Matches generate a metric my.prod.event.count emitted into the metrics pipeline and exported by debug.
The image is a flowchart illustrating a process for generating pulse metrics using a count connector, with data flowing from a "Spans/Logs Stream" through "conditions" to a "Time Series Output."

​
SpanMetrics connector

SpanMetrics derives SRE-style metrics (rate, errors, latency histograms) and exemplars from spans. It is commonly used to produce RED metrics and latency histograms for Prometheus. Example: receive traces via OTLP, apply spanmetrics with explicit histogram buckets, dimensions, and exemplars, and export to Prometheus:
Use cases:
  • SLIs and RED metrics (requests, error rates, durations).
  • Latency histograms with exemplars for trace-level correlation.
  • Error trend analysis by dimensions (status code, method).

​
ServiceGraph connector

ServiceGraph computes a service dependency graph from trace spans, identifying client→service and service→service edges and generating related metrics to highlight hotspots or unexpected dependencies.
The image is a diagram showing a "ServiceGraph" that maps service dependencies in real time from traces, depicting connections between a client and services A, B, C, and D, highlighting specific issues like "Hotspot" and "Unexpected edge."
Configuration example: route traces through servicegraph and expose dependency metrics to Prometheus:
What it produces:
  • Metrics showing edges and counts between services.
  • Can highlight hotspots and unexpected edges for dependency analysis.

​
Routing connector (OTTL-based routing)

The Routing connector evaluates OTTL (OpenTelemetry Transformation Language) expressions to dispatch telemetry to different pipelines. Use cases include environment isolation, tenant routing, error pipelines, and fan-out. Key options:
  • default_pipelines — where to send unmatched items.
  • match_once — stop after first match (reduce duplication).
  • error_mode — how to handle OTTL evaluation errors.
Example: route traces to traces/prod if resource has env=prod, route error spans (status >= 400) to traces/errors, and use a default pipeline for others:
Example: routing logs from a single filelog receiver that contains multiple environments:
Routing tips:
  • Use match_once to avoid duplicates when you only want one destination.
  • Use default_pipelines to ensure unmatched telemetry still gets processed.
  • Test rules with a small dataset to avoid misrouting production telemetry.

​
Forward connector

The Forward connector is a lightweight bridge that forwards telemetry between pipelines without transformation. It’s useful for merging sources, splitting for multiple downstream destinations, or creating parallel processing branches. Example: merge logs from two receivers into a single merged logs pipeline, and branch traces into sampled vs all:
When to use forward:
  • When you need to combine multiple inputs into one pipeline.
  • When you need to create parallel downstream processing (fan-out).

​
Sum connector

The Sum connector aggregates numeric attributes from spans into time-series sums, optionally grouping by attributes (labels). Useful for business KPIs like revenue, order totals, or counters derived from attributes. Example: sum order totals and discounts from span attributes, grouped by promo.code:
Result:
  • Time-series purchase.order.total and purchase.discount.total containing sums of numeric attributes.
  • Labels from promo.code let you split KPIs by campaign or promotion.

​
Exceptions connector

The Exceptions connector extracts exception information found in spans and converts that data into logs or log-like telemetry including trace/span IDs for correlation. This is valuable for building error-focused pipelines and alerting. Example: send traces through exceptions to produce logs consumed by a logs pipeline:
What to expect:
  • The connector emits structured logs for exceptions that include trace and span IDs.
  • Use these logs for alerting, storage in a log backend, or further enrichment.
Wrap-up Connectors let you transform, route, and enrich telemetry inside the Collector without touching application code. They help you:
  • Produce SRE metrics and SLIs from traces (spanmetrics, count, sum).
  • Build dependency/topology metrics (servicegraph).
  • Route and isolate telemetry (routing, forward).
  • Extract errors and exceptions for dedicated pipelines (exceptions).
Start small, validate outputs in a staging environment, and monitor for duplicate telemetry or overload when enabling multiple connectors that might fan out signals.
Be careful with fan-out and overlapping rules. Multiple connectors or routing rules can cause duplicated metrics/logs if match conditions overlap. Test configurations and use match_once when appropriate.
The image is a slide labeled "Wrap-up" that outlines four key points related to telemetry, metrics, and performance. Each point has a number and highlights functions like connectors, common metrics, and strategic guidelines.
Links and references

Watch Video