Before we learn how to switch things off, we need to understand why anyone would want to. It starts with how easy it is to produce too much.

When a program runs in production, you cannot stand next to it and watch it. So you ask the program to send you information about itself. This information is called telemetry. The most common kinds are traces, which follow one request through many services, metrics, which are numbers measured over time, and logs, which are timestamped messages.

OpenTelemetry offers a wonderful shortcut: automatic instrumentation. You attach an agent or install a few packages, and your program starts producing telemetry for web servers, database drivers, message queues and many other libraries, without you writing any measuring code. This is a huge time saver. But “everything, automatically” has a flip side. It does not know what matters to you.

How much is too much?

Consider a small online shop. A load balancer checks whether each server is alive by calling a health check address every five seconds. With ten servers, that is two calls per second, or about 172,800 calls per day, and every one of them can produce a trace with several spans. None of those traces will ever help anyone debug anything. Yet they take up network bandwidth, processing time in the application, space in the backend and money on the monthly invoice.

Now add a library that records every single file read, a database driver that records every tiny internal query, and a framework that creates spans for every internal function call. In a busy system, it is entirely possible for more than half of the telemetry to be completely unhelpful.

A handful of small words appear in every conversation about this topic. Learn them once and the rest becomes easy.

Instrumentation

Instrumentation is code that measures what a program is doing and produces telemetry about it. The word is borrowed from the instruments on a ship or an airplane: the dials, gauges and meters that tell the pilot what is happening. In software, instrumentation creates spans, increments counters and writes log records.

Manual and automatic instrumentation

Manual instrumentation means you, the developer, write the measuring code yourself, for example “start a span called calculate price, do the work, end the span.” You are in complete control, because nothing happens unless you wrote it.

Automatic instrumentation, also called auto-instrumentation, means that a ready-made tool adds measuring code for you, for popular libraries and frameworks. It does this by attaching an agent when the program starts, by wrapping library functions at runtime, or by shipping small add-on packages. You get telemetry from the web framework, the HTTP client, the database driver and more, with almost no effort.

Instrumentation library

Each piece of automatic instrumentation usually lives in its own small package, called an instrumentation library, which knows how to measure one thing, for example one web framework or one database driver. A system may have dozens of them active at once. Each can usually be switched on or off separately, which is the key fact that makes suppression possible.

Signals

Traces, metrics and logs are called signals. A single instrumentation library may produce more than one signal. For example, an HTTP server library may produce a span for each request and also a metric for request duration.

SDK, API and exporter

The API is the set of functions that instrumentation calls to create telemetry. The SDK is the engine behind the API that collects, processes and sends the telemetry. An exporter is the part of the SDK that sends the finished telemetry to another place, such as a collector. Suppression can happen in any of these places, as you will see.

To switch something off at the right place, you must first understand the road that telemetry takes from your code to your dashboard.

graph LR
  A["Your Application Code"] --> B["Instrumentation Library"]
  B --> C["OpenTelemetry API"]
  C --> D["SDK: samplers, processors, views"]
  D --> E["Exporter"]
  E --> F["Collector: receivers, processors, exporters"]
  F --> G["Backend and Dashboards"]
    

Read the figure from left to right. Your application does its normal work, such as handling a web request. An instrumentation library watches that work and calls the OpenTelemetry API to say “a request started” or “a database call finished.” The SDK behind the API decides what to do with those calls: a sampler may decide to drop a trace, processors may change or filter spans, and views may reshape metrics. The exporter then sends whatever is left to a collector, which can filter and change it again before it reaches the backend that stores it and draws your dashboards.

Every box in this road is a place where something can be switched off or filtered. And each choice has a different price. The earlier you stop something, the more you save, because the work, memory and network use are avoided completely. The later you stop it, the more you have already paid for.

What an instrumentation library actually does

