Tracing any app with OpenTelemetry

I'd instrument every service with the OpenTelemetry SDK and framework auto-instrumentation, so HTTP and gRPC servers and clients create spans and propagate W3C traceparent automatically. In the LLM worker, I'd wrap business functions with @traceable in OTel mode and the client with wrap_openai. That way the LLM runs nest under whatever OTel span is active. All services export OTLP to a collector, which forwards to LangSmith and Tempo. Because the trace ID comes from the edge span and travels in headers, the worker's model call lands under the API's root span. I'd check the hops that auto-instrumentation misses, such as queues and custom clients, and inject and extract context manually there. Then I'd track the orphan-root rate to prove it holds.

Sourced from Docs by LangChain (MCP)

Framework auto-instrumentation in the Chat API, for example FastAPI or Express, opens an OpenTelemetry server span. Handler and helper functions decorated with @traceable become child spans carrying LangSmith run attributes such as run type, inputs and outputs. When the API calls the worker and the retriever, the propagator injects a W3C traceparent header. Those services extract it, so their spans join the same trace. Inside the worker, wrap_openai records an LLM span, and the retriever records its vector DB query as its own span. Every service batches spans and sends them over OTLP to a local Collector. The Collector redacts sensitive attributes, batches spans, and fans them out: LLM-relevant spans go to LangSmith and the full trace goes to Tempo or Jaeger, both with the same trace ID.

Sourced from Docs by LangChain (MCP)

With LangSmith tracing and OTel mode enabled, the SDK does not keep a separate context tree. It reads the active OpenTelemetry context when the decorated function starts, then creates its span as a child of whatever span is current, which here is the FastAPI server span. It also sets itself as the current span while the function runs, so nested @traceable helpers and wrapped OpenAI calls become its children. If OTel mode is off, LangSmith builds its own run tree and the server span and runs will not share a parent. That is the most common reason people see two disconnected views of one request.

Sourced from Docs by LangChain (MCP)

First, confirm that the API actually sends traceparent. Capture the outbound request and check the header. If it is missing, the HTTP client is not instrumented or the call runs outside the active context, for example in a thread pool or a fire-and-forget task that lost context. Second, confirm that the worker extracts the header before it opens its first span. Middleware order matters. Third, check that the propagators match on both sides; a W3C-only setup and a B3-only setup will not interoperate. Fourth, check the Collector filter. If the parent span was dropped from the LangSmith pipeline, the child may look like a root. Comparing trace IDs in Tempo usually shows quickly which of these it is.

Sourced from Docs by LangChain (MCP)

The collector separates the app from its backends. Services know one OTLP endpoint, and the collector holds the LangSmith API key and the project header, so credentials don't spread across every deployment. It gives me one place for policy: attribute processors for redaction, batching and retry for resilience, and separate pipelines so LLM spans go to LangSmith while everything goes to Tempo. Adding a backend, or moving between regions, becomes a config change rather than a code release. The costs are another component to run and monitor and a possible point of span loss. So I watch its queue and failed-send metrics and run it as a sidecar or agent close to the services.

Sourced from Docs by LangChain (MCP)

I treat it in layers. At the source, I avoid putting secrets in span attributes at all. I mask fields like raw user IDs or tokens before @traceable records inputs and outputs, because data that never leaves the process can't leak. In the collector, attribute processors delete or hash known keys centrally, so policy changes don't need app releases. I keep LangSmith traces useful by retaining prompts, model names, token counts and outputs that evaluators need, and by replacing identifiers with stable hashes so threads still group correctly. I'd also remember that online evaluation upgrades traces to extended retention, so whatever is stored may live longer. That's another reason to redact before ingestion, not after.

Sourced from Docs by LangChain (MCP)

wrap_openai patches the client, so every call automatically becomes an LLM-type run. It records the prompt messages, the completion, the model name and token usage in the attribute shape LangSmith expects. LangSmith can then render the call as a proper LLM run, show token counts, and let evaluators and dashboards filter on it. A hand-written span gives you timing, but you would have to map the message and usage fields yourself, keep them consistent across services, and update them when the API changes. The trade-off is that wrap_openai records full prompts by default. That makes the PII controls, at the source or in the Collector, essential rather than optional.

