CPU 스파이크 예측

Predictive System Health Checks: What I Learned Testing ARIMA, SARIMA, and Prophet on Infrastructure Metrics

When building a system health check layer, knowing the current CPU, memory, or disk usage is only half the battle. If your dashboard says “CPU is at 85%,” you are missing critical context. Is that a normal Tuesday morning spike? Or is it a runaway process that will crash the server in twenty minutes?

To build an intelligent, predictive health check layer for my application, I decided to move past reactive thresholds. I ran a series of head-to-head experiments using three heavy hitters in time-series forecasting: ARIMA, SARIMA, and Facebook Prophet.

I tested them against diverse, real-world infrastructure shapes—ranging from daily 9-to-5 spikes to slow-burning memory leaks.
Here is a deep dive into what worked, what failed, and how data frequency and history length completely change the game.

The Tech Stack & Test Dataset Shapes
To see where each model shined or sputtered, I evaluated them on three core infrastructure metrics: CPU (highly volatile), Memory (gradual/stepped), and Disk Space (linear growth).
I fed these metrics into three statistical frameworks:

ARIMA (Autoregressive Integrated Moving Average): The classic baseline. Best for short-term, non-seasonal trends.
SARIMA (Seasonal ARIMA): ARIMA’s older sibling. It adds seasonal parameters to capture repeating cycles (like a 24-hour day).
Prophet: An additive model optimized for business time series with strong seasonal patterns and multiple curve shifts.

I threw five distinct data anomalies and patterns at these models to see how they would react:

1. Daily Workday Spike: (High usage 9-to-5, dead at night)
2. Gradual Linear Creep: (Slow, steady memory or disk growth)
3. Once-a-Month Spike: (Monthly cron jobs or payroll processing)
4. Random Spike: (Unpredictable traffic/DDOS bursts)
5. Smooth Wave Pattern: (Usual gradual increase/decrease)

Performance Breakdown: Which Model Won?

Pattern 1: Gradual Increases & Memory Creeps
Winner: Prophet
The Reality: Prophet knocked this out of the park. When an application has a slow memory leak or a steady growth in disk usage, Prophet isolates the structural trend line beautifully from day-to-day noise. It handles non-linear growth curves without overreacting.
The Losers: ARIMA and SARIMA tend to “flatline” too early or get heavily distorted by minor short-term fluctuations, missing the macro-trajectory of a slow-burn failure.

Pattern 2: Daily Workday Spikes (Hourly Data)
Winner: SARIMA
The Reality: When infrastructure metrics strictly adhere to human schedules (e.g., traffic surges at 9 AM and drops at 6 PM), SARIMA dominates. Once you properly configure its seasonal period parameter (s=24 for hourly data), it locks onto the daily pattern with razor-sharp precision.
The Runner-Up: Prophet performs adequately here, but it tends to slightly smooth out the sharp peaks, making its maximum capacity forecasts a bit too conservative for infrastructure alerting.

Pattern 3: Once-a-Month Spikes
Winner: None (Structural Failure)
The Reality: Every model failed here unless given years of data. If your dataset only spans 3 months, a monthly cron job or billing cycle only appears 3 times. Statistical models cannot confidently separate a 3-occurrence spike from a random outlier. They either ignore the monthly spike entirely or treat it as a trend disruption.

Pattern 4: Random Spikes & Traffic Bursts
Winner: None
The Reality: Time-series forecasting models assume the future is a function of the past. A completely random spike (like a sudden micro-burst of traffic or a rogue script execution) breaks these models completely.
The Danger: ARIMA and SARIMA are especially vulnerable here; they often interpret a massive random spike as the beginning of a major upward trend, leading to wild, panicked forecasts for the subsequent hours.

The Hidden Variable: Data Frequency vs. History Length
One of my biggest takeaways was that the math doesn’t matter if your data granularity is wrong. I observed a direct trade-off between the frequency of data collection and the historical window used for training:
Scenario A: Every hour for the last 1 week

Best for: Identifying intra-day cycles and immediate next-hour alerts.
The Problem: The model becomes blind to long-term trends. It assumes the world resets every Sunday night. If your memory is gradually creeping up week-over-week, this training window will completely miss it.

Scenario B: Every 12 hours for the last 3 months

Best for: Macro-capacity planning, disk space runway prediction, and tracking monthly baselines.
The Problem: You lose all fine-grained peak visibility. A critical, high-intensity CPU spike that lasts for 2 hours gets completely smoothed out and averaged into oblivion. The model will tell you your system is perfectly fine when it is actually choking during peak hours.

Practical Engineering Takeaways
If you are looking to build predictive alerts or trend graphs into your own applications, save yourself some time and follow these engineering rules:

1. Decouple Your Models: Do not use a single model for your system health dashboard. Use Prophet to track slow-moving variables like disk allocation and memory creep. Use SARIMA to forecast highly cyclical, usage-dependent patterns like CPU spikes.
2. Sanitize Your Data Before Training: Because random spikes break statistical models, you must clean your training data. Apply a rolling median filter or a simple outlier truncation step to strip out random 1-minute 100% CPU spikes before feeding the data to the model. Otherwise, your model will spend days forecasting “ghost” anomalies.
3. Align Granularity to the Goal: If you want to prevent out-of-memory (OOM) crashes today, train an hourly model on a 14-day history. If you want to know when to upgrade your AWS EBS volumes, train a 12-hour aggregated model on a 6-month history.

What are you using?
Building an automated predictive system is iterative, and no statistical model fits perfectly out of the box without tweaking parameters.
Have you tried building time-series forecasting into your DevOps or application monitoring stack? Do you lean toward classic stats models, or have you migrated to deep learning solutions? Let’s discuss in the comments below!