• Hooks in. It attaches itself to the library it watches, for example by wrapping a function in a web framework.
• Creates spans or measurements. When the watched function runs, it starts and ends spans, adds attributes such as the HTTP method and the route, and records metrics.
• Handles context. It reads trace headers from incoming requests and writes trace headers into outgoing ones. This is called context propagation, and it is what ties the spans of different services into one trace.
• Hands data to the API. It does not send anything over the network itself. The SDK and exporter do that.

That third point, context handling, is the one that matters most for suppression. An instrumentation library often does two jobs at once: it produces telemetry and it passes along the trace identity. If you switch off the whole library, you may stop both jobs, and that can break traces in other services. We will give this problem its own chapter.

There are several very different reasons for switching something off. Knowing your reason helps you choose the right tool.

Suppress, disable, drop and filter: what is the difference?

People use these words loosely, but there is a useful way to separate them.

• Disable usually means switching off a whole component, such as an instrumentation library or the entire SDK, so that it does nothing at all.
• Suppress usually means stopping telemetry for a specific situation while the component stays active, for example “do not create spans while inside this block of code” or “ignore requests to this address.”
• Drop means that telemetry has been created but is thrown away before it is stored, for example by a sampler or a view.
• Filter means selecting which telemetry to keep based on rules, for example in a collector.

In everyday speech all four may be called “suppression.” This guide uses the wider meaning, and points out the differences where they matter.

There is no single “off switch” in OpenTelemetry. There are many switches, each at a different layer. This chapter gives you the map, and the following chapters visit each stop.

graph TD
  A["Deployment level: do not attach the agent, operator annotations"] --> B["SDK level: disable the SDK or a signal"]
  B --> C["Instrumentation library level: disable one library"]
  C --> D["Request level: ignore specific URLs or operations"]
  D --> E["Code level: suppress inside a block of code"]
  E --> F["SDK processing: sampler, span processor, metric views"]
  F --> G["Collector level: filter, transform, sample"]
  G --> H["Backend level: ingestion rules and retention"]
    

The figure runs from the top, where the cut is earliest, to the bottom, where it is latest. A cut near the top prevents everything below it from happening. A cut near the bottom happens after the work and the transport have already been paid for.

How to use the map

Ask three questions every time. First: what exactly do I want to stop? A single route? One library? One kind of attribute? Second: do I still need trace propagation through this part? Third: where is the cheapest place that still solves the problem safely? The answers point you to a layer.

The biggest switches are the simplest. They are also the blunt ones, so use them only when you really mean to switch off a lot.

Disabling the whole SDK

The OpenTelemetry specification defines a standard environment variable called OTEL_SDK_DISABLED. When it is set to true, a compliant SDK behaves as though OpenTelemetry were not installed. Instrumentation calls still happen, but the SDK does nothing with them: no spans are recorded, no metrics are kept and nothing is exported. It is the “main fuse” for telemetry.

This is useful in a few cases. You might switch the SDK off in a unit test environment, on a developer’s laptop, in a temporary emergency when telemetry is suspected of harming performance, or in a deployment where no backend is available. Because it is an environment variable, it can be set without changing code, and removed again just as easily.

Turning off one signal

You often want to stop one signal but keep the others. OpenTelemetry defines a standard setting for the exporter of each signal. Setting the exporter to the special value none means “do not export this signal anywhere.”

This is the right tool when a whole signal is not needed. For example, a team that only wants traces can set the metrics exporter to none, so that the application does not spend effort collecting and sending metrics. Remember that setting an exporter to none stops the sending, but in some SDKs the instrumentation may still create the telemetry in memory before it is thrown away. If you need to avoid even the creation, look for a setting that disables the instrumentation itself, which the next chapter covers.

When to use these big switches

• In tests, where telemetry would only add noise and slowness.
• In a quick emergency, where you need to rule out telemetry as the cause of a performance problem.
• For a service that really needs no telemetry of one kind, such as no metrics.
• As a safe default for a new environment until the backend is ready.

They are not the right tool for removing one noisy route or one chatty library. For that, you need a narrower switch.

This is the switch most people are looking for. It turns off one instrumentation library and leaves everything else running.

