Kennisbank › Monitoring › Linux Monitoring: From `top` to `tcpdump`, `thermald` and `sg3_utils`
monitoring starter 29 August 2026

Linux Monitoring: From `top` to `tcpdump`, `thermald` and `sg3_utils`

Linux Monitoring: From `top` to `tcpdump`, `thermald` and `sg3_utils` This article shows you how to build a working monitoring baseline on a Linux server using

You also want a terminal multiplexer. `tmux` 3.x is the practical choice, since monitoring sessions need to survive a dropped SSH connection.

One warning before you start: monitoring tools that capture packets or read raw device data need elevated privileges. Run them as `root`, or grant the specific capability with `setcap`. Handing out `sudo` for `tcpdump` to everyone on the box is how you end up explaining yourself to your security team.

Step 1 — Install the tools

Start by pulling in what isn't already there. `top` is part of `procps`, which every distribution installs by default, so you can skip that one.

```bash sudo apt update sudo apt install -y tmux tcpdump thermald sg3-utils ```

On RHEL, Rocky or AlmaLinux the package names differ slightly:

```bash sudo dnf install -y tmux tcpdump thermald sg3_utils ```

The cost here is disk space and a handful of new background services. `thermald` starts on boot and stays resident, which is the point — it needs to be watching before the CPU gets hot, not after.

Step 2 — Get a first look with `top`

`top` gives you a live view of what the kernel is running. Not a snapshot, not a log line — a refreshed list of processes plus a system summary at the top.

```bash top ```

The header shows load average, CPU breakdown, memory and swap. Below that, processes sorted by CPU by default. Inside `top` you can press `M` to sort by memory, `P` to sort by CPU, `1` to expand per-core CPU lines, and `k` to kill a process by PID.

Configuration persists across runs. Press `W` to write your current layout to `~/.toprc`, and the next time you start `top` it comes back the way you left it. That matters in operations: you build one view that answers your questions, and you stop rebuilding it every morning.

Step 3 — Run several monitors side by side with `tmux`

Watching `top` means occupying a terminal. If you also want `tcpdump` and a log tail, you need more than one pane — or more than one SSH session, which is worse.

```bash tmux new -s monitor ```

Inside the session, split horizontally with `Ctrl-b "` and vertically with `Ctrl-b %`. Navigate panes with `Ctrl-b` followed by an arrow key. Run `top` in one pane, `tcpdump` in another, `tail -f /var/log/syslog` in a third.

Detach with `Ctrl-b d`. The session keeps running. Reattach later with:

```bash tmux attach -t monitor ```

This is the single biggest quality-of-life change in day-to-day monitoring. You start a capture, close your laptop, come back an hour later, and the data is still there. The trade-off is that a detached `tmux` session keeps consuming resources whether you look at it or not — a `tcpdump` you forgot about will happily fill a disk.

Step 4 — Capture network traffic with `tcpdump`

`tcpdump` reads packets off an interface and either prints them or writes them to a file. It is the tool you reach for when something is slow, unreachable, or behaving in a way the application logs don't explain.

```bash sudo tcpdump -i eth0 -nn -c 100 port 443 ```

Flags worth knowing: `-i` selects the interface, `-nn` stops DNS and service-name resolution so you see raw addresses and ports, `-c` stops after a number of packets. Without `-c` it runs until you interrupt it.

To write a capture for later analysis in Wireshark:

```bash sudo tcpdump -i eth0 -w /tmp/capture.pcap -s 0 ```

The `-s 0` sets the snapshot length to the full packet. Older guides tell you to use `-s 65535`; on current versions `0` means "everything," and it's the better habit.

Filtering is where `tcpdump` earns its place. `host 10.0.0.5`, `net 192.168.1.0/24`, `port 53`, `tcp and not port 22` — all valid, all composable with `and`, `or` and `not`. On a busy interface, no filter means no useful output.

Step 5 — Watch CPU temperature with `thermald`

