The Problem with Disjointed Monitoring Tools
When a Linux web server suddenly slows to a crawl, identifying the bottleneck requires investigating multiple different hardware components. Is the CPU maxed out? Is the server running out of RAM and swapping to the hard drive? Is the network interface completely saturated by a DDoS attack?
Historically, system administrators had to run a half-dozen completely different commands in separate terminal windows to monitor all these metrics simultaneously. They used top for the CPU, free for the memory, iostat for disk activity, and ifstat for the network. Constantly shifting your eyes between multiple scrolling windows is inefficient and makes it difficult to see correlations (e.g., noticing that a massive spike in disk writes happens at the exact same millisecond as a massive spike in CPU usage).
To solve this, developers created the dstat command. It is a highly versatile, all-in-one replacement for all of those legacy monitoring tools, combining every crucial hardware metric into a single, beautifully color-coded, scrolling table.
Step 1: Installing dstat
Unlike basic tools like top, dstat is not always installed by default on minimal Linux distributions. You may need to install it from your package manager.
- On Ubuntu/Debian:
sudo apt-get install dstat - On CentOS/RHEL:
sudo dnf install dstat
Step 2: The Basic Overview
To launch the default monitoring layout, simply type the command and press Enter:
dstat
The terminal will instantly begin outputting a new row of data every single second. The output is cleanly separated into several columns:
- CPU stats: Shows exactly how much of the processor is being used by the user, the system, and how much is idle.
- Disk stats: Shows the raw read and write speeds (in kilobytes or megabytes) happening on your primary hard drive.
- Net stats: Shows the exact amount of data being received and sent over your network interface.
- Paging stats: Shows if the system is desperately moving data from RAM to the hard drive.
- System stats: Shows hardware interrupts and context switches.
Because every metric is printed on the exact same row every second, it is incredibly easy to see exactly how a spike in network traffic impacts your CPU usage in real-time.
Step 3: Customizing the Columns
The true power of dstat is its modularity. You can append dozens of different flags to the command to tell it exactly what data columns you care about, allowing you to build a custom dashboard on the fly.
If you only care about CPU usage, Memory usage, and Network traffic, you can use the -c (cpu), -m (memory), and -n (network) flags.
dstat -c -m -n
The display instantly unclutters, showing you only the three specific metrics you requested.
Step 4: Finding the Culprit Process
While seeing a massive spike in disk writes is helpful, you still need to know exactly which software application is causing it.
dstat includes incredible “top” plugins that identify the single most resource-hungry process on the system second-by-second.
To see standard metrics alongside the name of the most CPU-intensive application and the most disk-intensive application, run:
dstat --top-cpu --top-io
As the data scrolls down the screen, an extra column will appear on the right side. If an automated backup script suddenly triggers, you will clearly see a spike in disk I/O, and the right column will explicitly print something like rsync (45M), instantly proving exactly what software is crushing the hard drive.
Step 5: Exporting Data for Excel
If you are monitoring a server during a high-traffic stress test, you will want to save the data for later analysis.
You can force dstat to stream its output directly into a standard CSV file using the --output flag.
dstat --output /home/user/stresstest.csv
This command will continue to display the colorful interface on your terminal screen, while silently logging every single data point to the CSV file, which you can easily graph later in Microsoft Excel.