Every auto-instrumentation distribution has a list of the libraries it can instrument, each with a short name such as “flask,” “redis,” “http” or “kafka.” Most distributions let you either disable chosen names from the full list, or disable everything and enable only the names you want. The exact setting names differ by language, but the idea is the same.

Two styles: deny list and allow list

• Deny list. Everything is on, except the names you list. This is easy to start with, but when you upgrade, newly added instrumentations switch themselves on, which can surprise you.
• Allow list. Everything is off, except the names you list. This is stricter and more predictable. It is a good choice for mature systems where you know exactly what telemetry you want.

Which libraries are commonly disabled?

Often you do not want to remove a whole library. You want to remove just the boring requests. This is the most common and the safest kind of suppression.

Instrumentation for web servers and HTTP clients usually lets you give it a list of patterns, or a small function, to decide which requests to ignore. If a request matches, the library simply does not create a span for it. All other requests are still measured as normal.

Typical things to ignore

• Health check and readiness probe addresses.
• Address paths that serve metrics for scraping.
• Static files such as images, style sheets and scripts.
• Internal status pages and administrative pings.
• Favicon requests from browsers.

How it is done in different ecosystems

Server side and client side are different

A subtle point: ignoring a URL on the server side means “when my service receives a request for this address, do not trace it.” Ignoring a URL on the client side means “when my service calls this address, do not trace the call.” These are separate settings. A common beginner surprise is to configure the server-side ignore list and then still see spans for outgoing calls to the same address from another service. Decide which side you mean, and set both when needed.

Sometimes you want telemetry to pause for a specific stretch of code. OpenTelemetry’s SDKs have a built-in idea for this, called context-based suppression.

Recall that the context is the small bag of information that travels with a piece of work. Some SDKs let you put a special marker into that bag, which means “do not create telemetry while this marker is present.” Instrumentation libraries check the context before creating spans, and if they see the marker, they skip their work. When the block of code finishes, the marker is removed, and normal instrumentation resumes.

In the Python ecosystem, this is offered as a helper that you wrap around a section of code. In the JavaScript ecosystem, there is a function that returns a new context in which tracing is suppressed. Other SDKs have similar tools or internal markers. The exact helpers differ between languages and versions, so check your SDK’s documentation.

The classic example: do not trace the tracer

Telemetry exporters send data over the network, often using an HTTP client library. If that HTTP client is itself instrumented, then sending a batch of spans would create a new span for the sending, which would be exported in the next batch, which would create another span, and so on. This feedback loop would flood the system. To prevent it, exporters run their sending inside a suppressed context, so the HTTP client does not trace its own telemetry traffic. You get this protection for free in good SDKs, but you can use the same idea for your own code.

sequenceDiagram
  participant App as Application Code
  participant Ctx as Context
  participant Lib as Instrumented HTTP Client
  App->>Ctx: Mark telemetry as suppressed
  App->>Lib: Call a monitoring endpoint
  Lib->>Ctx: Is suppression marked?
  Ctx-->>Lib: Yes
  Note over Lib: No span is created
  App->>Ctx: Remove the mark
  App->>Lib: Call a business service
  Lib->>Ctx: Is suppression marked?
  Ctx-->>Lib: No
  Note over Lib: Span is created as usual
    

Good uses for code-level suppression

• Internal housekeeping calls. A background task that polls a configuration service every second and would otherwise create thousands of identical traces.
• Calls to monitoring and telemetry systems. Any code that talks to the observability system itself.
• Bulk operations. A loop that reads a million rows and would otherwise create a million tiny spans. Suppress inside the loop, and create one span around the whole loop instead.
• Sensitive sections. A short section of code that handles private data, where you prefer no automatic spans to be created.

The SDK has its own tools for thinning telemetry out. They are the best choice when you want to remove telemetry but keep trace identities flowing.

Samplers: dropping whole traces by rule

A sampler decides, when a span starts, whether the trace will be recorded and exported. A custom sampler can look at the name of the span and its starting attributes, and decide to drop requests for health checks or other noisy routes, while keeping everything else. This is called head-based sampling, because the decision is made at the head of the trace.

