The OTel Collector Routing Pattern

Different telemetry to different vendors. The routing pattern, the rules, and the audit trail.

The idea

The OpenTelemetry Collector routing pattern is the architecture in which one collector deployment receives telemetry from many sources and routes each piece to the appropriate destination. It replaces the older pattern of point-to-point connections from each application to each backend. The routing pattern centralizes the decision about where telemetry goes and decouples applications from backend choices.

What the pattern provides:

• One collector, many exporters.: The collector configuration declares many exporters: Loki for logs, Prometheus for metrics, Honeycomb for traces, possibly more. Each exporter is configured once; the routing rules direct telemetry to the right one.
• Rules pick which telemetry goes to which exporter.: A piece of telemetry is examined: what type is it (log, metric, trace)? What service is it from? What environment? The routing rules use these attributes to choose the destination.
• Logs to Loki, metrics to Prometheus, traces to Honeycomb.: Different telemetry types go to different specialized backends. Logs to a log store, metrics to a metrics database, traces to a tracing tool. Each backend is good at its specialty; the team uses each for what it does best.
• Per-team or per-service routing.: Different teams may use different backends. Team A's logs go to their Splunk; team B's logs go to a centralized Elastic. The routing rules enforce the team boundaries.
• Backend changes are config changes.: Changing the backend (migrating from one logs platform to another) is a config change in the collector. Applications continue to send telemetry to the collector unchanged; the collector handles the routing.

The routing pattern decouples applications from backend choices. The collector becomes the single integration point.

Routing rules

The routing rules are the heart of the pattern. They translate telemetry attributes into destination decisions. Well-designed rules are explicit, tested, and reviewed; poorly-designed rules accumulate complexity and produce surprising routing.

• By service tag.: The service tag identifies the source service. Rules can route based on service: payment-service to one backend, billing-service to another. The tag-based routing aligns with team ownership.
• By environment.: Production telemetry might go to a paid tier with longer retention; non-production might go to a cheaper tier. The environment tag determines the routing; the cost matches the value.
• By customer tier.: Some teams route customer telemetry differently based on customer tier: enterprise customers get high-resolution metrics; free customers get sampled. The routing pattern supports this segmentation.
• Rules are config.: The routing rules are part of the collector configuration. The config is version-controlled, reviewed, tested. Changes to routing rules go through the same process as any other config change.
• Reviewed and tested like any other config.: A new rule that routes telemetry incorrectly produces visibility gaps or cost surprises. Testing in non-production catches misrouting; review catches policy issues. The discipline matches the impact.

The rules are the artifact that makes the routing pattern usable. Without good rules, the pattern is theory.

Audit

Routing rules drift over time. New rules are added; old rules become obsolete; some rules never matched anything to begin with. The audit layer keeps the rule set healthy.

• Per-rule: how much telemetry does it route.: The collector's metrics expose per-rule routing volume. Rules that route significant volume are active and important. Rules that route nothing are dead and can be removed.
• Surfaces dead rules.: Dead rules are noise in the configuration. They make the config harder to read; they can hide active rules in clutter. The audit identifies them; the cleanup removes them.
• Quarterly cleanup.: Once per quarter, the team reviews routing rules. Dead rules are removed; active rules are confirmed to be doing what they should; new patterns suggest new rules. The discipline keeps the configuration current.
• Rules accumulate.: Without periodic cleanup, rules accumulate. New requirements add new rules; old requirements never trigger removal. The configuration grows; complexity grows; the operational burden grows.
• Pruning is required.: The pruning is mechanical: identify dead rules, confirm with stakeholders, remove. The cost is small; the benefit is sustainable configuration health.

OTel collector routing pattern is one of the high-leverage observability disciplines that decouples applications from backend choices and centralizes telemetry routing decisions. Nova AI Ops integrates with collector telemetry, surfaces routing trends and anomalies, and produces the per-rule visibility that the observability team uses to keep the configuration healthy.