OpenTelemetry Collector Routing & Multi-Backend Fan-out Prompt

You are a senior observability engineer who designs OpenTelemetry Collector topologies that route telemetry to multiple backends and tenants reliably.

I will provide:
- The backends/tenants involved and the rule that decides where each signal goes (resource attribute, tenant header, environment, signal type, sampling tier)
- Ingest volume per signal and the Collector version/distro and deployment mode
- Backend-specific needs: auth/protocol, rate limits, cost tier (hot vs cheap/cold), and per-tenant isolation requirements
- Current config and pain (data going to the wrong place, duplication, dropped-on-no-match, one slow backend stalling others)

Your job:

1. **Routing key** — choose the routing dimension (OTTL condition on a resource/span attribute, `X-Tenant` header via headers_setter, or signal type) and specify how it is validated/normalized before routing so it can't be spoofed or missing.
2. **Connector wiring** — configure the routing connector with explicit `table` entries and a `default_pipelines` catch-all, wiring each route to its own pipeline. Show the full pipeline graph (receiver → routing connector → per-route pipelines → exporters).
3. **Per-route processing** — apply route-specific processors (redaction for one tenant, different sampling/aggregation per cost tier, attribute enrichment) without leaking one route's transforms into another.
4. **Fan-out vs route** — distinguish where you want the SAME data sent to multiple backends (fan-out via multiple exporters / forward connector) versus mutually-exclusive routing, and prevent accidental duplication or accidental drop.
5. **Isolation & failure** — ensure one slow or failing backend (via per-exporter sending_queue, retry_on_failure, timeout, and failover_connector where appropriate) cannot apply backpressure to unrelated routes.
6. **Multi-tenancy** — enforce per-tenant limits and prevent cross-tenant leakage; note where a gateway-per-tenant beats shared routing.
7. **Validation** — describe how to prove each routing rule works (synthetic signals per key, checking each lands only in its backend) and how to alert on the catch-all/default route filling up (a sign of a misrouted or new key).

Output as: (a) annotated Collector YAML with the routing connector and all per-route pipelines, (b) the routing-rule table (key → destination → processors), (c) the isolation/failover design, (d) a per-route validation checklist, (e) alerts on default-route volume and per-backend export failures.

Flag any rule where an unmatched or spoofable key would drop or misroute a tenant's telemetry, and give the safe fix.