Sourced from Docs by LangChain (MCP)

HTTP auto-instrumentation will not help here, so the producer must inject context into the message itself. The OTel propagator writes traceparent, and tracestate if you use it, into message headers or attributes. The consumer extracts that context before it starts its processing span. Use a consumer span linked to, or parented by, the extracted context, depending on whether one message maps to one request. Many queue client instrumentations already do this. If yours does not, write a small wrapper so every team does it the same way. Then test that a message produced in a traced request yields worker spans with the same trace ID, including on retries and redeliveries.

Sourced from Docs by LangChain (MCP)

Each user turn is its own trace, which is correct because it is its own request. To group turns, attach a shared conversation identifier as metadata on the root run of every turn, using the thread or session metadata key that LangSmith recognises. The Chat API is the natural place to set it, because it already knows the conversation ID. Do not use raw user identifiers or anything personally identifying as the thread key. Use an opaque ID. Once the turns are grouped, online evaluators can run at thread level, for example to judge whether the whole conversation resolved the user's issue.

Sourced from Docs by LangChain (MCP)

Route on attributes, not on service names. Spans created by @traceable and wrap_openai carry LangSmith run attributes, so the LangSmith pipeline can keep spans that have them, plus the root request span, so the tree stays anchored. Database driver spans, HTTP client internals and runtime spans go only to the infrastructure backend. Be careful about parents: if you drop an intermediate span that LLM spans hang under, LangSmith may show orphaned or re-rooted runs. So either keep the ancestors of kept spans or decorate the intermediate functions with @traceable. Tempo receives everything after redaction, so infra engineers still see the full picture with the same trace ID.

Sourced from Docs by LangChain (MCP)

An OpenTelemetry trace with one trace ID corresponds to a LangSmith trace. Each span becomes a run, and the span's parent ID gives the run tree. LangSmith-specific attributes on the span supply the run type, such as chain, llm, tool or retriever, along with the inputs, outputs and metadata. Traces are stored in a project, which you choose with the project header on the exporter. Threads sit above traces and group several traces that share a thread or session metadata key. The infrastructure backend uses the same trace and span IDs but simply ignores the LangSmith attributes it does not understand.

Sourced from Docs by LangChain (MCP)

Sampling decisions must be made per trace, not per span. With head sampling, the root service decides and the decision travels in the traceparent sampled flag. Downstream services honour it through a parent-based sampler, so every service keeps or drops the same traces. If you want to keep all errors or slow requests, use tail sampling in the Collector. That requires all spans of a trace to reach the same Collector instance, often through a load-balancing tier keyed by trace ID. Apply the sampling before the fan-out so both pipelines see the same set. LangSmith online evaluators then add their own sampling rate on top, which is a separate choice.

Sourced from Docs by LangChain (MCP)

The SDK's batch span processor exports in the background with a bounded queue. If the Collector is unreachable, exports fail and the queue fills. Once it is full, new spans are dropped rather than blocking request threads. That is the behaviour you want: lose telemetry, not requests. Keep export timeouts short and never use a synchronous span processor in production. On the Collector side, a memory limiter protects it from overload, and sending queues with retry absorb short vendor outages. Monitor the SDK's dropped-span counts and the Collector's own metrics, and alert on export failures, so silent data loss is noticed.

Sourced from Docs by LangChain (MCP)

Only in the Collector, and injected from a secret store such as a Kubernetes secret or a vault through an environment variable that the exporter header config references. It should not be in the application services, because they export to the local Collector and never talk to LangSmith directly. That shrinks the number of places a key can leak and makes rotation a Collector redeploy instead of a fleet-wide change. Never put the key in span attributes or resource attributes, and do not log the Collector config with expanded values. Use separate keys per environment, so a staging leak cannot write into production projects.

Sourced from Docs by LangChain (MCP)

