resource usage

Overview

A healthy system uses CPU, memory, disk, and network within normal bounds; deviations can mean trouble — or an attack. Monitoring resource usage is both an operations and a security skill. This lesson covers observing system resources on Linux.

Learning objectives

• Monitor CPU, memory, and disk usage.
• Use the right tool for each resource.
• Relate resource anomalies to possible security events.

Core concept

Key resources and the tools to inspect them:

• CPU & memory (live) — top/htop show overall and per-process usage.
• Memory — free -h shows total/used/free memory and swap.
• Disk space — df -h shows filesystem usage; du -sh <dir> shows a directory's size.
• Disk I/O / load — the load average (shown by uptime/top) indicates how busy the system is.

How it works

Each tool answers a specific question: free -h for "is memory exhausted?", df -h for "is a disk full?", top for "what is consuming CPU right now?", and load average for "how saturated is the system?" Watching these over time establishes a baseline; sudden spikes or exhaustion point to a problem — a runaway process, a filling disk (perhaps from runaway logs), or resource abuse. Interpreting them together localizes the cause.

Practical example

$ free -h
              total   used   free
Mem:           7.7Gi  6.9Gi  0.3Gi
$ df -h /
Filesystem  Size  Used Avail Use%
/dev/sda1   50G   49G   1.0G  99%

Memory is nearly full and the root filesystem is at 99% — both warning signs. A disk at 99% can crash services and is sometimes caused by excessive logging or a malicious process dumping data; investigating what filled it (du -sh /var/log/*) localizes the cause.

Cybersecurity relevance

Resource anomalies are meaningful security signals. A CPU spike may indicate a cryptominer; memory exhaustion or a full disk can be the effect (or goal) of a denial-of-service or a misbehaving compromise; unusual disk growth may be data staged for exfiltration or runaway attacker activity. Monitoring resources helps detect these and also protects availability (a core security property). Correlating a resource anomaly with process and log data turns "the system is slow" into a specific diagnosis.

Common mistakes

• Using the wrong tool — e.g. df (filesystem space) vs du (directory size) vs free (memory).
• Reacting without a baseline, so you cannot tell normal load from abnormal.
• Ignoring a full disk, which can crash services and may signal an attack or misconfiguration.

Key takeaways

• Monitor resources with top/htop (CPU/memory live), free -h (memory), df -h (disk space), du -sh (directory size), and load average (uptime).
• Establish a baseline so spikes or exhaustion stand out; each tool answers a specific "is this resource healthy?" question.
• Resource anomalies (CPU spikes, memory/disk exhaustion, unusual growth) are security signals — miners, DoS, or exfiltration — and monitoring also protects availability.

Check your understanding

• Which command shows filesystem disk usage, and which shows the size of a specific directory?
• Give one example of a resource-usage anomaly and the kind of security event it might indicate.