How to Monitor Server Performance

Monitoring server performance helps you spot slowdowns, predict failures, and plan capacity before users notice problems. This guide covers the essential metrics to track, the tools you can use, and the steps to set up a practical monitoring routine—whether you manage a single Linux VPS or a small cluster.

What You’ll Need

Access to the server (SSH for Linux, RDP for Windows) with admin/sudo privileges.
A monitoring tool—either built-in OS tools (like top or Performance Monitor) or a dedicated service (like Prometheus + Grafana, Netdata, or Zabbix). Choose based on your comfort level.
A place to store historical data (if using a self-hosted tool, ensure disk space; if using a cloud service, an account).
Optional but recommended: a notification channel (email, Slack, or webhook) for alerts.

Step-by-Step

Define your baseline. Before you can spot anomalies, you need to know what “normal” looks like. Record typical CPU, memory, disk I/O, and network usage during peak and off-peak hours for a week. Use built-in tools: on Linux, run top, iostat, and vmstat; on Windows, open Task Manager or Performance Monitor.
Install a monitoring agent or tool. For a quick start, install netdata on Linux (one-line script) or use Windows Performance Monitor’s built-in data collector sets. For more advanced setups, deploy Prometheus with node_exporter, or use a SaaS agent like Datadog (free tier available).
Configure the key metrics to collect. At minimum, track:
- CPU usage: overall %, per-core, and load average (Linux).
- Memory: used, free, cached, swap usage.
- Disk: space used, I/O read/write rates, and inode usage (Linux).
- Network: bandwidth in/out, packet drops, and error counts.
- System load: number of processes waiting for CPU.
Set up a dashboard. If using Grafana, create a new dashboard and add panels for each metric. If using netdata, the web UI is already a dashboard. If using built-in tools, you can use htop for a live view, but for historical data you’ll need a logging solution.
Define alert thresholds. Set alerts for conditions that indicate problems, such as CPU > 90% for 10 minutes, memory > 95%, disk space > 85%, or network errors > 0. In Prometheus, write alert rules; in netdata, use the “Alarms” tab; in cloud tools, configure notification channels.
Test your alerts. Simulate a load (e.g., run stress --cpu 4 on Linux) and verify that alerts fire and reach you. Adjust thresholds if you get too many false positives.
Monitor regularly. Check the dashboard daily, but rely on alerts for immediate issues. Review weekly trends to spot gradual degradation (e.g., memory creeping up due to a leak).
Document and act. When an alert triggers, note what you did to resolve it. Over time, you’ll build a runbook for common issues.

Common Mistakes

Only watching CPU. High CPU isn’t always bad; low CPU with high I/O wait can indicate a disk bottleneck. Always correlate metrics.
Ignoring swap usage. If the system is swapping heavily, performance tanks even if RAM looks “free” (because cached memory is counted as free).
Setting thresholds too low. Alerting at 50% CPU will spam you. Use your baseline to set meaningful thresholds.
Not monitoring disk I/O. Disk latency and queue length are often the real cause of slow responses, especially on databases.
Forgetting about network errors. Packet loss and collisions can cause timeouts even with low bandwidth usage.
No historical data. If you only look at live metrics, you can’t diagnose intermittent issues after they’ve passed.

Tips

Start with a simple tool like htop and iotop to get comfortable with reading metrics before installing a full monitoring stack.
Use a time-series database (like Prometheus) for long-term retention; it’s more efficient than logging to text files.
Monitor not just the server’s resources, but also the application’s response time (e.g., HTTP request latency) to get a user-centric view.
For cloud servers, use the provider’s built-in monitoring (e.g., AWS CloudWatch) as a fallback, but set up your own for more detail.
Automate the installation of monitoring agents using configuration management tools (Ansible, Puppet) to keep all servers consistent.
Keep your monitoring tool updated; old versions may miss new metrics or have security vulnerabilities.

Troubleshooting

No data appears on the dashboard. Check if the agent service is running (systemctl status netdata on Linux). Verify that the port is open (default 19999 for netdata) and that your firewall allows it. For Prometheus, check the target list in the UI—if it’s down, the exporter may be misconfigured.

Alerts not firing. Confirm that the alert expression is correct (e.g., cpu_usage > 90). Check the evaluation interval—it may take a few minutes. Ensure notifications are configured with the right webhook/email.

High CPU but no obvious cause. Use top to sort by CPU (press P). Look for processes you don’t recognize—could be a runaway script or a crypto miner. Use ps aux --sort=-%cpu to see the top consumers.

Disk space shows 100% but you can’t find the file. Use du -x -h --max-depth=1 / | sort -h to find large directories. Deleted files may still be held open by processes—use lsof +L1 to find them.

Monitoring tool itself is consuming too many resources. Lower the collection interval (e.g., from 1s to 10s) and reduce the number of metrics. If using netdata, disable unnecessary plugins.

Can’t connect to the server from the monitoring tool. Check SSH access, firewall rules, and that the agent is listening on the correct interface (sometimes it binds to localhost only—edit the config to bind to 0.0.0.0).

Frequently Asked Questions

What is the single most important metric to monitor?

There isn’t one—it depends on your workload. For web servers, CPU and memory are critical; for databases, disk I/O and latency matter more. Start with CPU, memory, disk, and network as a baseline.

How often should I check the dashboard?

Check manually once a day, but rely on alerts for immediate issues. Review weekly trends to spot gradual changes.

Can I monitor server performance for free?

Yes. Built-in tools like top and vmstat are free. Netdata has a free community edition, and Prometheus + Grafana are open-source. You only pay for hosted services if you want to avoid managing them.

What is a good CPU usage threshold for alerts?

Set an alert at 90% sustained for 10 minutes, but adjust based on your baseline. Some servers run at 80% constantly without issues; others should never exceed 50%.

How do I monitor multiple servers?

Use a central tool like Prometheus with an exporter on each server, or a SaaS solution like Datadog or New Relic. They allow you to view all servers on one dashboard and set alerts per server.

What’s the difference between load average and CPU usage?

Load average is the number of processes waiting for CPU (including those in uninterruptible sleep). CPU usage is the percentage of time the CPU is busy. A high load average with low CPU usage often indicates I/O wait or too many processes.

Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.

More cards in this drawer

The whole Numbers and Powers drawer →