​
Overview

Titled Performance Metrics — “Real-time performance monitoring and resource utilization”. Four charts for one machine.
Navigation: Compute → Virtual Machines → click a machine → Monitoring.

​
The charts

Each shows No data available when there’s nothing to plot.
The two-series charts are the useful ones. In far exceeding Out on a web server is backwards and worth investigating; Write pinned flat while Read spikes usually means a caching problem rather than a disk problem.

​
Time range

Last Hour, Last 6 Hours, Last 24 Hours, Last 7 Days.

​
Refreshing

There is no auto-refresh on this section. The Refresh button is the only thing that updates it.A chart left open shows data from whenever you loaded the page. During an incident this is a genuine trap — you can be staring at a five-minute-old picture while deciding what to do. Click Refresh before drawing a conclusion.

​
What the resolution limits

Metrics are collected every five minutes, aggregated by whichever window you pick, and retained for 30 days. The page states this at the bottom.Two consequences:A spike shorter than five minutes may not appear at all. If a machine froze for 90 seconds, these charts probably won’t show it. Use Events and Jobs for short-lived incidents.Anything older than 30 days is gone. For longer trends, export what you need before it ages out.

​
When metrics aren’t available

If collection isn’t configured you get Metrics Unavailable with a Retry button and this hint:
Contact your administrator to enable CloudStack metrics collection or configure a metrics backend.
That’s a platform configuration matter, not something you can fix from the console. The rest of the machine’s sections work normally — only these charts depend on it.

​
Common task: decide whether a machine is the wrong size

1

Set the range to Last 7 Days

A day tells you about yesterday; a week tells you about the machine. Anything shorter and you’ll be fooled by a quiet afternoon.
2

Refresh, then read the average badges

CPU Usage and Memory Usage each show {n}% avg for the window. Remember the badge is an average — a machine averaging 20% with daily spikes to 95% is correctly sized, not oversized.
3

Look at the shape, not just the number

A flat line near the top means you’re capped and should scale up. A flat line near the bottom means you’re paying for headroom you never use. A sawtooth means periodic load, which is a case for autoscaling rather than a bigger machine.
4

Check Disk I/O before blaming CPU

Low CPU with heavy, sustained Read usually means the machine is waiting on storage. A bigger compute offering won’t help; faster or larger storage might. See Volumes.
5

Scale from the header, with the machine stopped

Scale on the machine’s header. It’s blocked entirely while the machine holds VM snapshots — delete those first. See Virtual Machines.

Overview tab

The three at-a-glance metric cards.

Events tab

Short incidents the charts are too coarse to show.

AutoScaling Groups

When the answer is more machines, not a bigger one.