Dependency calls per request, by operation

let lookback = 24h;
let calls = dependencies
    | where timestamp > ago(lookback)
    | summarize dependency_calls = sum(itemCount) by operation_Name;
requests
| where timestamp > ago(lookback)
| summarize requests = sum(itemCount) by operation_Name
| join kind=leftouter calls on operation_Name
| extend dependency_calls = coalesce(dependency_calls, 0)
| extend calls_per_request = round(todouble(dependency_calls) / requests, 1)
| project operation_Name, requests, dependency_calls, calls_per_request
| order by calls_per_request desc

How it works

The classic performance bug is an endpoint that makes one database call per item in a list: fast in development with three items, slow in production with three hundred. Latency charts show the symptom; this query shows the cause, as a plain number of calls per request.

Line by line

• let calls = ...; sums dependency calls per operation_Name, sampling-adjusted. The data model says every telemetry item inherits the operation name from the request or page view that created the operation, so a dependency recorded while handling GET /orders carries that name.
• The main query sums requests per operation_Name the same way.
• join kind=leftouter calls on operation_Name keeps every request operation, including those that made no calls at all.
• coalesce(dependency_calls, 0) turns “no match” into zero, so those rows read 0 rather than empty.
• todouble(...) / requests divides as real numbers; integer division would round 2.6 calls per request down to 2.
• order by calls_per_request desc puts the chattiest endpoints first.

Check the operation name first

The join only works when dependencies carry an operation name. Microsoft lists a known issue for the OpenTelemetry exporters: the operation name is missing from dependency telemetry. Check before trusting a page of zeros:

let lookback = 24h;
dependencies
| where timestamp > ago(lookback)
| summarize calls = sum(itemCount), without_name = sumif(itemCount, isempty(operation_Name))

If most calls lack a name, group dependencies by operation_Id and join to requests on operation_Id instead, keeping cloud_RoleName in both keys so one service’s calls aren’t attributed to another.

Reading the result

Ten or more calls per request on a busy route is worth a look; hundreds is almost always a loop. Take the route into SQL dependency duration by name or outbound HTTP calls by target to see which dependency it hammers. The agent-based dependency tracking guide explains which calls are recorded at all, because an uninstrumented client makes a route look quieter than it is.

Variations

• Workspace tables: use AppRequests and AppDependencies, TimeGenerated, OperationName and ItemCount.