Before talking about isolation, we need to understand why anyone shares a telemetry system in the first place.

What a tenant is

A tenant is a group that owns a set of data and expects it to be kept apart from other groups. In a company that sells software to other companies, a tenant is usually a customer. In a large organisation, a tenant might be a product team, a department or a business unit. In a platform team’s view, a tenant can even be an environment such as production or testing. The word is flexible, and the first job in any design is to decide exactly what it means in your setting.

Telemetry is the stream of traces, metrics and logs that systems produce about themselves. When many tenants produce telemetry, there are two simple ways to handle it. You can give every tenant a completely separate monitoring system, or you can let them share one. Separate systems are easy to understand and strongly separated, but they are expensive and slow to manage. A shared system is cheaper and easier to operate as one platform, but it demands careful design so that tenants do not harm or spy on each other.

Why organisations choose to share

Who the stakeholders are

A multi-tenant platform serves several groups of people, and each of them cares about different things. Tenants want their data kept private, their dashboards fast and their bills fair. Platform engineers want a system that is simple to operate and does not wake them up at night. Security teams want clear evidence that data cannot leak. Finance teams want costs they can explain. Legal and compliance teams want proof that obligations about location and retention are met. A good design keeps all five groups in mind from the first day, because each can veto the platform if its needs are ignored.

A shared vocabulary makes the rest of the guide much easier to follow.

An important fact about OpenTelemetry

OpenTelemetry is a set of standards and tools for producing and moving telemetry. It does not, on its own, define a built-in concept of tenancy. There is no single standard switch that says “this data belongs to tenant A and must never mix with tenant B”. Instead, multi-tenancy is something you build from the ordinary parts: attributes that carry identity, authentication that proves identity, processors and connectors that route and shape data, and backends that store data separately. Conventions for naming a tenant attribute also vary, so check the current guidance and choose a name your whole platform will use consistently.

Telemetry has three signals, and tenancy touches each differently

Traces, metrics and logs behave differently, and so do their tenancy problems. Traces are made of spans linked together, so keeping a trace whole matters, and a single trace should never contain spans from two tenants. Metrics are numbers over time grouped into series, so the main danger is the sheer number of series a tenant can create. Logs are text with attributes, so the main danger is sensitive content hiding inside the message. A design that handles one signal well may handle another poorly, so review each signal separately.

Linking signals without leaking across tenants

Users like to jump from a metric spike to a related trace to the logs of one request. This works because the signals share identifiers. In a multi-tenant system, the same tenant label must be present and trusted on all three signals, or a jump from one to another could cross a boundary. Treat the tenant label as part of the identity of every item, and make sure that links and lookups always include it.

Isolation is not one thing. It is a bundle of separate promises, and a design can keep some and break others.

Why the dimensions must be considered separately

It is easy to believe that adding a tenant label to everything solves the whole problem. A label gives you a way to separate data when you query it, which helps with data isolation, but it does nothing for performance. A single noisy tenant can still overwhelm a shared queue even if every item carries a perfect label. Similarly, strong performance limits do nothing to stop someone from reading the wrong data. A serious design looks at each dimension and decides how it will be protected.

Threats that isolation must withstand

It helps to think like an attacker, or like a careless engineer, and list what could go wrong. A tenant might try to read another tenant’s data by guessing identifiers. A tenant might try to impersonate another by copying its label. A tenant might flood the platform on purpose to cause harm, or by accident through a bug. A platform operator might look at data they should not see. A configuration change might accidentally expose data. A shared cache or shared file might hold data from several tenants and return the wrong one. Each of these threats deserves a specific defence.

Every multi-tenant design sits somewhere on a spectrum between full separation and full sharing.

flowchart LR
  subgraph Silo
    A1[Tenant A data] --> CA[Collector A] --> SA[Storage A]
    B1[Tenant B data] --> CB[Collector B] --> SB[Storage B]
  end
  subgraph Pool
    A2[Tenant A data] --> CP[Shared collector]
    B2[Tenant B data] --> CP
    CP --> SP[Shared storage with tenant labels]
  end
        