Both, for different reasons. At the source you know the semantics. You can mask emails, phone numbers or ID numbers in inputs before they are attached to the run, or turn off input and output capture for especially sensitive functions. The Collector is the central backstop. Attribute and redaction processors drop or hash known sensitive keys and patterns for every service, including ones a team forgot to configure. Relying only on the Collector means raw PII still crosses the network to it, and pattern rules miss free text. Relying only on the source means one careless service leaks. Defence in depth, plus tests that send known fake PII through and assert it never reaches either backend.

Sourced from Docs by LangChain (MCP)

I would avoid guessing and measure the inputs. Take peak requests per second and multiply by the average number of spans per request. Get that span count by tracing a sample of real requests in staging, because agent loops and retries inflate it. Then multiply by the average serialized span size, which is dominated by prompt and completion attributes on LLM spans. That gives bytes per second into the Collector. The LangSmith pipeline carries only the filtered subset and Tempo carries everything, so compute each separately. Add headroom for retries during backend outages, size the Collector's memory and queue from that figure, and validate with a load test using the batch settings you plan to run.

Sourced from Docs by LangChain (MCP)

Each exporter should have its own sending queue and retry policy, so a slow or failing LangSmith exporter backs up only its own pipeline. Tempo keeps receiving the full trace. Set bounded queues so the Collector sheds LangSmith data instead of growing memory without limit, and alert on queue size and failed sends. Check whether the failures are authentication errors, which should not be retried forever, or transient errors, which should be retried with backoff. A persistent queue on disk can carry you through longer outages if losing LLM traces is costly. The important property is that one vendor's outage never degrades the other pipeline or the application.

Sourced from Docs by LangChain (MCP)

Hash when you still need to correlate but never need the raw value. Examples are a user ID or email, where you want to see that the same user hit the same failure several times or filter a thread by user. A keyed hash, such as an HMAC with a secret held only in the Collector, prevents dictionary attacks on low-entropy values like phone numbers, which a plain unsalted hash would not. Drop when the value has no debugging use or when even a pseudonym is too risky, such as passwords, tokens, card numbers or authorisation headers. Remember that hashed identifiers can still be personal data under privacy law, so retention and access rules still apply.

Sourced from Docs by LangChain (MCP)

In LangSmith, attach online evaluators to the project with a filter and a sampling rate. The filter narrows which runs are scored, for example only root runs of the chat endpoint, or only runs with negative user feedback, or a particular model. The sampling rate controls cost when the evaluator is an LLM-as-judge. Use cheap code rules at a higher rate, such as checking for valid JSON or an empty answer, and the expensive judge at a lower rate. Thread-level evaluators can score whole conversations. Results feed dashboards, and alerts or automation rules can act on them. Remember that runs scored online get upgraded to extended retention.

Sourced from Docs by LangChain (MCP)

Online evaluator scores become feedback on runs, and LangSmith dashboards chart them over time. I would set an alert on a drop in the key evaluator's average score, or a rise in error rate or latency, on the production project. Automation rules can act on matching runs, for example sending low-scoring runs to an annotation queue for human review, adding them to a dataset, or calling a webhook that posts to the on-call channel. Tagging runs with the deployed version or prompt tag in metadata lets you filter the dashboard and tie the regression to a specific release. The same trace ID lets on-call jump into Tempo for infrastructure context.

Sourced from Docs by LangChain (MCP)

Native LangSmith tracing works well for LLM-only views, but this app is multi-service and the platform team already runs Tempo or Jaeger. With OTel, one set of instrumentation and one trace ID serve both audiences. LLM engineers see runs in LangSmith, and SREs see the same request with database and network spans in Tempo. Context propagation uses the W3C standard, which already works across languages and frameworks. Redaction and routing live centrally in the Collector instead of in every service. The cost is more moving parts: you run and monitor a Collector, and you must make sure LangSmith attributes survive the pipeline.

Sourced from Docs by LangChain (MCP)

Very little at the protocol level. That is the point of W3C Trace Context and OTLP. The Python side uses the LangSmith Python SDK with @traceable and wrap_openai. The Node side uses the LangSmith JS/TS SDK with its traceable and OpenAI wrapper equivalents, plus the Node OpenTelemetry SDK with OTel mode enabled. Both use the W3C propagator, so traceparent written by Python is read by Node. Both export OTLP to the same local Collector. Watch for drift in attribute conventions, such as metadata key names for thread IDs or tenant IDs. Put them in a shared convention document or library so the Collector filters and LangSmith views behave consistently.

