operation_Id

A request that calls two APIs and a database, logs three lines and throws one exception writes eight rows across requests, dependencies, traces and exceptions. They all share one operation_Id, which is how the portal’s end-to-end transaction view and your own queries put them back together. operation_ParentId on each row points at the item that caused it, so the rows form a tree.

Microsoft’s OpenTelemetry migration guide maps the old names onto the standard ones: Operation ID is the trace ID, and the ID or Operation Parent ID is the span ID. Recent classic .NET SDKs use W3C Trace Context by default, so the value travels between services in the traceparent header. In the W3C specification’s example header, 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01, the second field is the trace ID, and that is the value to search for:

let opId = "4bf92f3577b34da6a3ce929d0e0e4736";
union requests, dependencies, traces, exceptions
| where timestamp > ago(1d)
| where operation_Id == opId
| project timestamp, itemType, name, message, operation_ParentId
| order by timestamp asc

In a Log Analytics workspace the columns are OperationId and ParentId. Sampling keeps operations whole, so a kept request still comes with its dependencies and logs.