The great advantage of dropping through a sampler is that the trace context still travels. A dropped span becomes a lightweight placeholder, the trace ID and span ID are still passed along, and other services still see a consistent picture. Chapter 13 explains why this matters.

Span processors: changing or filtering spans

A span processor receives every span at its start and its end. It can add attributes, remove sensitive attributes, or in some designs filter spans out before export. Processors are handy for scrubbing private data. They are less ideal for dropping spans, because by the time a processor sees a span, the span has already been created, and the application has already paid the cost of creating it. Dropping a parent span in a processor while keeping its children can also leave orphan spans in the trace, so be careful.

Metric views: reshaping or removing metrics

For metrics, the SDK offers views. A view is a rule that matches instruments by name, type or source, and changes how they are handled. Views can drop an instrument entirely, keep only chosen attributes to reduce the number of series, rename a metric or change its aggregation. If one instrumentation library produces a metric with a label that has thousands of values, a view that removes that label can cut the cost sharply without touching the library.

When you cannot change the application, or when you want one central place to apply rules, the collector is a powerful tool.

The OpenTelemetry Collector is a separate program that receives telemetry from many applications, processes it, and forwards it to one or more backends. Its processing stage is made of small building blocks called processors. Several of them are useful for suppression.

Strengths of collector-level filtering

• No application change. You can fix noise in a service you cannot redeploy.
• One central policy. A single rule can apply to every service in the company.
• Fast to change. Updating a collector configuration is usually quicker than rebuilding and releasing many services.
• Language independent. The same rule works regardless of the language of the source service.

Limits of collector-level filtering

• The work is already done. The application has created, recorded and sent the telemetry. You save backend storage, but not the application’s effort or the network between the application and the collector.
• It can cut holes in traces. Dropping a parent span while keeping its children, or dropping spans from the middle of a trace, leaves orphans and broken trees. Filter whole traces, or leaf spans that have no children, to stay safe.
• It cannot undo propagation. The collector sees telemetry after the fact, so it cannot change which trace headers were sent between services.

The earliest cut of all happens before the application even starts. If the agent is never attached, no instrumentation ever runs.

Automatic instrumentation has to be introduced into a program somehow. Depending on the language and platform, that is done by adding an agent file to the start-up command, by adding a wrapper command, by installing packages, or by letting a Kubernetes component inject it. Each of these entry points is also an exit point: if you remove it, instrumentation disappears.

Ways instrumentation is introduced, and how to switch it off

Why deployment-level control is attractive

• Maximum savings. Nothing is attached, nothing runs, no memory is used.
• Visible and reviewable. The decision lives in the deployment files, not hidden in code.
• Easy to roll back. Adding the annotation or the agent again restores everything.

Why it is also the riskiest

A service with no instrumentation at all is a hole in every trace that passes through it. It will not extract incoming trace headers and will not inject outgoing ones, so the trace is cut in two at that point. Use deployment-level control only for services that really are not part of any traces you care about, such as isolated batch tools, or for a temporary experiment.

This is the most important chapter of the guide. Many painful incidents come from confusing “stop recording spans” with “stop passing the trace along.”

As we saw earlier, instrumentation libraries often do two jobs. Job one is producing telemetry: creating spans, metrics and logs. Job two is propagating context: reading trace headers from incoming messages and writing them into outgoing ones, so that the trace identity flows from service to service.

When you disable a whole HTTP server or HTTP client library, you usually switch off both jobs at once. The server library no longer reads incoming trace headers, so the service starts a brand new trace for each request. The client library no longer writes trace headers, so the next service cannot continue the trace. Your traces fall apart into fragments.

graph LR
  A["Service A: instrumented"] -->|"trace headers sent"| B["Service B: HTTP library disabled"]
  B -->|"no trace headers sent"| C["Service C: instrumented"]
  A --> T1["Trace 1 contains A only"]
  B --> T2["No spans from B"]
  C --> T3["Trace 2 starts at C as a new root"]
    

