Wiki · Concept · Last reviewed June 25, 2026

OpenTelemetry Routing Connector

The OpenTelemetry Routing Connector routes traces, metrics, or logs from one Collector pipeline into other pipelines according to conditions. For AI systems, it turns telemetry routing into a governance surface: which events go to ordinary debugging, restricted audit stores, security review, cost-controlled analytics, or jurisdiction-specific backends.

Category: Concept Published: June 25, 2026 Modified: June 25, 2026 Last reviewed: June 25, 2026 Tags: OpenTelemetry, routing connector, observability, AI agents, telemetry governance

Definition

The Routing Connector is an OpenTelemetry Collector Contrib connector for sending telemetry to specific pipelines. OpenTelemetry documentation defines connectors as components that connect two pipelines, acting as both exporter and receiver. The Routing Connector README says it routes logs, metrics, or traces based on resource attributes to specific pipelines, using OpenTelemetry Transformation Language statements as routing conditions. Its documented stability is alpha for traces, metrics, and logs.

This makes it different from a processor. A processor changes, drops, batches, samples, or enriches telemetry inside one pipeline. A connector sits between pipelines. The Collector configuration documentation says connectors are configured under a connectors section and enabled through pipelines in the service section, not merely by being declared.

How It Works

A routing connector consumes telemetry at the end of one pipeline and emits it at the beginning of one or more downstream pipelines. The routing connector's configuration is primarily OTTL-based. Conditions inspect telemetry context, then send matching data to named pipelines. In practice, this allows one incoming stream to become multiple streams with different processors, exporters, access rules, retention classes, and destinations.

For example, ordinary service traces might go through batching and export to a general observability backend. Incident-class traces might go through OpenTelemetry Redaction Processor rules and then to a restricted security store. High-volume healthy traces might be sampled or dropped. Regional telemetry might be kept in-region. The connector does not itself make those policies good; it gives the pipeline a place to express them.

AI Agent Telemetry

AI Agents produce telemetry with mixed audiences. Developers may need latency, error, model route, token count, and tool status. Safety reviewers may need blocked action traces, escalation events, and approval records. Privacy teams may need proof that raw prompts, private documents, and credentials did not leave a restricted path. Legal or customer-support teams may need a narrow AI Audit Trails record for disputed delegated actions.

A single backend rarely fits all of that. The Routing Connector can help split telemetry by task class, tenant, region, policy label, incident severity, data classification, model gateway, or tool namespace. That matters for agentic systems because the same trace can contain both routine performance data and sensitive evidence about a user's work, account, file, purchase, or support case.

Governance Use

The governance value is explicit separation. If every span goes to the same store, teams are tempted to solve all problems with one retention period, one access model, and one privacy posture. Routing makes different duties visible. A low-risk analytics route can be short-lived and aggregated. A restricted incident route can retain less frequent but more evidentiary traces. A development route can exclude production prompts. A jurisdiction route can keep regulated telemetry inside a required boundary.

The connector is also a change-control object. A new routing condition can redirect sensitive data, bypass a redaction processor, send records to a different vendor, or remove evidence from a review path. It should therefore be reviewed with the same seriousness as authorization policy, model-gateway configuration, and audit-log retention.

Limits

Routing is only as reliable as the attributes and conditions it depends on. If a service fails to set a region, tenant, data-classification label, incident marker, or model route, the connector may send telemetry to the default path. If routing conditions are too broad, sensitive traces may reach general stores. If they are too narrow, critical traces may be lost or hidden from the team that needs them.

There is also an operational limit. Multiple routes create more pipelines to test, monitor, document, and secure. A routing diagram that looks clean can still fail if downstream processors are missing, exporters are misconfigured, or access controls are weaker in one destination than another.

Minimum Record

An AI deployment using the Routing Connector should record the collector distribution and version, connector version, source pipeline, downstream pipelines, OTTL routing conditions, default route, resource attributes used, required labels, processor order after routing, exporter destinations, retention class, access-control owner, region or vendor boundary, and tests for each route. It should also record which route handles incidents, appeals, legal holds, and deleted or restricted data.

Source Discipline

Use OpenTelemetry project documentation and the Collector Contrib README for connector behavior, configuration, and stability claims. Use vendor documentation only for vendor-specific distribution support or backend behavior. Treat routing screenshots as implementation evidence, not as proof that telemetry governance is working.

Spiralist Reading

The Routing Connector is a switchyard for machine memory. It decides where the trace goes next, who can see it, how long it lives, and which future investigation can find it. In agent systems, that switchyard is moral infrastructure. It can keep private traces out of general view, or it can quietly send intimate work into the wrong archive. The discipline is to make every route named, justified, tested, and reviewable.

Sources

Return to Wiki