Introduction

Capacity planning asks when a system will stop meeting demand, not only whether it is healthy today. Good planning combines historical measurements, business events, and a clear safety margin.

What you should be able to do after this lesson:

Select metrics that represent real capacity.
Store and graph measurements over time.
Separate trends from temporary spikes.
Estimate when a resource will reach an operational threshold.
Recommend an upgrade, cleanup, or architecture change early enough.

Big Idea: Forecast the Limit That Users Will Notice

A capacity limit is not always 100 percent utilization. A service may violate its latency target at 70 percent CPU, a filesystem may need 15 percent free space for maintenance, and a network link may become unreliable during bursts before its hourly average looks high.

Capacity planning therefore connects four values:

current demand
growth rate
operational limit
lead time required to act

The output should be a decision date, not merely a graph.

Choose Meaningful Metrics

Track resources that can constrain the service:

CPU utilization and run queue
available memory, swap activity, and process growth
filesystem use, inode use, IOPS, latency, and queue depth
interface throughput, packet loss, and connection count
application-specific work such as requests, jobs, users, or database transactions

Percentages without workload context are weak. For example, requests per second and response time explain more than CPU usage alone.

Collect Consistent History

One sample cannot reveal a trend. Use the same interval and labels so measurements can be compared.

Common tools include:

sar from sysstat for historical system activity
collectd for periodic metric collection
monitoring systems such as Icinga or Nagios for checks and alerts
graphing systems such as MRTG or Cacti for trends

Modern monitoring stacks can serve the same purpose, but the exam focus is the method: collect, retain, graph, and alert.

sar -u
sar -r
sar -d
sar -n DEV

The named tools serve different roles:

collectd gathers metrics at regular intervals.
Icinga2 and Nagios evaluate checks and raise alerts.
MRTG and Cacti are traditionally associated with storing and graphing time-series network or system data.

Exact products change, but an exam scenario still expects you to distinguish collection, visualization, threshold evaluation, and notification.

Trend, Seasonality, and Peaks

Distinguish three patterns:

trend: long-term growth or decline
seasonality: repeated daily, weekly, or monthly behavior
spike: a short exceptional event

Provisioning from a quiet average can fail during peak hours. Compare matching periods, such as Monday morning with previous Monday mornings.

Estimate an Exhaustion Date

Suppose a filesystem contains 600 GiB, grows by 20 GiB per month, and should not exceed 85 percent. The operational limit is 510 GiB. If 410 GiB is used, 100 GiB remains before the limit, or roughly five months at the current rate.

This estimate is only a starting point. Growth may accelerate, retention policies may change, and an upgrade may require procurement time.

Define Thresholds and Lead Time

The technical maximum is rarely the correct alert threshold. Leave room for:

workload bursts
maintenance operations
data migration
hardware delivery
rollback and testing

Use warning and critical thresholds. A warning should arrive while there is still time to act.

Capacity Responses

More hardware is not the only answer. Possible actions include:

deleting or archiving old data
changing retention policies
optimizing a query or application
distributing work across systems
adding caching
scheduling heavy jobs outside peak periods
increasing CPU, RAM, storage, or bandwidth

Guided Practice: Build a Simple Forecast

Choose a noncritical filesystem and record its used space once per day for at least a week:

date -Is
df -B1 --output=source,size,used,avail,pcent,target /srv/data

For a short exercise, use three sample measurements:

Day 1: 400 GiB used
Day 8: 414 GiB used
Day 15: 428 GiB used

The observed rate is approximately 2 GiB per day. If the operational limit is 500 GiB, the remaining 72 GiB provides about 36 days at that rate. If procurement and migration require 21 days, the useful decision window is only about 15 days.

Now challenge the estimate:

Was a backup or import responsible for unusual growth?
Does growth repeat weekly or accelerate?
Are inode limits closer than byte capacity?
Will a planned release change demand?

Record the assumptions beside the forecast. A number without its assumptions cannot be reviewed later.

Troubleshooting Scenario

A monitoring graph predicts six months before a filesystem reaches 90 percent, but it contains only monthly averages. Daily data reveals a large weekly import followed by partial cleanup. The average hides a peak that will exceed available space in three weeks.

The correction is to retain higher-resolution data, graph peak usage, and model the workload cycle. Capacity planning must protect the system during the peak, not only at the average.

Exam Focus

Growth requires historical, consistently collected data.
Distinguish trend, seasonality, and one-time spikes.
Know the awareness-level roles of Icinga2, Nagios, collectd, MRTG, and Cacti.
Include operational thresholds and implementation lead time in a forecast.

Common Mistakes

Keeping too little history to see seasonal behavior.
Predicting from one unusually busy day.
Tracking utilization without latency or workload.
Alerting only at 100 percent.
Ignoring the time needed to implement the solution.

Recap

Capacity planning converts historical measurements into an action date.
Track workload, utilization, and service quality together.
Account for trends, seasonality, peaks, and implementation lead time.
Revisit forecasts as new measurements arrive.

200.2 Predict Future Resource Needs