A partial trace does not prove the business operation stopped
Distributed tracing records observations from several services under a related context. Sampling deliberately retains selected telemetry, while propagation connects one service's activity to another. A missing span can therefore reflect a tracing contract problem even when the downstream business operation completed.
This guide investigates Application Insights with an OpenTelemetry-based collection path. Defaults vary by language, distribution and version, so record the actual instrumentation rather than assuming one sampling percentage applies everywhere. Telemetry completeness and business correctness remain separate questions.
Setup: map propagation and sampling at each hop
Choose one supported test operation and identify its participating services. Record instrumentation versions, sampling strategy, configured rate, propagation format and export destination for each. Note gateways or asynchronous messaging boundaries that may require explicit context handling.
A diagnostic matrix can begin with:
Service and instrumentation version:
Inbound context and parent relationship:
Sampling strategy and decision propagation:
Exporter and destination:
Local operation evidence and trace identifier:
Use sanitized identifiers and controlled test data. Avoid logging tokens, authorization headers or complete payloads merely to observe trace context. A privacy-safe local request record can establish that the business operation happened without copying customer content.
Illustrative incident: services make incompatible sampling decisions
In this illustrative scenario, one service uses a sampling approach that is not coordinated with its downstream service. The trace view contains a parent operation and selected later activity but lacks the expected connecting spans. Operators initially interpret the view as proof that the request never crossed the service boundary.
The team compares local operation records, propagated context and sampling configuration. It aligns the reviewed tracing contract and tests again. The example is fictional and does not claim that sampling is the cause of every missing trace.
Troubleshooting: separate operation, context and telemetry delivery
| Observation | Evidence | Boundary |
|---|---|---|
| Downstream operation exists but is not linked | Parent/context propagation | Trace relationship across the hop |
| A consistent fraction of telemetry appears | Actual sampler and version settings | Deliberate selection rather than random loss |
| Only one service has no fresh telemetry | Export errors, destination and limits | Service-specific delivery |
| Trace breaks at asynchronous work | Message context and consumer instrumentation | Correlation across execution boundaries |
Also consider filtering, service-side limits and export failures. Changing a sampler cannot fix a wrong destination or a failed exporter. Conversely, a successful exporter does not establish that related services use compatible sampling and context behavior.
Correct the instrumentation contract deliberately
Choose a supported sampling design for the deployed language and distribution, then align participating services and context propagation. Keep the rate and strategy under reviewed configuration. Do not disable all sampling indefinitely without understanding ingestion cost, limits and privacy exposure.
Maintain independent business counters or durable completion records where operational correctness requires them. A sampled trace is a diagnostic view, not the authoritative ledger for payments, jobs or customer transactions. Use that separation when responding to suspected lost work.
Verification, monitoring and SOP
Run a controlled multi-service operation and inspect expected parent relationships, local completion evidence and exported telemetry. Test an asynchronous boundary if the workflow uses one. Verify that dashboards and alert queries interpret sampled data according to their supported semantics.
An internal SLO can describe diagnostic trace coverage for a defined sample and instrumentation set; it is not an end-to-end business SLA. The SOP should record SDK versions, sampler ownership, propagation formats, exporter checks, cost controls, safe test identities and the fallback evidence used when a trace is incomplete.
See Clouvenix observability monitoring for a reviewed implementation and operational handover.
Technical reference
Microsoft OpenTelemetry sampling, Microsoft Application Insights trace-gap FAQ, Microsoft missing-telemetry investigation. Reviewed 19 October 2026; use documentation for the installed product and release.