Application metrics help explain CPU, memory, and resource behavior across replicas. They require enabled and healthy collection.
Read a chart
Open the application metrics view, select a time range of at most 31 days, and inspect the displayed units. CPU in cores is different from a percentage relative to a limit. Memory values should be compared with both application requirements and configured limits.
Aggregated buckets can show minimum, average, and maximum values. A low average can hide a brief peak, while a maximum alone does not describe sustained load. Larger time buckets smooth short events.
Use the observations
Compare metrics before and after a release, restart, or replica change. Check the actual replica count and avoid confusing aggregate demand with per-replica utilization.
Automatic scaling requires fresh observations from all running replicas. A partial or stale series can prevent a scaling decision; missing samples are not interpreted as idle replicas.
Diagnose missing or unusual data
Confirm the application identity, selected range, collector state, storage availability, and retention. Recently enabled collection has no earlier history. Depending on storage placement and flush timing, recent data may appear after a delay.
A task that exits quickly may leave sparse observations; use logs and events as well.
Tune resource reservations and limits using representative load, and check server metrics before assuming the application alone is responsible.