Choosing a model

The right choice depends on the strength of the guarantees you owe and the money you can spend. A platform serving internal teams that trust each other may happily use a pool. A service holding regulated data for large customers may need silos for the largest of them. Many organisations adopt tiers: a shared pool for small tenants, with dedicated pipelines or storage for the few tenants who need or pay for stronger separation.

Tiering in practice

Most successful platforms define a small number of tiers, rather than negotiating a unique design with every tenant. A basic tier might use the shared pool with modest limits and standard retention. A standard tier might use the shared pool with higher limits and longer retention. A premium tier might use a dedicated pipeline, or even dedicated storage, with strict guarantees. Defining tiers in advance makes the platform easier to explain, price and operate, and it gives tenants a clear path to upgrade as their needs grow.

Whichever tiers you choose, write them down in plain language, including what is promised about data separation, limits, retention, response times and deletion. Tenants will compare tiers carefully, and unclear promises lead to disputes later.

Every isolation mechanism depends on knowing, reliably, which tenant a piece of telemetry belongs to.

The golden rule

If the label that names a tenant is supplied by the sender and trusted without checking, any sender can pretend to be any tenant. A careless or malicious client could stamp its data with another tenant’s identifier, filling that tenant’s storage with junk or causing its quota to run out. The safe design is for the platform to decide the tenant identity, based on something it has verified, such as the credentials presented when the data arrived.

Common sources of identity

Baggage is a convenience, not a security tool

OpenTelemetry supports a mechanism called baggage, which carries small key and value pairs along with a request as it travels between services. It is tempting to put a tenant identifier there. Baggage is useful for passing context inside your own system, but it travels in ordinary request headers, may be forwarded to third parties, and can be forged by anyone who can send a request. Use it for convenience, such as letting downstream services label their telemetry, but never as proof of identity.

Identity for telemetry sent from inside a tenant’s own systems

Customers who send data to your platform usually run their own agents or collectors. Giving each customer a credential that is unique to them lets you identify the tenant reliably. Credentials should be easy to rotate and revoke, and should be scoped narrowly: the credential allows sending telemetry as that tenant and nothing else. Short-lived tokens, issued by an identity service and refreshed automatically, reduce the damage if one is stolen.

Within a single organisation, workloads often run in shared clusters, and identity can come from the platform: the namespace, the service account or a signed workload identity. Here the gateway reads trusted platform information and maps it to a tenant through a table. The table itself is critical, since an error in it sends data to the wrong tenant, so keep it under strict change control with review and testing.

A well-formed design has clear layers, and each layer has a job in keeping tenants apart.

flowchart TD
  A[Applications and agents of many tenants] --> G[Edge gateway: authenticate and stamp tenant]
  G --> R[Routing layer: choose path by tenant]
  R --> P1[Pipeline for tenant group 1]
  R --> P2[Pipeline for tenant group 2]
  R --> P3[Default or quarantine pipeline]
  P1 --> E1[Exporter with tenant credentials]
  P2 --> E2[Exporter with tenant credentials]
  E1 --> S[Multi-tenant storage]
  E2 --> S
  P3 --> Q[Quarantine for investigation]
        

The most important principle in this layout is that trust is established once, early and by the platform. Everything after the edge gateway relies on the trusted label rather than on anything the sender said. Each later layer can then make decisions confidently, and an auditor can examine the gateway to see how identity is determined.

Agents near the tenant and gateways in the middle

A common arrangement uses two kinds of collector. Agents run close to the applications, perhaps inside the tenant’s own environment, and do light work such as collecting and forwarding. Gateways run centrally and do the platform work of authentication, stamping, routing and limits. Keeping the security-critical work in the gateway means that tenants cannot change or bypass it by altering their own agents.

It is tempting to let agents add the tenant label, since they know which application they serve. This can be allowed as a convenience, but the gateway must still verify and overwrite. If the label is accepted from the agent without verification, a compromised or misconfigured agent can impersonate another tenant.

The Collector offers a toolkit of components that, combined carefully, give you tenant isolation.

