KQL · usage
Requests per day by cloud role
Daily request volume for each service sending to the resource over the last 14 full days, sampling-adjusted, as a column chart.
requests usage
let lookback = 14d;
requests
| where timestamp >= startofday(ago(lookback)) and timestamp < startofday(now())
| summarize requests = sum(itemCount) by bin(timestamp, 1d), cloud_RoleName
| order by timestamp asc
| render columnchartReturns: One column per day for the last 14 complete days (UTC), split by cloud role name, showing each service's sampling-adjusted request count.
Pitfalls
- Days are UTC days. For a team in UTC-8, a 'day' here runs from 16:00 to 16:00 local time.
- Today is left out on purpose, because a partial day always looks like a drop. Remove the second time condition to include it.
- Count with sum(itemCount). With adaptive sampling a raw row count flattens out as traffic grows, exactly when you want to see growth.
- Health probes and availability tests are requests too. Filter them out by operation_Name or with isempty(operation_SyntheticSource) to see user traffic.
How it works
Traffic per service per day is the simplest capacity and usage chart there is, and the one people keep asking for: is the new API getting traffic, did the weekend dip as usual, which service carries most of the load. It also tells you where your telemetry volume comes from, because more requests mean more requests, dependencies and logs to pay for.
Line by line
let lookback = 14d;covers two weeks, enough to compare each weekday with the same day last week.timestamp >= startofday(ago(lookback))starts at midnight UTC 14 days ago, so the first day is complete.timestamp < startofday(now())stops at midnight UTC today. Kusto datetimes are always UTC.requests = sum(itemCount)counts requests the sampling-aware way. Adaptive sampling keeps a roughly steady number of rows per second as traffic grows, so counting rows would hide growth.by bin(timestamp, 1d), cloud_RoleNamegives one row per day per service. The day comes first because the chart takes its x-axis from the first column.render columnchartdraws one group of columns per day, one column per role.
Reading the chart
Look for steps rather than spikes. A role whose volume doubled overnight and stayed there has a new caller, a retry loop or a new client release. A role that dropped to near zero may have lost its telemetry rather than its traffic: compare with your load balancer’s numbers, and see the no data checklist if the drop is real only in Application Insights.
If several services show up as one role, or a role is empty, the role names need setting; the initializers and processors guide shows how. For the cost side of the same picture, telemetry volume by table shows billed gigabytes rather than request counts.
Variations
- Stacked: use
| render columnchart with (kind=stacked)to read the total and the split at once. - User traffic only: add
| where isempty(operation_SyntheticSource)to drop traffic the SDK marked as synthetic, such as availability tests. - Workspace tables: use
AppRequests,TimeGenerated,ItemCount,AppRoleNameandSyntheticSource.