Skip to content

Monitoring and Logs Updated 2026-05-27

Statistics monitoring

Per-node RAM, CPU, disk, network, and IOPS metrics — what they mean, how the platform aggregates them, and how to read the I/O graph in particular.

The statistics view is where you see what an environment is actually doing. Every container — application server, balancer, web server, database, storage — has its own statistics tab in the dashboard, reachable from the Statistics button next to the node (or next to a layer, for the aggregated view).

The view covers five metrics, each with the container’s current limit drawn alongside the consumption line so you can see how close you are to the ceiling.

Metrics

  • RAM — memory consumption in MiB. The limit is a function of the container’s reserved + dynamic cloudlets.
  • CPU — processor load in MHz. The limit follows the same cloudlet model.
  • Network — internal and external traffic in MB. Network is bounded as a per-second throughput cap (Mbps on external traffic), not as a total usage cap.
  • Disk — stored data in MB. The limit is the disk size configured for the container, within the region’s allowed range.
  • IOPS — disk I/O operations per second. The limit is set at the region level.

You can vary the Interval (how granular each point is) and Duration (how far back the window goes) at the top of the panel, and toggle individual metric sections on or off to focus.

How aggregation works

The platform samples every container’s metrics once a minute and keeps the minute-level data for one hour. After that, samples are aggregated into one-hour blocks, using one of two methods depending on the resource type:

  • Sum for CPU, Network, Disk IOPS, and Disk I/O. The hour block’s value is the total over the hour.
  • Maximum for RAM and Disk. The hour block’s value is the peak observed during the hour.

This split matters when you read a graph over a long window. A CPU spike that lasted one minute is visible at minute granularity, but at hour granularity it shows up as a bump in the hour-sum line — not as a peak. RAM behaves the opposite way: the line over a long window shows the worst minute in each hour, not the average.

Reading the I/O graph

IOPS — input/output operations per second — measures how many discrete reads and writes the storage backing your container is handling. It is the single best indicator of whether the container is constrained by storage performance, not by storage size.

Three things to keep in mind when reading the I/O graph:

  1. There is a hard limit, drawn as a red dotted line at the top. Crossing it does not crash anything, but it does mean further I/O is throttled — your application will see additional latency on disk operations until the rate drops back below the line.
  2. The IOPS limit scales with the Interval. If the per-minute limit is 6,000 IOPS, the per-hour limit is 6,000 × 60 = 360,000. The same “limit” line moves proportionally as you change the interval.
  3. Hovering over a point gives you the exact numbers. The tooltip shows the timestamp, the disk space used, the disk space limit, the IOPS over the interval, and the IOPS limit over the interval. The Disk and IOPS limits share the Limit entry in the legend; the actual values are on the left axis (disk) and the right axis (IOPS).

A container that runs consistently near the IOPS line is a candidate for either scaling out (spread the I/O across more nodes) or query/storage optimization (reduce the I/O each node does). Reading the graph tells you which.

What the numbers tell you

Statistics are operational, not just informational. The same data shows up in two other places:

  • Load alerts — you can trigger notifications when any of these metrics crosses a percentage of the limit, sustained for a window.
  • Scaling decisions — when you adjust the reserved or scaling limits for a node, the statistics view tells you whether your guess is reasonable. If RAM consistently sits at 90% of the reserved cap, the reserved figure is probably too low.

Windows containers

IOPS statistics are not collected for Windows-based nodes at the moment. The other four metrics (RAM, CPU, network, disk usage) work normally on Windows. If you need IOPS visibility on a Windows workload, the workaround is to surface Performance Monitor counters into your own observability stack.

Where to go from here

  • Load alerts — turning these metrics into actionable notifications.
  • Monitoring consumed resources — using the same data to track current usage against configured limits.
  • Log files — the log side of the same view.