Names, options and availability change between versions, and some components live in the contributed set that must be included in your Collector build. Treat the list below as a map of ideas, and confirm details in the documentation for the version you run.

How the pieces fit together

Avoiding common pitfalls with these components

Each building block has traps that catch people the first time. Keeping request headers in the context is useful but increases memory use, because the headers travel with the data through the pipeline, so retain only the headers you need. Batching per tenant metadata creates a separate batch for each distinct value, and with a very large number of tenants this can use a lot of memory, which is why the option has a limit on the number of distinct values it will track. Set that limit with care, since data for values beyond the limit may be handled differently from what you expect.

Routing connectors depend on matching rules, and a mistake in a rule can send data to the wrong place. Keep rules simple, test them with sample data, and always include a default route. Authentication extensions must be applied to every receiver that accepts outside data, including less obvious ones such as health or debugging endpoints, or an unauthenticated back door will exist.

The edge gateway is the most security-sensitive part of the design, so it deserves close attention.

sequenceDiagram
  participant C as Tenant client
  participant G as Edge gateway
  participant A as Authentication check
  participant T as Tenant table
  participant P as Next pipeline stage
  C->>G: Send telemetry with credentials
  G->>A: Verify credentials
  A-->>G: Verified identity
  G->>T: Look up tenant for identity
  T-->>G: Tenant identifier
  G->>G: Remove any sender-supplied tenant label
  G->>G: Add trusted tenant label
  G->>P: Forward stamped telemetry
        

Step by step

When a request arrives, the receiver first checks the credentials through an authentication extension. Requests that fail the check are refused immediately, before any data is read. For requests that pass, the verified identity is used to look up the tenant, perhaps through a table kept in configuration or fetched from a trusted service. The gateway then removes any tenant label supplied by the sender and adds the verified one.

Where should the label go? Labels that describe the whole source, such as the tenant, belong on the resource, which is the top layer of the telemetry data model. Placing the tenant on the resource means that every item beneath it inherits the label, and it keeps the label out of the individual data points, where it would multiply the number of distinct series.

What to do with unknown or missing identity

Not every request will map cleanly. A credential may be valid but unknown to the tenant table. A trusted internal sender may omit its identity. The design must decide in advance what to do. The safest choices are to refuse data with no identity, or to send it to a clearly separate quarantine path where it is stored apart from any tenant and reviewed by the platform team. Silently assigning such data to a default tenant is dangerous, because it pollutes that tenant’s data and hides the problem.

Once data carries a trusted label, the platform can choose what happens to it.

A routing connector sits between pipelines. It looks at a property of incoming data, such as a resource attribute or a request header kept in the context, and sends the data to a matching pipeline. A default route catches data that matches nothing, which is exactly where unidentified or unexpected data should go. Routing can be done for traces, metrics and logs in the same way, with separate pipelines for each signal.

One pipeline per tenant, or per group?

The most obvious design is a separate pipeline for every tenant. It is easy to understand and gives each tenant its own processing rules and exporters. But the number of pipelines grows with the number of tenants, and each pipeline consumes memory and adds start-up time. With hundreds or thousands of tenants this does not scale, and configuration files become enormous.

A more scalable design groups tenants by what they need. All small tenants with standard rules share one pipeline, and the tenant label travels with the data to the exporter. Medium tenants with special rules share a second pipeline. Only the few large or demanding tenants get a pipeline of their own. This keeps configuration small while preserving the ability to treat important tenants differently.

flowchart TD
  IN[Stamped telemetry] --> RC{Routing connector}
  RC -->|Large tenants| PL[Dedicated pipeline each]
  RC -->|Standard tenants| PS[Shared standard pipeline]
  RC -->|Regulated tenants| PR[Regional pipeline]
  RC -->|No match| PD[Default quarantine pipeline]
        

Handling tenants that move between groups

Tenants change over time. A small tenant grows into a standard one, and a standard tenant signs a contract that requires regional storage. Routing based on a table that maps tenants to groups makes such moves a matter of editing the table, rather than rewriting pipelines. The table should be versioned, reviewed and applied in a controlled way, since an incorrect edit can send a tenant’s data to the wrong group.