Sourced from Docs by LangChain (MCP)

The LLM span must stay open until the stream finishes, not end when the first chunk arrives. Otherwise latency is wrong and the completion and token usage are missing. The OpenAI wrapper handles streaming by aggregating chunks and finishing the run at the end of the stream, but your own @traceable function that returns a generator or async iterator must also be traced in a way that covers the full iteration. Make sure token usage is actually returned for streamed calls, since some APIs need an option to include it. Also record time to first token as metadata, because users perceive that latency, not total duration.

Sourced from Docs by LangChain (MCP)

Run the services against an in-memory or local OTLP receiver, such as a Collector with a file or debug exporter, using the same processor config as production. Send a request containing known fake PII and a fake secret. Then assert on the exported spans: every span shares one trace ID, parent-child links form the expected tree across API, worker and retriever, LLM spans have model and token attributes, and none of the planted sensitive strings appear anywhere in attributes or events. Run this test whenever the Collector config or instrumentation libraries change, because upgrades often silently change header handling or attribute names.

Sourced from Docs by LangChain (MCP)

Use one project per environment per application, such as chat-prod and chat-staging, not one per service. The point of this design is that a request is one trace across services, and splitting services into separate projects would split the view. The project is set by the header on the Collector's LangSmith exporter, so each environment's Collector points at its own project with its own key. Distinguish services inside a project with metadata or the service name resource attribute. Keep experiments from offline evaluation separate from production projects so dashboards and online evaluators only see real traffic.

Sourced from Docs by LangChain (MCP)

Interesting production runs, such as low online scores, negative user feedback or flagged failures, can be routed by automation rules or annotation queues into a dataset. Reviewers in a single-run annotation queue can correct the output against a rubric and export it as a reference example. That dataset becomes the regression suite. Before changing a prompt or model, run evaluate() against it with evaluators such as code checks or an LLM-as-judge, and compare the experiment with the baseline. Because redaction happens before traces reach LangSmith, the dataset inherits the redacted inputs, which is what you want for privacy.

Sourced from Docs by LangChain (MCP)

Control volume at three layers. In the SDKs, sample by trace with a parent-based sampler, and avoid decorating tiny hot-path helpers with @traceable. In the Collector, filter non-LLM spans out of the LangSmith pipeline, truncate very large attributes such as long documents, and consider tail sampling that keeps all errors but only a fraction of successes. In LangSmith, scope online evaluators with filters and sampling rates, because LLM-as-judge calls cost money and scored traces move to extended retention. Measure spans per request and bytes per span regularly, because new agent steps quietly multiply both.

Sourced from Docs by LangChain (MCP)

Start with the Collector deployed and receiving, with only the infrastructure exporter enabled. Turn on framework auto-instrumentation and propagation service by service, and confirm in Tempo that traces connect. Next, enable the redaction processors and verify them with planted test data. Then add @traceable and wrap_openai in the worker, enable OTel mode in the LangSmith SDK, and turn on the LangSmith pipeline pointing at a staging project. Once traces look correct and redaction is proven, point the production Collector at the production project. Add online evaluators and alerts last, with low sampling rates at first. Every step can be rolled back with config alone.

Sourced from Docs by LangChain (MCP)

Traces that an online evaluator runs on are upgraded to extended retention, so they live longer than ordinary traces. For privacy, that means any data that slipped past redaction sticks around longer, which raises the stakes of getting the Collector rules right. It also affects cost and data-retention commitments you may have made to users. So scope online evaluators with filters and sampling instead of running them on everything. Make sure the retention policy you document matches what is actually stored, and have a deletion process for traces tied to a user who exercises data rights.

Sourced from Docs by LangChain (MCP)

