VMware ESXi and vSphere Cluster Management
Real-Time and Historical Performance Statistics in VMware vSphere
Learn how vSphere collects, stores, rolls up, configures, and displays real-time and historical performance statistics for ESXi hosts and virtual machines.
VMware vSphere performance statistics help administrators understand how ESXi hosts and virtual machines use resources over time. Performance charts present collected measurements for resources such as CPU, memory, storage, and networking. These measurements support troubleshooting, trend analysis, capacity planning, and before-and-after comparisons.
This lesson explains the difference between recent real-time data and longer-retained historical data, how vSphere stores and aggregates each type, how to configure collection and retention, and how to choose the correct performance chart range.
Purpose of vSphere Performance Statistics
A performance statistic is a measurement associated with an inventory object. An inventory object can be an ESXi host, virtual machine, datastore, cluster, network device, or another managed resource. A performance counter is a measurable metric exposed for an object, resource category, or device instance. Examples include CPU usage, memory consumption, datastore latency, read and write throughput, and network transmit or receive rate.
Performance charts use these counters to show resource behavior over time. A chart can help answer questions such as:
- Is a virtual machine currently consuming excessive CPU?
- Does a host experience memory pressure during a recurring workload?
- Does network traffic increase during a scheduled backup?
- Has datastore latency changed after a storage configuration change?
- Is resource demand growing enough to affect capacity planning?
The same resource can look very different depending on the selected time range. A short view may expose a brief spike, while a long view emphasizes averages and recurring patterns.
Real-Time Statistics
Real-time statistics are recent, high-frequency performance measurements intended for immediate observation and troubleshooting. ESXi collects real-time host and virtual-machine statistics every 20 seconds. The real-time view covers approximately the previous hour.
Real-time data is held locally in flat-file storage on the ESXi host and in memory on vCenter Server while it is being presented through the management system. A flat file is local file-based storage rather than a relational database. Real-time data is therefore designed for current observation, not for long-term retention.
Collection Frequency, Sample Interval, and Visible Range
These terms describe different properties:
- Collection frequency: how often the source obtains a measurement. For real-time host and virtual-machine statistics, this is normally every 20 seconds.
- Sample interval: the time spacing between data points displayed or stored in a chart. A historical chart can display points at a larger interval because measurements have been aggregated.
- Visible time range: how far into the past the chart displays data. The real-time range is approximately one hour, even though its samples are frequent.
Real-time statistics are appropriate when investigating an active CPU spike, validating current workload behavior, checking whether contention is continuing, or observing a network or storage anomaly as it occurs.
Historical Statistics
Historical statistics are aggregated performance measurements retained for longer-term analysis. vCenter Server stores historical performance data in the vCenter Server database, which provides persistent storage for charts and reporting after the short real-time window has passed.
Historical data uses data rollup. A data rollup aggregates finer-grained measurements into coarser summaries. For example, several measurements collected during a five-minute period can be represented by a historical five-minute data point. Older data is progressively represented with less temporal detail so that it can remain available for longer periods without requiring every high-frequency measurement to be stored indefinitely.
Historical charts are useful for:
- Identifying daily, weekly, or seasonal workload patterns.
- Planning host, cluster, storage, and network capacity.
- Investigating recurring incidents that are no longer active.
- Comparing performance before and after a configuration or workload change.
- Creating operational reports based on longer observation periods.
Real-Time and Historical Statistics Comparison
Historical Time Ranges and Data-Point Intervals
Each historical range uses a different sample interval and retention duration. The exact availability can depend on vCenter Server configuration, but the commonly used ranges are:
- Past day: one data point every 5 minutes. A 24-hour period contains 288 five-minute samples.
- Past week: one data point every 30 minutes.
- Past month: one data point every 2 hours.
- Past year: one data point per day, producing approximately 365 samples in a year.
Long-range charts are excellent for recognizing patterns, but they are less suitable for diagnosing short-lived events. A burst lasting 30 seconds may be visible in a 20-second real-time chart and may influence a five-minute value, but it can be averaged into a 30-minute, two-hour, or daily point until it is no longer obvious.
Relationship Between Real-Time Collection and Historical Rollups
vSphere moves from fine-grained recent measurements to coarser historical summaries. High-frequency real-time samples show what is happening now. Historical rollups preserve the overall behavior of those measurements while reducing the number of stored data points needed for longer retention.
Consider a virtual machine that experiences a CPU burst for 40 seconds. The real-time chart may show two or more elevated 20-second samples. In a five-minute historical interval, the burst contributes only part of the interval and may appear as a modest average. In a daily chart, the same burst is included in a single daily aggregate and may have almost no visible effect.
The storage location also changes in importance: recent real-time data is associated with ESXi host flat-file storage and vCenter Server memory, while persistent historical statistics are stored in the vCenter Server database.
Viewing Performance Data in the vSphere Web Client
To view performance charts for a host or virtual machine:
- Select the target ESXi host or virtual machine in the inventory.
- Open its performance-monitoring view.
- Select a resource category such as CPU, memory, storage, or network.
- Choose a metric or performance counter, such as usage, latency, throughput, or a device-specific counter.
- Select the time range: real-time, day, week, month, or year.
- Review the chart timestamps, units, averages, peaks, and density of data points.
Always verify the unit before interpreting a value. CPU may be shown as a percentage or a rate, storage may use throughput or latency units, and networking may use a rate such as bits per second. A chart average describes the selected interval; it does not necessarily describe the maximum value reached inside that interval.
Compare ranges when diagnosing an issue. Use real-time data to determine whether a condition is active, the past-day view to see whether it is unusual for the current day, the past-week view to find recurrence, and longer ranges to evaluate broader capacity or growth trends.
Practical Example: Investigating an Active CPU Spike
- Open the performance view for the affected virtual machine or ESXi host.
- Select the real-time range to inspect 20-second samples from approximately the previous hour.
- Determine whether CPU activity is sustained or limited to a short burst.
- Compare the same CPU resource in the past-day view to determine whether the event is unusual.
Real-time data is the best starting point for a short-lived condition that is occurring now. If the event is no longer active, use the past-day range, while remembering that its five-minute points may smooth brief peaks.
Using Performance Statistics for Network Monitoring
Network performance charts can show throughput and activity for a virtual machine, host, virtual network adapter, physical adapter, or other available network object. Inspect transmit and receive rates, compare activity with known workload schedules, and look for periods of elevated traffic.
Use a short range, such as real-time, for an active network anomaly. Use the past-day range to identify busy periods during a normal day, then use the past-week range to determine whether those periods repeat. Relate network trends to virtual-machine workloads, host behavior, backup windows, replication, and possible network contention.
Configuring Statistics Collection and Retention
vCenter Server performance-statistics settings control how much historical metric data is collected and how long it remains available. Historical interval settings commonly define a sampling period and a retention period. The sampling period determines how frequently a historical point is created or retained for an interval. The retention period defines how long those statistics remain available.
Configuration changes should match operational requirements. More detail can improve recurring-incident investigation and reporting, but it can also increase vCenter Server database growth, processing load, backup requirements, and general management overhead. Longer retention consumes storage even when the sampling interval stays the same.
vSphere Web Client Configuration Workflow
- Locate the vCenter Server statistics or performance-statistics settings in the vSphere Web Client.
- Review the configured historical intervals, sampling periods, and retention periods.
- Identify the metrics and time period required for troubleshooting, reporting, compliance, or capacity planning.
- Adjust the sampling or retention settings only as needed.
- Set the appropriate statistics collection level.
- Document the previous values and estimate the expected database and processing impact before making a production change.
- Save the configuration.
- Allow sufficient time for newly configured statistics to be collected, then verify that the desired chart range and counters are available.
Do not expect a configuration change to create historical data retroactively. A new level or interval affects data collected after the change, subject to the applicable vCenter Server behavior and rollup process.
Statistics Collection Levels
The statistics collection level is the vCenter Server setting that controls the breadth and detail of performance counters retained for historical reporting. Higher levels collect more counters and instances, enabling richer analysis. They also increase database storage, processing, and operational overhead.
- Lower levels: generally suitable for baseline monitoring and routine reporting.
- Higher levels: useful when detailed diagnostics require additional counters or device instances.
- Selection principle: choose the lowest level that meets reporting, troubleshooting, compliance, and capacity-planning requirements.
Statistics collection level is not the same as logging level. Collection level controls performance-counter retention. Logging level controls the verbosity of diagnostic log messages. Increasing logging verbosity does not add historical performance counters, and increasing statistics collection does not make diagnostic logs more detailed.
Historical Statistics Configuration Trade-Offs
Choosing the Correct Performance Time Range
Practical Example: Finding a Daily Network Usage Pattern
- Open host or virtual-machine network performance metrics.
- Use the past-day range and inspect its five-minute data points.
- Identify recurring busy periods and compare them with known workload schedules.
- Use the past-week range to determine whether the pattern repeats across days.
The daily view provides enough detail to connect traffic with schedules, while the weekly view helps distinguish a one-time event from a recurring pattern.
Practical Example: Why a Brief Incident Is Absent from a Yearly Chart
- Compare a real-time or past-day chart with the past-year chart.
- Note that the yearly view uses daily aggregated points.
- Explain that a brief spike contributes only a small part of a daily aggregate and can therefore be diluted or obscured.
Long retention necessarily comes with lower temporal detail. Use the shortest range that still covers the question being investigated.
Operational Limitations and Troubleshooting
A Spike Appears in Real-Time but Not in Historical Charts
Likely causes include an event shorter than the historical aggregation interval or a spike averaged into a five-minute, 30-minute, two-hour, or daily sample.
- Use real-time or past-day data for short-duration incidents.
- Capture supporting evidence while the issue is occurring.
- Consider more detailed historical collection if the incident recurs and the operational value justifies the added overhead.
Expected Historical Metrics or Detailed Counters Are Unavailable
Possible causes include an insufficient statistics collection level, retention that is too short, or a recent configuration change for which sufficient data has not yet been collected.
- Review the required metric and its collection-level requirement.
- Review sampling and retention settings.
- Increase collection detail only after assessing database impact.
- Wait through the applicable collection interval and then validate the chart again.
A Chart Has Too Few Points or Looks Too Smooth
A long-range historical view with coarse aggregation may be selected, or the incident may be shorter than the selected sample interval.
- Select a shorter time range.
- Use real-time data for active conditions and past-day data for recent events.
- Correlate with logs and other monitoring sources when historical resolution is insufficient.
Historical Statistics Are Missing or Incomplete
Check whether retention removed older data, whether vCenter Server database availability or collection problems affected persistence, and whether the object was unavailable or unmanaged during the period.
- Confirm the selected time range and retention policy.
- Check vCenter Server health and database-related monitoring.
- Confirm host and virtual-machine management connectivity for the affected period.
- Verify that the object was managed by vCenter Server when the expected data should have been collected.
Real-time availability also depends on the host and vCenter monitoring path being operational. Before drawing a conclusion, confirm the selected time range, metric, units, object, and aggregation behavior.
Planning Increased Historical Detail
- Identify the metrics and time period needed for recurring troubleshooting.
- Review the existing historical interval, retention period, and statistics collection level.
- Estimate the impact of retaining more data or collecting more counters and instances.
- Apply the change through vCenter Server statistics settings.
- Allow time for the newly configured data to accumulate.
- Verify that the expected counters and chart ranges are available.
Use the smallest increase that solves the operational problem. A targeted change is easier to size, validate, back up, and maintain than collecting every available counter indefinitely.
Key Exam and Operations Notes
- Real-time statistics are recent, high-frequency measurements, normally collected every 20 seconds and displayed for roughly one hour.
- Historical statistics are aggregated, longer-retained measurements stored in the vCenter Server database.
- Real-time data is associated with ESXi host flat-file storage and vCenter Server memory; historical data is persistent in the vCenter Server database.
- Common historical intervals are 5 minutes for the past day, 30 minutes for the past week, 2 hours for the past month, and 1 day for the past year.
- Aggregation can hide short-lived spikes, so use real-time or shorter historical ranges for incident diagnosis.
- Statistics collection level controls performance-counter detail; logging level controls diagnostic log verbosity.
- Higher collection detail and longer retention improve analysis but increase database and processing overhead.
- After changing settings, allow sufficient collection time before validating the result.
Summary
vSphere performance statistics provide a time-based view of resource behavior for ESXi hosts, virtual machines, and other inventory objects. Real-time statistics are best for observing active conditions with 20-second samples over approximately one hour. Historical statistics are retained in the vCenter Server database and rolled up into progressively coarser intervals for day, week, month, and year views.
Choose the time range according to the question: recent high-frequency data for active incidents, daily or weekly data for workload patterns, and monthly or yearly data for capacity and growth analysis. Configure collection levels, sampling intervals, and retention periods deliberately because additional detail consumes database storage and management resources.
For related study, see Real-Time and Historical Statistics.