When a tenant moves, think about what happens to data in flight and to history. New data starts flowing to the new group as soon as the table changes. Data already stored in the old group remains there, and queries must be able to find it, either by searching both groups for a period or by copying the history across. Decide in advance which approach you use, and tell the tenant what to expect.

Tenants differ in what they send, what they may keep and what they want removed.

Sampling with tenants in mind

Sampling decisions interact with tenancy in interesting ways. A fixed percentage is fair in proportion, but it gives a small tenant very few traces and a large one a flood. A limit on traces per second gives each tenant a predictable ceiling, which protects the platform but may leave a very large tenant with thin coverage. Many platforms combine approaches, with a base rate for all tenants and higher or lower rates according to tier. Whatever the policy, make it explicit and visible to tenants, so that nobody is surprised by what they can and cannot see.

Tail-based sampling, which decides after a trace is complete, needs all spans of a trace in one place. In a multi-tenant system it must also keep tenants apart: the decision memory for one tenant’s traces must never be shared with another’s. Routing by tenant before tail sampling, and then routing by trace identifier inside each group, keeps both needs satisfied.

Rules must be scoped

A rule meant for one tenant must apply to that tenant only. Conditions such as “drop spans with this name” need an extra condition that checks the tenant label, or they will delete data belonging to everyone who uses the same name. This is a classic source of cross-tenant damage, and it is easy to make when configurations are edited by hand. Prefer structures where each tenant’s rules live in their own clearly named section, and use automated checks to catch rules that lack a tenant condition.

Letting tenants control some of their own rules

Tenants often want a say in what is kept: which services are sampled more heavily, which fields are masked, which noisy endpoints are dropped. A safe way to allow this is a self-service layer that produces rules in a restricted form. The platform checks each request against the tenant’s tier and limits, wraps the rule in a condition that restricts it to that tenant, and applies it through the same reviewed process as any other change. The tenant never edits the shared configuration directly.

The last step is telling the storage system whose data it is receiving.

Many observability backends have their own idea of tenancy. A common pattern is that the backend expects a header on each request that names the tenant, and it stores and queries data separately for each header value. Several popular open-source systems for traces, metrics and logs follow this approach, so your platform can often rely on the backend to keep tenants apart in storage, provided it tells the backend the right tenant every time.

Three ways to carry the identity to the backend

Credentials for storage

The platform needs credentials to write to the backend. Keep these separate from anything tenants can influence, store them securely, and give the exporter only the permission to write, never to read. If different tenants require different credentials, keep them in per-group exporters, and rotate them on a schedule.

When the backend is unavailable for only one tenant

Backends sometimes fail for a single tenant, perhaps because that tenant has reached a storage limit or has been misconfigured on the backend side. If the exporter retries without limit, data for that tenant piles up, and if it shares a queue with others, their data waits too. The remedy is to separate queues by group, set sensible limits on retries and queue sizes, and make refusals visible both to operators and to the tenant concerned. Tenants should be told clearly when their data is being refused and why, so they can act.

Decide in advance what happens to data that cannot be delivered. Options include dropping it after a retry period, holding it in a limited disk queue, or sending it to a holding area. Dropping is simple but loses data. Holding is safer but costs resources and must be bounded. Whichever you choose, make the behaviour part of the tier’s promise, so that tenants know what to expect.

Keeping data apart is useless if one tenant can still bring the whole platform to its knees.

Where tenants compete

Tools for fairness

The first tool is a limit on how much each tenant may send, expressed as a rate, as a volume per period, or as a number of distinct series. The Collector’s core components include a memory limiter that protects the process as a whole, but a limit per tenant often needs additional help. Some contributed components and many API gateways can enforce per-tenant limits, and some backends enforce limits themselves for each tenant header. Check what is available for your versions, and place the limit as early as possible, so that excess data is refused before it consumes resources.

The second tool is separation of queues. If every tenant shares one exporter queue, a slow backend for one tenant can block all. Batching and queuing per tenant group means that a problem in one group fills only that group’s queue. The third tool is separate pipelines for tenants of different sizes, so that a very large tenant cannot crowd out small ones within a shared pipeline.

