The Direct Answer
A B2B command center should use OpenTelemetry routing as a controlled delivery architecture, not merely as a mechanism for copying data between systems. The recommended pattern places one or more OpenTelemetry Collectors at the edge, routes telemetry by tenant, environment, signal, service, and policy, and sends each class of data to the least expensive destination that meets its retention and investigation requirements. A simple production baseline is one regional Collector deployment per cloud region, one tenant ID on every resource, and separate pipelines for metrics, traces, and logs.
Also worth reading: How Do Teams Set Up OpenTelemetry Tail Sampling Without Losing Important Traces? · What Is a B2B Command Center for Multi-Team Operations? · What Command Center ROI Benchmarks Should B2B SaaS Leaders Expect in 2026?
For a leadership platform serving multiple operating teams, the most useful rule is to keep observability data logically separate from customer operating records. OpenTelemetry data should normally flow directly from customer environments into an isolated telemetry plane, while the command-center application receives summarized operational indicators through a controlled interface. This reduces exposure of raw traces and logs, prevents one noisy team from degrading another team’s telemetry, and allows the product to enforce different storage, sampling, and access policies.
As of 27 September 2026, teams should not assume that one universal collector configuration fits every environment. Cloud-native platforms may justify a fully managed ingestion service, while enterprises with data residency, custom processors, or disconnected environments still need a self-managed Collector or gateway. The decisive issue is control over routing boundaries, cost attribution, failure behavior, and auditability—not collector branding.
How OTel Routing Architecture Works
OpenTelemetry instrumentation generates metrics, traces, and logs through APIs and language-specific libraries. Those signals leave an application through configured protocol exporters, usually OTLP over gRPC or HTTP, and enter an OpenTelemetry Collector or another compatible gateway. The Collector is a vendor-neutral telemetry pipeline that can receive, process, batch, filter, transform, and export data; routing is one processing responsibility within that pipeline.
A production design commonly separates receivers, processors, and exporters. Receivers accept OTLP or another supported format. Processors establish tenant and environment metadata, redact sensitive fields, add resource attributes, apply sampling, batch records, and make routing decisions. Exporters then send each pipeline to a particular backend. This separation is important because a Collector route such as tenant/acme -> pipeline acme routes an internal pipeline to an exporter group, but it does not automatically establish identity, quota isolation, or trustworthy billing.
Tenant identification deserves particular care. The receiving service must derive tenant identity from authenticated metadata, a signed envelope, or a trusted resource attribute rather than trusting an arbitrary request header. In managed multi-tenant systems, use a gateway to terminate customer credentials, verify the customer, and generate an internal tenant attribute. At scale, teams should also attach a stable service.name, deployment environment, region, data classification, cost center, and schema version before any data is persisted.
The command center should consume an intentionally narrow model. It might need service health, queue depth, incident totals, task latency, and business-process status, but it generally does not need every HTTP header, prompt token, stack trace, or customer log record. Aggregating telemetry at the boundary can reduce both egress charges and downstream query cost, while preserving enough evidence for leadership reporting. Raw telemetry can remain in the customer’s approved observability stack, with only approved summaries entering the SaaS control plane.
A Practical Multi-Team Design
The first step is to inventory telemetry by purpose rather than by volume. Classify each signal as immediate operational telemetry, security telemetry, compliance evidence, debugging data, or leadership reporting data. These classes have different requirements: a dashboard may tolerate 15-minute metric resolution, while a payment investigation may require traces for 30 days and a security event may require immutable retention. Treating all three OpenTelemetry signals as one product is a frequent design error.
A sensible starting topology uses a regional edge, a processing tier, and policy-specific destinations. The edge accepts OTLP and rejects unknown customers or malformed payloads. The processing tier enriches records, enforces payload limits, samples high-volume traces, and separates internal telemetry from customer telemetry. Leadership reporting can use minute-level metrics and aggregate records, debugging traces can be retained for 7 to 30 days, and compliance records can follow a 1-year policy when the contract requires it.
For a 24x7 command center, a practical incident threshold is to retain every error trace for 30 days, sample successful traces at 1% to 5%, and sample them up to 100% for 15 minutes around a declared incident. Those figures are operating choices, not OpenTelemetry standards. Teams should adjust them using request volume, incident frequency, storage cost, and contractual requirements. If a service emits 10,000 traces per minute, a 5% baseline sample produces about 500 retained traces per minute before tail-based retention rules are applied.
The product should also distinguish platform telemetry from product telemetry. Internal command-center health signals belong to the SaaS provider’s engineering environment, even if the same OpenTelemetry software runs there. Customer business signals must stay associated with the correct tenant and may be subject to contractual access controls. Mixing those streams into a shared index can create a cross-tenant disclosure risk, so namespace separation and authorization tests should be mandatory before launch.
Routing Options and Trade-Offs
There is no single routing architecture that is best in every case. A managed observability provider reduces collector maintenance and can simplify account-level controls, but it may increase vendor dependence and leave some routing and data-egress decisions outside the team’s control. A self-managed Collector provides stronger configuration control, yet it transfers upgrades, capacity planning, processor reliability, and 24x7 operation to the adopting team.
| Feature | Managed observability platform | Self-managed OpenTelemetry Collector |
|---|---|---|
| Initial setup | Usually faster through automatic agents and integrations | Requires configuration, deployment, credentials, and testing |
| Routing control | Good, but constrained by provider capabilities | Highly configurable across receivers, processors, and exporters |
| Tenant isolation | Commonly available at account or namespace level | Achievable, but must be designed and tested by the operator |
| Operating burden | Provider handles much backend maintenance | Team handles upgrades, capacity, incidents, and security patches |
| Cost profile | Easier to forecast, often higher at sustained volume | Potentially lower variable cost, but labor and redundancy must be included |
| Best fit | Smaller teams and standard cloud estates | Regulated, high-volume, multi-cloud, or specialized estates |
Some teams also consider a message-bus layer between collection and storage. A queue can absorb backend outages and smooth traffic spikes, but it adds delivery semantics, duplicate-processing questions, retention cost, and another component to operate. Use a buffer when peak telemetry can exceed the target backend’s ingestion rate or when network interruptions are common. Do not add Kafka or a comparable service solely to make the architecture look sophisticated; for many workloads, Collector memory and disk buffering are sufficient.
Cost, Pricing, and Budget Controls
OpenTelemetry itself is open source and does not impose a per-event license fee. Cost arises from the managed collector service, computation, networking, storage, queries, log indexing, retention, support, and staff time. On Amazon Bedrock, for example, model inference is metered by tokens and model type, while operational telemetry can be routed to CloudWatch, an external observability vendor, or both. Bedrock cost attribution should connect usage to a customer, team, feature, and model, but it should not force every diagnostic trace into a customer bill unless the contract says so.
For infrastructure budgeting, calculate retained volume before choosing a sampling rate. If a service emits 2 GB per hour, keeps 5% of traces, and runs continuously, the nominal retained trace volume is about 1.8 GB per day before compression and indexing expansion. Retaining that for 30 days implies roughly 54 GB of trace payloads. A managed platform may charge by ingest, indexed volume, active series, or query count, so a 5% sample can still create a large active-series or indexing bill when metric dimensions are poorly designed.
For LLM workloads, separate model telemetry from infrastructure telemetry. Record input tokens, output tokens, cached tokens where available, model ID, region, latency, success status, and attributed tenant. Report estimated monthly cost as a range and reconcile it against the provider invoice; tokenizer behavior, cached input discounts, batch discounts, and regional prices can change effective rates. A useful governance threshold is to alert when one tenant exceeds 120% of its approved monthly budget and to require review at 80%, rather than waiting for a hard billing failure.
The command-center pricing model should not expose OpenTelemetry routing as a hidden usage surcharge. Leadership customers generally need predictable platform pricing, while variable telemetry expenses belong in the provider’s capacity and margin plan. If advanced retention, private connectivity, or dedicated data residency is offered, price it explicitly as an add-on or enterprise tier. Transparent thresholds—such as 30-day detailed traces, 90-day summaries, and 13-month compliance records—are easier to sell and support than vague “unlimited observability” claims.
Common Mistakes and Failure Modes
The most damaging mistake is treating a tenant header as proof of identity. If any customer can send tenant=other_customer, routing becomes a security vulnerability. Terminate authentication at a trusted edge, validate the customer, strip conflicting tenant attributes, and test horizontal-access attempts before accepting production traffic. A second common error is sending all signals to the most capable observability platform by default, which raises cost without guaranteeing better operational decisions.
Another mistake is creating excessive metric cardinality. Adding raw user IDs, request IDs, or full URLs as metric labels can produce millions of active series and overwhelm the backend. Use bounded dimensions such as service, region, status class, and method; keep unique identifiers in logs or traces where they belong. Also avoid duplicating identical telemetry through both metrics and logs unless each representation serves a documented purpose.
Processor ordering must be deliberate. Tenant authentication and metadata validation should occur before any exporter selection. Redaction should happen before data leaves the trusted boundary, and batching should generally be late enough not to defeat tenant-aware behavior. Finally, treat routing configuration as production code: review changes, pin Collector versions, test malformed input, and have a rollback path. A configuration change that sends all logs to an empty bucket can create an apparent monitoring outage even while the applications remain healthy.
A less obvious failure is allowing leadership dashboards to depend on raw trace queries. Detailed traces are valuable for engineers, but a command center should consume precomputed service-level indicators and business-process metrics. Keep dashboard queries bounded, cache repeated results, and record the freshness target, such as 60 seconds for operational status and 15 minutes for historical summaries. This makes product behavior stable when the observability backend is slow or under retention pressure.
When to Act and How to Roll It Out
Act now if the platform already operates multiple teams, tenants, or regulated environments, because routing and attribution become harder to retrofit once customer data is mixed. The trigger is not simply a desire to “modernize telemetry.” Strong triggers include unexplained invoice growth, cross-team alert noise, an inability to prove tenant isolation, a need for regional residency, or incidents where the leadership view disagrees with the engineering view.
A 30-day implementation can be realistic for an existing OpenTelemetry estate. In week 1, inventory signals, owners, retention, regions, and estimated volumes. In week 2, define tenant identity, naming conventions, and routing policies. In week 3, deploy a non-production Collector with separate pipelines and synthetic tests. In week 4, shadow a small set of services, compare routing counts with backend totals, and establish budget alerts. Full migration should wait until rollback, capacity, and access-control tests pass.
Start with 2 to 3 representative services rather than the whole estate. Include one high-volume service, one customer-facing team, and one internal platform service. Compare records accepted, exported, rejected, sampled, and stored; target less than a 1% unexplained discrepancy, and investigate any mismatch greater than 0.5%. Confirm that a deliberately malformed payload is rejected, a revoked credential cannot export data, and a backend outage activates buffering without exhausting memory. Document the expected recovery point and recovery time, which may be 5 to 15 minutes for a simple buffer but can be longer for a large queue.
Review the architecture quarterly. Revisit sampling when traffic changes by more than 50%, when incident volume rises for two consecutive months, or when storage cost exceeds 10% of the relevant platform budget. A quarterly review should also check schema version, Collector release notes, data deletion requests, regional capacity, and whether a team is still exporting a signal that no one queries. Telemetry architecture decays quietly: unused dashboards, orphaned fields, and forgotten routes accumulate faster than formal requirements do.
The Recommended Operating Policy
The definitive policy is to centralize standards while decentralizing destinations. Maintain one organization-wide model for names, required attributes, tenant identity, redaction, and ownership, but allow teams to choose approved backends according to latency, residency, retention, and cost. Route raw telemetry to the system designed for investigation, route aggregates to the command center, and keep detailed customer evidence out of the leadership interface unless explicitly approved.
For most B2B command-center SaaS products, begin with OTLP over gRPC or HTTP to a regional Collector, separate pipelines for metrics, traces, and logs, and a managed queue only when traffic spikes justify it. Use 1% to 5% success-trace sampling as an initial hypothesis, retain errors at 100% for at least 30 days, and revise the policy from evidence. Require tenant-aware budget labels, but keep billing aggregation separate from telemetry transport. This design gives leadership a dependable operational view while preserving engineering control over the underlying observability data.
The important measure is not the number of pipelines or exporters. It is whether the team can answer, within minutes, which customer produced a signal, where it was sent, how much was retained, who could access it, and what it cost. If those answers are explicit and tested, the routing architecture is doing its job. If they are reconstructed from logs or intuition, the system is not yet ready to serve as the operational foundation for multi-team command-center decisions.