Use run type retriever so LangSmith renders it correctly. Record the query after redaction, the index or collection name, the number of results requested and returned, and the IDs and scores of the returned documents. Document content is useful for evaluating relevance and groundedness, but it may contain customer data, so include it only if your data classification allows it, or truncate or hash it. Never record database credentials or connection strings. Duration and errors come for free from the span. With document IDs and scores, you can later build retrieval evaluators and spot whether a bad answer came from bad retrieval or bad generation.

Sourced from Docs by LangChain (MCP)

Each service timestamps spans with its own clock, so clock skew between hosts can make a child appear to start before its parent, or extend past it. Parent-child structure comes from IDs, not timestamps, so the tree is still correct. Only the timeline rendering looks odd. Fix the root cause with proper NTP time sync on all hosts. Do not try to correct timestamps in the Collector, because that hides real latency problems. When analysing latency, trust durations within a single service more than cross-service gaps.

Sourced from Docs by LangChain (MCP)

Attach an opaque tenant ID as metadata on the root run and as a span attribute, so you can filter traces, dashboards and evaluator results per tenant. Never use tenant names or customer contact details for this. Redaction rules must hold for every tenant, and some tenants may contractually forbid prompt capture. Handle that with a per-tenant flag that disables input and output recording at the source, not only in the Collector. Access to LangSmith projects and to Tempo should follow least privilege, because traces contain customer conversations even after masking.

Sourced from Docs by LangChain (MCP)

If prompts are managed in the LangSmith Prompt Hub, pull them by commit or tag at runtime and record the prompt name and commit identifier as metadata on the LLM run or its parent. Then you can filter traces and online evaluator scores by prompt version, and compare how a newly tagged commit performs against the previous one in production. The same metadata goes to Tempo, so infrastructure incidents can be correlated with prompt changes. Avoid logging the full prompt template as an attribute on every span. The commit reference is enough, and it keeps spans smaller.

Sourced from Docs by LangChain (MCP)

1. AThe LangSmith online evaluator
2. BThe wrap_openai client wrapper
3. CFramework auto-instrumentation such as FastAPI or ExpressCorrect answer
4. DThe OpenTelemetry Collector

Why: The workflow has framework auto-instrumentation open the OTel server span. @traceable functions then nest under it.

Sourced from Docs by LangChain (MCP)

1. ADirectly to Tempo
2. BTo a shared log file
3. CTo a local OpenTelemetry Collector over OTLPCorrect answer
4. DDirectly to LangSmith

Why: Services export over OTLP only to the local Collector, never directly to the vendors.

Sourced from Docs by LangChain (MCP)

1. Ax-request-id
2. BtraceparentCorrect answer
3. Cx-api-key
4. DLangsmith-Project

Why: W3C Trace Context defines traceparent, which holds the trace ID, parent span ID and flags. tracestate carries optional vendor data.

Sourced from Docs by LangChain (MCP)

1. AAdd two @traceable decorators per function
2. BConfigure one OTLP collector pipeline set with two exportersCorrect answer
3. CCall LangSmith and Tempo APIs from each handler
4. DEnable two different propagators in each service

Why: An OpenTelemetry Collector receives OTLP once and fans out through multiple exporters. Backends are added or changed in collector config, not in app code.

Sourced from Docs by LangChain (MCP)

1. AAnnotation queues
2. BPairwise experiments
3. CLangSmith tracing together with OTel modeCorrect answer
4. DPrompt Hub tags

Why: With LANGSMITH_TRACING and OTel mode both on, the SDK emits OTel spans that use the current OTel context as their parent.

Sourced from Docs by LangChain (MCP)

1. AOnly latency
2. BDatabase connection strings
3. CThe Collector's queue size
4. DPrompt, completion, model name and token usageCorrect answer

Why: The workflow states that wrap_openai records prompt, completion, model name and token usage.

Sourced from Docs by LangChain (MCP)

1. AThe model name was not recorded
2. Btraceparent was not injected by the API or not extracted by the workerCorrect answer
3. CThe online evaluator sampling rate is too low
4. DThe LangSmith project name is wrong

Why: Cross-service joining depends entirely on injecting and extracting the W3C traceparent header.

Sourced from Docs by LangChain (MCP)