Different tenants owe different obligations to their own customers, and the platform must honour them.

Redaction and minimisation

Telemetry often accidentally contains personal or secret data: names in messages, tokens in headers, addresses in queries. The platform should provide redaction rules that remove or mask such values before storage, and these rules should be applied at the gateway so that sensitive data never reaches shared storage. Tenants with stricter needs can have stricter rules. Where possible, encourage tenants to avoid recording sensitive data in the first place, because removal after the fact is never perfect.

Data residency

Some tenants must keep their data in a certain country or region. A pooled design in one location cannot satisfy this. The usual answer is routing by tenant to regional pipelines and regional storage, so that data never leaves the permitted area. This also affects the gateway: if raw data crosses a border on its way to the region where it is processed, the rule may already be broken. Place gateways in each region, or route at the very edge.

Retention

Tenants may buy, or be required to have, different retention periods. In a pooled store this requires the backend to support separate retention per tenant, or requires separate storage for tenants with different periods. Be clear about what retention means: how long data stays searchable, and how long it stays on disk, which may differ.

Deletion and the right to be forgotten

When a tenant leaves, or when a person asks for their data to be erased, the platform must be able to delete it. In shared storage where many tenants’ data is mixed in the same files, deletion can be hard or even impossible at fine detail. Design for deletion at the tenant level from the start, choosing storage that can remove a tenant’s data entirely, and document what can and cannot be removed at finer levels.

Encryption and key management

Data should be encrypted while it travels, between tenants and the gateway and between every internal stage, and while it rests in storage. Encryption in transit relies on certificates, which must be issued correctly, renewed before they expire and checked on both sides. Encryption at rest is often handled by the storage system. Some tenants ask for their own keys, so that they can revoke access to their data by withdrawing a key. This is a powerful form of isolation, but it adds the burden of managing many keys safely, and it must be designed carefully so that a lost key does not mean lost data.

Keep keys separate from the data they protect, rotate them on a schedule, and limit who can use them. Record every use of a sensitive key. If the platform serves regulated tenants, expect auditors to ask for evidence of each of these practices.

Isolation must hold when people read data, not only when machines write it.

Writing data under the correct tenant is only half of the story. The other half is making sure that people can read only what they are allowed to read. When someone opens a dashboard, runs a search or sets an alert, the platform must attach their tenant, or the set of tenants they are allowed to see, to every query, and the backend must enforce it. If this check is done only in the user interface, anyone who calls the backend directly can bypass it.

Principles for safe querying

The platform operator’s special position

The people who run the platform can usually see everything, which is both necessary and risky. Reduce the risk by limiting how many people have this power, requiring approval and recording for its use, and giving most operators tools that show health and volume without revealing content. Tenants, especially regulated ones, will ask how operator access is controlled, and a clear answer builds trust.

Dashboards, alerts and shared settings

Dashboards and alert rules are also tenant data. A dashboard that queries across tenants, or an alert rule that reads another tenant’s series, is a leak waiting to happen. Keep dashboards and alert rules organised by tenant, give each tenant its own space, and review any shared or template dashboards to ensure they do not pull data from outside the viewer’s allowed set.

Sharing saves money only if everyone can see, and pay, their fair part.

Cost isolation begins with measurement. For each tenant, the platform should record how much data it sent, how much was stored and for how long, and how much was queried. Without this, shared costs are split by guesswork, and tenants have no reason to be careful. With it, you can charge tenants, show them their own usage, and set limits based on facts.

What to measure

Taking care with the meter itself

Counting per tenant means adding a tenant label to the platform’s own metrics, and if the number of tenants is large, this itself creates many series. Keep the number of labels small, count at coarse granularity, and consider summarising per tier for dashboards while keeping detailed figures in a separate store used for billing. Counting must be done after identity is verified, so that spoofed labels cannot shift costs to another tenant.

Preventing cost surprises for tenants

