Inspect distributed tracing by using Application Insights

The problem it solves

In a system of several services, a single user request touches many of them. Each service's own logs show its part; none shows the request. Distributed tracing stitches those parts into one end-to-end view.

How it works

A correlation identifier travels with the request across service boundaries, so every span — each unit of work in each service — can be attributed to the same operation. Application Insights reconstructs the tree from those spans.

The practical consequence: correlation must be propagated. A service that drops the incoming context starts a new trace, and the end-to-end view breaks precisely at that service. A gap in the trace usually means missing propagation rather than a fast service.

What it tells you

View	Answers
End-to-end transaction	Which service consumed the time
Dependency map	What calls what, as it actually behaves
Failed transaction	Where in the chain the failure originated

That last is the one worth stressing: a failure is often reported by the service the user talks to and caused several hops away. Tracing distinguishes reporting from causing — without it, teams debug the service that logged the error, which is frequently the wrong one.

With sampling

Sampling applies to traces too. Application Insights samples coherently so a retained operation keeps its related telemetry, rather than leaving half a trace — but a specific transaction may still be absent entirely.

Primary sources