CPU and available memory per instance as a timechart

let lookback = 24h;
performanceCounters
| where timestamp > ago(lookback)
| where counter in ("% Processor Time Normalized", "Available Bytes")
| summarize
    cpu_pct = avgif(value, counter == "% Processor Time Normalized"),
    available_gb = avgif(value, counter == "Available Bytes") / 1e9
    by bin(timestamp, 5m), cloud_RoleInstance
| order by timestamp asc
| render timechart

How it works

When one instance is slower than its siblings, the first suspects are CPU and memory. The performanceCounters table holds them: one row per counter per instance at a regular interval, with the category, counter and instance names split into their own columns and the reading in value.

Line by line

• where counter in (...) keeps two counters: % Processor Time Normalized (the process’s CPU use divided by the logical processor count, as Microsoft defines it) and Available Bytes (free physical memory on the machine). Both are in Microsoft’s default counter lists for ASP.NET and ASP.NET Core, and in the set the Distros export to this table.
• avgif(value, counter == "...") averages each counter’s readings separately in the same summarize, so both end up as columns on one row.
• available_gb divides bytes by 1e9 so memory and CPU sit on comparable scales on one chart.
• by bin(timestamp, 5m), cloud_RoleInstance gives one point per instance per 5 minutes. cloud_RoleInstance is the machine or container, not the counter’s own instance column, which Microsoft notes usually holds a process or application name.
• render timechart draws a CPU line and a memory line for each instance.

Which counters do you have?

Microsoft’s own starting point for this table is a list of what is there:

let lookback = 24h;
performanceCounters
| where timestamp > ago(lookback)
| summarize readings = count(), avg_value = avg(value) by category, counter, instance

Classic Windows performance counters appear only where the SDK can read them; cross-platform .NET apps report event counters instead, and some platforms report fewer. The performance counters guide explains which collector produces what, including for console and worker apps.

Reading the chart

CPU pinned near 100 on one instance while the others idle points at that instance’s workload: a stuck thread, a hot partition, a noisy neighbour. Available memory falling steadily until a restart is the shape of a leak. Compare the instance with request latency by cloud role and find which version it runs with cloud role instances and versions.

Variations

• One measure per chart: drop one of the two avgif() lines; with many instances, two lines each gets crowded.
• Workspace tables: use AppPerformanceCounters, TimeGenerated, Counter, Category, Instance, Value and AppRoleInstance.