The best bill is one that holds no surprises. Send tenants usage reports on a regular schedule and warnings when they approach limits. Show which services, signals and labels contribute most to their volume, so they can reduce waste. Many surprise bills come from a single change, such as a new label with many distinct values or a debug setting left on, and an alert on sudden growth catches these early, often before the tenant notices.

Fair attribution also requires deciding what to do about shared costs that no tenant causes directly, such as the platform’s own monitoring or the cost of idle capacity kept in reserve. Some platforms spread these costs evenly, some in proportion to usage, and some absorb them as the cost of providing the service. Whatever is chosen, explain it clearly in advance.

A platform that promises isolation must be able to prove it is working.

The telemetry platform needs its own monitoring. Beyond the usual health figures such as memory, processor use and queue length, a multi-tenant platform needs views by tenant: how much each is sending, how much is being refused, how long their data takes to become searchable, and whether any limits are close. These views allow operators to spot a noisy neighbour early, answer questions from tenants, and verify that limits and routing behave as designed.

Service levels for tenants

Define what you promise: how quickly data is accepted, how long before it is searchable, how much availability to expect, and what happens when limits are exceeded. Different tiers may have different promises. Measure each promise from the tenant’s point of view, so that your reports match their experience. A promise that is not measured is only a hope.

Most tenancy failures come from a small number of repeated mistakes.

A design that works for ten tenants may break at ten thousand.

Scale in layers

The edge gateway scales by adding more identical collectors behind an ordinary load balancer, because authentication and stamping are stateless. The routing and processing layer can scale the same way where its work is stateless. The stateful parts, such as tail sampling, need data for each trace to arrive together, which is the job of a load balancing exporter that routes by trace identifier. In a multi-tenant system, combine this with tenant routing so that each stateful group serves a set of tenants and each trace stays whole inside its group.

Sharding tenants across fleets

Beyond a certain size, one fleet of collectors becomes too large or too risky. A single bad configuration affects everyone, and a single failure domain covers all tenants. Splitting tenants across several independent fleets, sometimes called cells, limits the blast radius of any one problem. Each cell serves a subset of tenants, and a thin routing layer in front of the cells sends each tenant to its home cell. A problem in one cell leaves the others untouched.

flowchart TD
  T[All tenants] --> FR[Front routing layer]
  FR --> C1[Cell 1: gateway, processing, storage]
  FR --> C2[Cell 2: gateway, processing, storage]
  FR --> C3[Cell 3: gateway, processing, storage]
        

Moving a tenant

Tenants grow, and a tenant that began small may need a bigger tier or its own cell. Plan the move in advance. Moving data while keeping history searchable and keeping live traffic flowing needs a routine: start sending new data to the new home, keep the old home readable for a period, and then retire it. Practising this on a small tenant before you need it for a large one is wise.

Capacity planning with tenants in mind

Capacity for a shared platform is planned differently from capacity for a single application. Total volume matters, but so does the shape of the distribution: a platform where a few tenants produce most of the data behaves very differently from one where volume is spread evenly. Study the distribution, and plan for the largest tenants separately, since their growth can consume capacity faster than the average suggests. Keep headroom for sudden growth from any tenant, and review the figures regularly as tenants join, grow and leave.

Plan also for the busiest moments. Many tenants share the same patterns, such as a morning rush or an end-of-month report, so their peaks may coincide. A platform sized only for the average will struggle at these moments, so size for the combined peak and test with realistic bursts.

Isolation that has never been tested is a belief, not a fact.

Canary tenants

Create a few synthetic tenants that exist only for testing. They continuously send known data, and automated checks read it back, verify that it arrived complete under the right tenant, and confirm that other tenants’ canary data is not visible. A failing canary check is an early warning that something in the platform has changed for the worse, even before any real tenant is affected.

Test configuration changes before they go live

Most isolation failures begin with a configuration change. Run each change in a test environment with sample data from several tenants, and compare the output with expectations. Automated checks can scan configurations for known dangers: rules without tenant conditions, pipelines without a default route, exporters with fixed credentials in the wrong group, and logging of sensitive headers.

