Skip to main content
This guide shows how to use a connector in the OpenTelemetry Collector to convert incoming traces into a metric that counts the number of traces (or spans) received. A connector bridges two pipelines: it acts as an exporter on the source pipeline (traces) and as a receiver on the destination pipeline (metrics). The high-level goal: if you send 10 traces to the collector, the connector produces an OpenTelemetry metric with value 10. Why this is useful
  • Create metrics derived from traces (e.g., span counts) without changing instrumented applications.
  • Translate signals inside the collector to power downstream monitoring (Prometheus, remote write, etc.).
  • Implement lightweight transformations or aggregations between pipelines.
Example Collector topology A typical Collector configuration separates traces, metrics, and logs into distinct pipelines:
To convert traces into a span-count metric, add a connector named count. The connector receives traces from the traces pipeline and emits metrics into the metrics pipeline. Prometheus remote write + debug exporters Below is an exporter configuration that sends metrics to Prometheus remote write and also prints output via the debug exporter for visibility:
Wiring the connector into pipelines List the connector as an exporter on the traces pipeline and as a receiver on the metrics pipeline. This dual registration is what lets the connector receive the incoming traces and inject generated metrics into the metrics pipeline.
How the flow works (step-by-step)
  1. Traces enter the traces pipeline via the otlp receiver (OTLP protocol).
  2. The traces pipeline applies processors (attributes, batch) and exports traces to configured exporters (e.g., debug, Jaeger).
  3. Because count is listed as an exporter on the traces pipeline, the connector also receives the trace data there.
  4. The connector implements counting logic and emits a metric (for example, trace.span.count) representing the number of spans observed.
  5. Since count is also listed as a receiver on the metrics pipeline, the generated metric is ingested and processed by the metrics pipeline and forwarded to exporters such as Prometheus remote write and debug.
Quick reference: connector roles
Connector rolePipeline placementPurpose
Exporter (source)service.pipelines.traces.exportersReceives traces from the traces pipeline and performs conversion/aggregation.
Receiver (destination)service.pipelines.metrics.receiversAccepts the emitted metric into the metrics pipeline for further processing/export.
The connector functions as an exporter on the source pipeline and as a receiver on the destination pipeline. That dual role is why it must be listed in both places.
Run a generator that emits a few traces to the OTLP receiver. After the connector processes them, the debug exporter prints the generated metric. Example debug output (abbreviated) showing trace.span.count with value 5:
Best practices and considerations
  • Ensure the connector name is registered both as an exporter for the source pipeline and as a receiver for the destination pipeline; omitting either registration breaks the flow.
  • Use the debug exporter when testing to validate that the generated metrics look correct before sending them to a production backend.
  • Consider aggregation temporality and monotonicity: this example produces a monotonic sum with delta temporality; choose semantics that match your monitoring needs.
  • If you translate high-volume signals into metrics, review resource and cardinality implications to avoid metric explosion.
Be careful to register the connector name both where it should act as an exporter (source pipeline) and where it should act as a receiver (destination pipeline). Omitting either will break the flow.
Further reading and references This example demonstrates a simple, practical use-case: turning traces into a span count metric using a connector. Connectors are flexible and can perform richer transformations or signal translations when needed.

Watch Video