In the figure, service B has its HTTP instrumentation switched off. Service A sends trace headers, but B does not read them and produces no spans. When B calls C, it sends no trace headers, so C starts a fresh trace. Instead of one connected journey, the backend now shows two disconnected stories, and nobody can see that they belong together.

Two different ways to remove a span

The safe rules

• Prefer narrow switches. Ignore a route or drop with a sampler, before disabling a whole HTTP or messaging library.
• If you must disable a library, look for a setting that keeps propagation. Some SDKs let you disable span creation while keeping the propagators running. Check the documentation.
• Remember the propagators are separate. Context propagation is performed by propagator components configured in the SDK. As long as they are configured and used by something that reads and writes headers, trace identity can still flow. But if the instrumentation that calls the propagators is switched off, nothing calls them.
• Test after every change. Send a request through a path that includes the changed service and check that the trace is still one tree.

With so many layers, how do you choose? Use the questions in this chapter as a short checklist.

graph TD
  A["I want to remove some telemetry"] --> B{"What exactly do I want to remove?"}
  B -->|"A few specific requests, like health checks"| C["Ignore them in the library, or drop with a sampler rule"]
  B -->|"One noisy library, like file access"| D["Disable that instrumentation library"]
  B -->|"One signal, like all metrics"| E["Set that signal exporter to none"]
  B -->|"A sensitive or high-cardinality attribute"| F["Remove it with a processor, a view or the collector"]
  B -->|"Everything for this service"| G["Disable the SDK or do not attach the agent"]
  B -->|"A noisy part of my own code"| H["Suppress inside that code block"]
  D --> I{"Is it an HTTP or messaging library?"}
  I -->|"Yes"| J["Check propagation, prefer narrower options"]
  I -->|"No"| K["Safe to disable, then verify"]
    

The five questions

A quick lookup table

Let us walk through a complete example, from noticing the problem to proving the fix. The numbers are invented, but the steps are the ones real teams follow.

A team runs an order service behind a load balancer. Their tracing bill has doubled in two months while customer traffic grew by only ten percent. They suspect that something is producing a lot of spans for little value.

Sometimes the problem is not that there is too much telemetry, but that the same thing is recorded twice. Duplicates confuse readers and double the cost.

Duplicate spans appear when two layers of instrumentation both measure the same operation. There are several common causes.

How to remove duplicates

• Use the built-in duplicate suppression. Some agents, such as the Java agent, have a mechanism, often called a span suppression strategy, that avoids creating a second span of the same kind when one is already active for the same operation. It is usually on by default in a safe form, and some versions allow you to change the strategy. Check your agent’s documentation.
• Disable the less valuable layer. If a lower-level library duplicates a better, higher-level one, disable the lower-level one. Check that propagation is not affected.
• Remove redundant manual spans. If automatic instrumentation already covers a call, remove your own span around it, or turn your span into a child with useful extra attributes.
• Pick one agent. Never attach two tracing agents to the same process. Choose one and remove the other.
• Decide who owns the span in a proxy plus application setup. Often the sidecar owns network-level spans and the application owns business-level spans. Disable the overlapping ones on one side.

Sometimes you do not want to remove a whole span, only a risky or expensive detail inside it. This is often a better answer than switching off the instrumentation.

Sensitive data in attributes

Automatic instrumentation records attributes such as the full address of a request, the text of a database statement, the names of message queues and sometimes headers. Some of these can contain personal data or secrets: an email address inside a web address, a card number inside a query, an access token in a header. Once recorded, such data is copied to the collector, the backend, backups and every person who can read the traces.

You have several options, from best to last resort.

• Do not capture it at all. Many instrumentations capture request and response headers only when you ask them to. Leave those settings off for sensitive headers. Some database instrumentations sanitize statements by replacing literal values with placeholders, and this is normally on by default. Keep it on.
• Remove it in the SDK. A span processor can remove or mask chosen attributes before the span is exported. This keeps the data inside your process.
• Remove it in the collector. Attribute and transform processors can delete or hash chosen attributes for all services at once.
• Disable the instrumentation. If nothing else works, switching off the library that captures the data is the safest option, with the cost of losing its other telemetry.