Technology alone does not deliver isolation. Routines and responsibilities do.

Onboarding a tenant

Offboarding

When a tenant leaves, disable credentials first, so no new data arrives. Then remove routing and rules, delete or return stored data according to the agreement, remove the tenant from billing and dashboards, and record that the work was done. Forgotten tenants, with live credentials and stored data, are a quiet source of risk.

Managing configuration safely

Keep tenant configuration in version control, generate it from a single source of truth where possible, and require review for changes. Automated generation reduces the risk of the copy-and-paste mistakes that cause cross-tenant effects. Give tenants self-service where safe, such as choosing their own sampling within limits, while keeping identity, routing and limits under platform control.

A few typical situations show how the choices fit together.

graph LR
  A[Small tenants] --> P[Shared pool with limits]
  B[Growing tenants] --> M[Shared pool with higher tier]
  C[Large or regulated tenants] --> S[Dedicated pipeline or silo]
  P --> U[Usage metering and reports]
  M --> U
  S --> U
        

What the scenarios share

In every case, identity was established by the platform, routing used groups rather than one pipeline per tenant, limits protected everyone, and usage was measured per tenant. Where problems occurred in other organisations, one of these four foundations was missing.

A checklist in plain language, drawn from everything above.

A sensible order of work

Begin by writing the promises and choosing the model. Build the edge gateway and identity stamping first, since everything depends on it. Add routing with a default path, then export with tenant identity. Add limits and metering. Add redaction and per-tenant rules. Build monitoring and tests, and only then onboard real tenants, starting with a friendly few. Following this order gives you a trustworthy foundation before the stakes become high.

Short, plain answers to the questions people ask most often.

No single built-in switch exists. Multi-tenancy is assembled from attributes, authentication, processors, connectors, exporters and tenant-aware backends. Check the current documentation for any new conventions.

On the resource, the top layer of the telemetry model, so it applies to everything beneath it without multiplying labels on individual data points.

Not as proof. Use it at most as a hint, verify identity from credentials at the edge, and overwrite the header with the verified value.

Only for a few large or special tenants. For many tenants, route by group and let the tenant label travel with the data, to keep configuration and memory use manageable.

Apply limits on rate, volume and series count per tenant at the edge, separate queues and batches by group, and use pipelines of their own for the largest tenants.

Use the batching option that groups data by chosen metadata such as the tenant header, so each batch and each outgoing request contains one tenant only.

Refuse it or send it to a clearly separate quarantine path. Count it, alert on it and investigate, rather than assigning it to a default tenant.

It is convenient inside your own system but can be forged and may leak to third parties, so it must not be used as proof of identity or for security decisions.

Route tenants to regional pipelines and regional storage, and place gateways in each region so data does not cross borders before it is routed.

Choose storage that can remove a tenant’s data entirely, document what can be removed at finer detail, and test deletion with a synthetic tenant before it is needed.

Meter volume, series and storage per tenant after identity is verified, begin with showback reports, and keep the records long enough to settle disputes.

Not usually. Many backends support a tenant header and separate storage logically. Dedicated backends are for regulated or very large tenants who need the strongest separation.

Test it routinely with spoofing, cross-read, noisy-neighbour and deletion tests, and run canary tenants in production whose data is read back and checked automatically.

Tenant routing decides which group handles the data, sampling controls how much is kept, and a load balancing exporter keeps whole traces together inside each stateful group. They work together as stages of one design.

Multi-tenant telemetry isolation lets many tenants share one observability platform without sharing their data, their performance or their bills. OpenTelemetry provides no single tenant switch, so isolation is built from ordinary parts: verified identity stamped at an edge gateway, a tenant label on the resource, routing by group with a safe default, per-tenant processing, exporters that carry tenant identity to the storage, limits that protect the platform, and metering that makes costs visible.

The strength of the whole design is the strength of its weakest gap. A single trusted-but-forged label, a single mixed batch, a single missing default route or a single query without a server-side check can undo everything else. Define what you promise, build trust once and early at the edge, scope every rule by tenant, and test isolation again and again, and a shared platform can be both economical and safe.