How do the instruments and block_instruments arguments of Traceloop.init() control OpenLLMetry?

## Default: everything installed is instrumented `Traceloop.init()` with no instrumentation arguments enables every instrumentor whose package is present. That is the right default for a one-line integration, and for most applications it never needs touching. The two arguments exist for the cases where "everything" is the wrong answer. ## Allowlist versus blocklist ``` from traceloop.sdk.instruments import Instruments Traceloop.init(app_name="rag-api", instruments={Instruments.OPENAI, Instruments.LANGCHAIN}) Traceloop.init(app_name="rag-api", block_instruments={Instruments.ANTHROPIC}) ``` `instruments` is exclusive: pass it and *only* those instrumentors run, no matter what else is installed. `block_instruments` is subtractive: everything runs except the named ones. They express opposite defaults for future libraries — with an allowlist, a library someone adds next quarter is silently untraced; with a blocklist, it is traced automatically. That asymmetry is the whole basis of choosing between them, and it is what a senior answer should lead with: use the blocklist unless you have a positive reason to freeze coverage. ## Reason one: span volume and cost An agent loop with a chatty framework can emit dozens of spans per request, many of them internal framework bookkeeping with no diagnostic value. Ingest is usually billed by volume, and a trace nobody can read is not observability. Blocking one noisy instrumentor is a blunt but effective control at the source. The more precise alternative is filtering or sampling downstream in a collector, which keeps the option of turning detail back on without a redeploy — the tradeoff is that you pay to ship the data before you drop it. ## Reason two: duplicate instrumentation This is the failure that actually shows up in production and the one interviewers like. If the same library is patched twice — because you already run the standalone `opentelemetry-instrumentation-*` package for it, or because your framework emits its own spans for the same call, or because another vendor's agent auto-instruments on startup — you get two spans for one call. The visible symptoms are duplicated cost and token figures, nested spans that look like retries that never happened, and latency percentiles computed over double the events. Blocking one side is the fix; deciding *which* side to keep is a judgment call based on which produces the richer attributes and which your dashboards already key on. ## Reason three: containment during upgrades Instrumentation is version-coupled: an instrumentor patches specific methods of a specific client, and a major client release can move or rename them. The result is a package that errors on patching, produces spans missing key attributes, or, in the worst case, interferes with the library. Blocking that one instrumentor keeps the rest of your LLM tracing alive while you pin versions or wait for a fix — far better than ripping out the SDK because one dependency moved. ## Operational consequences to state out loud - **Blocking is silent.** A blocked library produces no spans and no warning. Six months later someone debugs "why has our vector store no latency data" and the answer is a line in `init` nobody remembers. Comment the reason next to the argument and give it an expiry. - **Blocking is not a privacy control.** Turning off an instrumentor removes the whole span, including latency and error signal, which is a heavy price to avoid recording content. Content capture has its own switch; use that instead when the concern is what is *inside* the span. - **Environment-varying sets are a debugging trap.** If staging traces a library that production blocks, your "it works in staging" investigations start from different data. Keep the set identical unless you have a specific reason. - **Not installed is not the same as blocked.** If the instrumentation package for a library is absent, it is untraced regardless of these arguments. When spans are missing, check installation before you go looking for a blocklist. ## How to answer the question well A weak answer stops at "it turns instrumentation on and off". A strong one names the allowlist/blocklist asymmetry, gives duplicate instrumentation as the concrete production case, notes that blocking is silent and needs a comment and an expiry, and separates volume control (which may belong in a collector) from privacy control (which belongs in the content-capture setting, not here).