High-cardinality data

Cardinality is the number of different values a label can take. A label such as the HTTP method has a handful of values, which is fine. A label such as the full address including a user identifier can have millions of values. For metrics, each unique combination of label values becomes a separate time series, so a high-cardinality label can create millions of series, slow down the backend and inflate the bill.

The remedies are similar. Prefer the route template, such as “orders by identifier,” over the raw address. Use metric views to drop or reduce labels in the SDK. Use collector processors to remove or group values. And avoid putting unbounded values, such as user identifiers or request identifiers, into metric labels in the first place. They belong in traces and logs, which are built for high-detail data.

Here are situations where teams reach for suppression. The scenarios are illustrative examples meant to build intuition, not descriptions of any particular company’s internal systems.

A design pattern is a proven way of solving a problem that keeps coming back. These are the patterns teams use most often when taming instrumentation.

The “summarize instead of suppress” pattern in more detail

Imagine a function that processes a file of ten thousand records and calls a database for each one. Automatic instrumentation creates ten thousand database spans. The trace becomes unreadable, and the backend is flooded. If you suppress all of them, you lose information about the loop. The better pattern is to suppress the inner spans, and wrap the whole loop in a single span that records useful summary values: how many records were processed, how many failed, and how long the loop took. One meaningful span replaces ten thousand meaningless ones.

The “defense in depth” pattern in more detail

For privacy-sensitive data, a single control is fragile. Someone might upgrade a library and a default might change. Someone might add a new attribute without telling anyone. By placing a control at each layer, you ensure that a mistake at one layer is caught by another. The source does not capture, the SDK processor masks anything that slipped through, and the collector deletes any attribute whose name matches a sensitive pattern. The cost is a little extra configuration, and the benefit is far less chance of a data leak.

Suppression is helpful, but it is not free. Every piece of telemetry you remove is information you may later wish you had. An honest look at both sides helps you decide how far to go.

The central trade-off: savings versus visibility

Every cut moves a slider between “see everything and pay for it” and “see less and pay less.” The best position is not at either end. It is the point where the telemetry you keep answers the questions you actually ask, and the telemetry you drop is the telemetry nobody has ever opened. The test is simple: if nobody has used a certain kind of telemetry in an investigation or a dashboard in the last few months, it is a good candidate for suppression.

Suppress versus sample

It is worth comparing suppression with sampling, because they overlap. Sampling keeps a share of every kind of trace, chosen at random or by rule. Suppression removes specific kinds of telemetry entirely. Use suppression for telemetry that is never useful, such as health checks. Use sampling for telemetry that is useful but too plentiful, such as ordinary customer requests. The two work well together: suppress the useless, sample the plentiful.

These mistakes appear again and again in real systems. Each looks harmless and each can silently damage your telemetry.

These habits keep your suppression rules safe, understandable and effective. Think of them as a checklist for every change.

A short pre-change checklist

• Can I describe exactly what I want to remove, and why?
• Is there a narrower switch than the one I plan to use?
• Will this affect context propagation for any trace that matters?
• Have I checked the exact name of the setting for my language and version?
• Do I know how I will prove that it worked and that nothing else changed?
• Is the change written down, with its reason, where my team can find it?
• Do I know how to undo it quickly?

A suppression rule that does nothing looks the same as one that works, until the bill arrives. And a rule that does too much looks the same as a quiet system, until an outage. Testing is how you tell the difference.

Test one: the “before and after” count

Before the change, record the number of spans, metric series or log records per minute for the affected service. After the change, record them again, with similar traffic. The difference should match what you expected. If you removed health checks that were 45 percent of spans, the count should drop by about 45 percent. If it does not change, your rule is not working. If it drops much more, your rule is too broad.

Test two: look at the raw output

In a test environment, send the telemetry to a place where you can read it directly. The collector has a debug exporter that prints what it receives, and most SDKs offer a console exporter. Send a request that should be suppressed and one that should not. Confirm that the first produces nothing and the second produces the usual spans, with the usual attributes.