`thermald` is a daemon, not a command you run interactively. It reads thermal sensors through the kernel's thermal sysfs interface at `/sys/class/thermal`, builds a model of how your CPU behaves under load, and applies cooling actions when thresholds are crossed. On Intel systems it uses the `intel_pstate` driver to lower clock speed; on other hardware it triggers the kernel's cooling devices.

Start it and enable it at boot:

```bash sudo systemctl enable --now thermald ```

Check what it sees:

```bash cat /sys/class/thermal/thermal_zone*/type cat /sys/class/thermal/thermal_zone*/temp ```

Temperatures are reported in millidegrees Celsius — `45000` means 45 °C. If your machine is a virtual server, expect either no thermal zones or a single fake one. There is no sensor to read on a hypervisor, and `thermald` will exit quietly.

Step 6 — Check disk health with `sg3_utils`

`sg3_utils` sends SCSI commands directly to a device. For monitoring, the useful part is that it exposes status and error information that the block layer hides.

```bash sudo sg_ses --page=0x02 /dev/sda sudo smartctl -a /dev/sda ```

`smartctl` comes from `smartmontools`, not `sg3_utils`, but the two are complementary: `sg_ses` reads SCSI Enclosure Services data (fan status, power supply state, temperature on enterprise enclosures), while `smartctl` reads the drive's own SMART counters. On a tape drive or external SAS shelf, `sg_ses` is often the only way to see what the enclosure thinks is wrong.

This is low-level work. On a cloud VM with a virtual block device, none of it applies, and you should not try to force it.

Step 7 — Set thresholds and alerts

Reading a graph is not monitoring. Monitoring is a system that tells you something is wrong without you looking.

For a first pass, `systemd` timers plus a shell script cover most ground. Write a script that checks a condition and exits non-zero, then have a timer run it every minute. For anything larger, Prometheus with `node_exporter` is the standard open source answer, and Grafana renders it. Both are heavier than a shell script and both will outlive your shell script.

The honest trade-off: a hand-rolled check is quick to write and easy to understand, and it will silently stop working the day someone renames a mount point. Prometheus is more setup and more moving parts, but it fails loudly.

Step 8 — Keep a record

A monitor that only shows the present is a monitor you can't debug with. When something broke at 03:00, you want the numbers from 02:55.

```bash while true; do date +%s >> /var/log/load.log cat /proc/loadavg >> /var/log/load.log sleep 60 done ```

Crude, but it works and it costs nothing. For anything beyond a single host, ship the data somewhere central instead of writing to local disk — a full disk is a monitoring failure that causes the next monitoring failure.

Verification

Confirm each layer is actually running, not just installed.

```bash systemctl status thermald tmux ls sudo tcpdump -i eth0 -c 5 -nn top -bn1 | head -5 ```

`systemctl status thermald` should show `active (running)`. `tmux ls` should list your `monitor` session. The `tcpdump` command should print five packets and exit. `top -bn1` runs `top` in batch mode for one iteration — useful in scripts and the quickest way to confirm it works without an interactive terminal.

If all four return what you expect, you have a working baseline.

Common problems

`tcpdump` shows nothing on the interface. You are likely looking at the wrong interface, or the traffic is on a bridge or VLAN that `eth0` doesn't see. Run `ip -brief link` to list interfaces, and check whether the packets you want are on a `veth`, `br0` or `bond0` instead.

`thermald` fails to start with "No thermal zone found." The hardware or hypervisor exposes no thermal sensors. On a VM this is expected and there is nothing to fix. On bare metal, check that the `coretemp` or `k10temp` kernel module is loaded with `lsmod | grep -E 'coretemp|k10temp'`.

`top` shows high load but low CPU usage. Load average counts processes waiting on I/O, not just running ones. A high load with idle CPU usually means disk or network wait. Check `iostat -x 1` and look at the `%iowait` column before you go hunting for a runaway process.

Monitoring is a layer you build once and then maintain, and the maintenance is the part nobody puts in the diagram.

← Terug naar kennisbank
← Terug naar kennisbank