1. AIt duplicates the application code
2. BIt writes to one database that both vendors read
3. CIt forwards everything only to Tempo, and Tempo forwards to LangSmith
4. DIt uses two pipelines with separate exportersCorrect answer

Why: The workflow splits spans into two pipelines: an otlphttp exporter to LangSmith and a second exporter to Tempo or Jaeger.

Sourced from Docs by LangChain (MCP)

1. ABy the Tempo service name
2. BThey are merged into one giant trace
3. CBy the dataset name
4. DBy a shared thread or session metadata key on each traceCorrect answer

Why: Threads group multi-turn conversations using a shared thread or session metadata key.

Sourced from Docs by LangChain (MCP)

1. AThe browser client
2. BEvery microservice
3. COnly the Collector, injected from a secret storeCorrect answer
4. DA span attribute on the root span

Why: Only the Collector talks to LangSmith, so keeping the key there limits exposure and makes rotation simpler.

Sourced from Docs by LangChain (MCP)

1. ASpans are sent directly to LangSmith instead
2. BNew spans are dropped without blocking requestsCorrect answer
3. CRequests block until the Collector returns
4. DThe service crashes

Why: Batch processors use bounded queues and drop spans when full, so telemetry problems do not take down the app.

Sourced from Docs by LangChain (MCP)

1. AEach service samples randomly on its own
2. BA parent-based sampler that honours the sampled flag in traceparentCorrect answer
3. CThe Collector's batch processor
4. DLangSmith online evaluator filters

Why: Parent-based samplers follow the upstream decision carried in traceparent, so every service keeps or drops the same traces.

Sourced from Docs by LangChain (MCP)

1. ABecause OTLP forbids attribute changes
2. BBecause LangSmith requires it for ingestion
3. CSo raw PII never leaves the service and semantic masking is possibleCorrect answer
4. DBecause the Collector cannot modify attributes

Why: Source redaction prevents raw PII from crossing the network and uses domain knowledge. The Collector acts as a central backstop.

Sourced from Docs by LangChain (MCP)

1. APairwise annotation queues
2. BPrompt Hub commits
3. COnline evaluators with filters and sampling ratesCorrect answer
4. Dpytest integration

Why: Online evaluators run on production runs or threads, with filters and sampling rates.

Sourced from Docs by LangChain (MCP)

1. AIn the vector database connection string
2. BIn the traceparent header
3. CAs a span attribute on every span
4. DAs an exporter header such as x-api-key on the LangSmith exporterCorrect answer

Why: The LangSmith OTLP endpoint authenticates with an API key sent as an exporter header, and the target project can also be set as a header. Keeping both in the collector config keeps them out of services.

Sourced from Docs by LangChain (MCP)

1. AThe receiver
2. BThe extension
3. CA processor such as an attributes, transform or redaction processorCorrect answer
4. DThe exporter's TLS settings

Why: Processors modify telemetry in the pipeline. Attribute, transform and redaction processors change or remove span attributes.

Sourced from Docs by LangChain (MCP)

1. AEach backend generates IDs from timestamps
2. BBoth receive the same spans, created with one propagated trace contextCorrect answer
3. CLangSmith rewrites IDs to match Tempo
4. DTempo queries LangSmith for IDs

Why: The IDs come from the instrumented services and are only forwarded by the Collector, so both backends see identical IDs.

Sourced from Docs by LangChain (MCP)

1. AA project header set on the Collector's LangSmith exporterCorrect answer
2. BThe trace ID prefix
3. CThe model name
4. DThe OpenAI organisation

Why: The LangSmith exporter sets the API key and the target project as headers.

Sourced from Docs by LangChain (MCP)

1. AIt strips LangSmith attributes
2. BIt exports on the request path, adding latency and coupling the app to the exporterCorrect answer
3. CIt disables context propagation
4. DIt cannot export OTLP

Why: A simple processor exports each span as it ends, on the calling thread. That puts export latency and failures on the request path.

Sourced from Docs by LangChain (MCP)

1. ADisabling the batch processor
2. BRaising the SDK sampling rate
3. CSeparate sending queues and retry settings per exporterCorrect answer
4. DUsing one shared exporter

Why: Separate exporter queues isolate backpressure, so one slow destination does not stall the other.