Test three: follow a trace across the changed service

Send a request through a path that includes the changed service. Open the trace in your tracing tool. Check that there is one tree, with the same trace ID from start to finish, and that the changed service’s spans are present as expected. This is the test that catches propagation damage.

Test four: check the edges of the pattern

For rules based on patterns, build a list of addresses or names from real traffic, including near misses. Run them through the pattern and see which are matched. You want exactly the ones you intended and no others. A few minutes spent here prevents a rule from hiding something important.

Test five: check metrics and logs too

Disabling an instrumentation library may also remove metrics or log records that dashboards and alerts depend on. List the dashboards and alert rules that use telemetry from the affected library, and make sure they still show data after the change.

Sooner or later a rule will not do what you expect. Either the noise stays, or something important vanishes. Here is a calm way to find out why.

Case one: the noise did not go away

Case two: something important disappeared

Measuring the health of your rules over time

Treat suppression as something to observe. Track the volume of telemetry per service per day and watch for sudden changes. A drop that nobody planned is a warning that a rule is too broad or that an upgrade changed a default. A rise after an upgrade may mean that a switch was renamed and no longer applies. A short weekly look at these numbers catches most problems early.

Suppression rules are decisions about what your company chooses to see. In a larger organization, those decisions need a little structure.

Governance: who decides what is switched off?

When many teams manage their own services, it is tempting to let each team switch off whatever it likes. That works for a while, then causes trouble: one team disables HTTP instrumentation and breaks traces for three other teams, another hides errors to make a dashboard look clean, and a third has a rule that nobody remembers. A light structure prevents this.

• Company defaults. A platform or observability team defines a baseline: which instrumentations are on, which routes are ignored everywhere, which attributes are always removed.
• Team overrides. Individual teams may adjust within limits, for example ignoring a route unique to their service. Overrides are kept in version control and reviewed.
• Protected switches. Some switches, such as disabling HTTP or messaging libraries, or turning off the SDK in production, may require a review, because of their effect on other teams’ traces.
• A record of reasons. Every rule has a comment explaining the reason, the owner and the date. Rules without a reason get questioned and eventually removed.

Security

• Suppression is not secrecy. Removing a span from a dashboard does not remove the underlying action. Do not use telemetry suppression to hide activity from auditors. Audit logs are a separate system with their own rules.
• Security monitoring needs its own signals. If you suppress telemetry for noisy routes, make sure that security tools do not depend on that telemetry. Suspicious requests to health or admin addresses could be exactly what a security team wants to see.
• Protect the controls. Anyone who can change environment variables or collector rules can hide activity or change what is captured. Limit that access and log changes.
• Remove sensitive data early. Data that never leaves the application cannot be leaked from the collector, the network or the backend.

Privacy

Suppression is one of the strongest privacy tools, because data that is never captured cannot be misused. Review what your instrumentations capture by default, and compare it with your privacy rules. Turn off capture of anything you do not need, and mask or remove the rest at the earliest safe point.

Cost

Telemetry cost is roughly the number of spans, metric series and log records, multiplied by their size and the time they are kept. Suppression reduces the first factor, often dramatically, for very little effort. Typical high-return targets are:

Keep a short list of “top ten sources of telemetry by volume” for each service, and review it every few months. Often the top two or three entries account for most of the cost, and each can be handled with a single narrow rule.

Short, direct answers to the questions beginners ask most often.

You started with a security camera that recorded the ceiling fan and ended with a full map of how to quiet OpenTelemetry instrumentation safely. Here is everything that matters in one place.

OpenTelemetry offers many switches at many layers, from turning off the whole SDK, to disabling one library, to ignoring one route, to suppressing inside a block of code, to dropping in samplers and views, to filtering in the collector. The earlier you cut, the more you save, but the greater the risk of breaking something. The wise path is to measure first, choose the narrowest switch that solves the problem, protect trace propagation, test the result and write down the reason. Done well, suppression gives you clearer traces, lower bills, better privacy and a calmer on-call life.