Sourced from Docs by LangChain (MCP)

1. AAll spans of a trace must reach the same Collector instanceCorrect answer
2. BEvery service must use the same programming language
3. CSpans must be exported without batching
4. DLangSmith must make the sampling decision

Why: Tail sampling decides per trace after seeing its spans, so all of a trace's spans must be routed to one instance, for example by trace ID.

Sourced from Docs by LangChain (MCP)

1. ARuns appear orphaned or re-rooted in LangSmithCorrect answer
2. BThe API key is rejected
3. CToken usage is doubled
4. DTempo loses the trace

Why: Removing a parent span breaks the visible tree in that backend, so its children lose their place in the hierarchy.

Sourced from Docs by LangChain (MCP)

1. AKeyed hashing (HMAC) with a secret held in the CollectorCorrect answer
2. BBase64 encoding
3. CPlain unsalted hashing
4. DStoring them in a separate span attribute

Why: A keyed hash cannot be reversed by dictionary lookup without the secret. Base64 is reversible, and unsalted hashes of small value spaces are easy to brute-force.

Sourced from Docs by LangChain (MCP)

1. Aevaluator
2. Bllm
3. CretrieverCorrect answer
4. Dprompt

Why: LangSmith run types include retriever for retrieval steps, which lets the UI and evaluators treat the span as retrieval.

Sourced from Docs by LangChain (MCP)

1. AA pairwise annotation queue with three experiments
2. BTempo alerts
3. COTLP retries
4. DAutomation rules routing runs to a single-run annotation queueCorrect answer

Why: Automation rules can route runs to annotation queues. Single-run queues support rubrics and export to datasets, while pairwise queues compare exactly two experiments.

Sourced from Docs by LangChain (MCP)

1. ABoth use the W3C Trace Context propagatorCorrect answer
2. BBoth call wrap_openai
3. CBoth run in the same container
4. DBoth use the same LangSmith project

Why: W3C Trace Context is language-neutral, so a traceparent written by Python is understood by Node.

Sourced from Docs by LangChain (MCP)

1. AWhen the user closes the browser tab
2. BWhen the request is sent
3. CWhen the first token arrives
4. DWhen the stream completes and usage is knownCorrect answer

Why: Ending at stream completion captures the full completion, accurate duration and token usage.

Sourced from Docs by LangChain (MCP)

1. AA new project per deployment
2. BOne project per environment, with services told apart by metadataCorrect answer
3. COne project per microservice
4. DOne project per user

Why: Splitting services into separate projects would split a single request's trace. Environment-level projects keep it whole.

Sourced from Docs by LangChain (MCP)

1. ACounting spans per second
2. BChecking the Collector process is running
3. CReviewing the Collector config by eye
4. DSending planted fake PII and secrets, then asserting they are absent from exported spansCorrect answer

Why: Only an end-to-end assertion on exported data proves that sensitive values never reach the backends.

Sourced from Docs by LangChain (MCP)

1. AIt is moved to Tempo
2. BNothing changes
3. CIt is upgraded to extended retentionCorrect answer
4. DIt is deleted immediately

Why: The reference notes state that running an online evaluator upgrades a trace to extended retention.

Sourced from Docs by LangChain (MCP)

1. AA wrong project header
2. BCollector batching
3. CClock skew between hostsCorrect answer
4. DBroken traceparent

Why: Each host timestamps its own spans. Parentage comes from IDs, so skew affects only the timeline display.

Sourced from Docs by LangChain (MCP)

1. ARecord the prompt name and commit or tag as run metadataCorrect answer
2. BUse the template's text length as the span name
3. CStore the prompt in the trace ID
4. DEmbed the full template in every span

Why: Prompts in the Prompt Hub are versioned by commits and tags, so a reference in metadata is precise and small.

Sourced from Docs by LangChain (MCP)

1. AThe user's email address
2. BThe user's phone number
3. CThe user's full name
4. DAn opaque, randomly generated conversation IDCorrect answer

Why: An opaque ID groups turns without putting personal data into trace metadata.

Sourced from Docs by LangChain (MCP)