# atop: a Linux monitor built around short sampling intervals

> atop is a C written ASCII monitor for Linux that reports CPU, memory, disk and per process activity for the last interval, keeps compressed raw counters for 28 days, and leaves per process network and GPU numbers to optional extras.

**Atoptool/atop** — System and process monitor for Linux

- Repository: https://github.com/Atoptool/atop
- Stars: 1,077 · Forks: 131
- Language: C
- License: GPL-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/atoptool-atop

## atop measures the last interval, not the boot average

atop is a full screen ASCII performance monitor for Linux, written in C and released under GPL-2.0 by Gerlof Langeveld. It is built for the awkward moment when a process is already gone: the documentation states that atop reports the activity of all processes, even those that finished during the interval. At system level it reports CPU, memory, swap, disks including LVM and the network layers. At process level it reports CPU utilization, memory growth, disk utilization, priority, username, state and exit code for every process and thread. Two defaults matter more than the counter list. Passive resources and processes are suppressed by default, so a quiet machine shows a short screen rather than hundreds of rows. And the numbers describe the last interval only, not what has accumulated since boot. That makes atop a sampling tool, and a good fit for explaining a spike after the fact rather than for watching a trend curve.

## Two screens: detail text and a bar graph overview

The same counters appear in two shapes. In text mode you get the detail view: system resource utilization, per process consumption, and a cgroup hierarchy view showing the utilization of CPU, memory and disk for each cgroup together with the processes it contains. In bar graph mode a character based graphical overview shows processor, disk, network interface and memory utilization at system level. Colors mark resources that have almost reached a critical load, so the overloaded thing catches the eye before you read a number. The window width is not fixed either, since columns are added or removed as the terminal is resized. Accumulators sit on top of the live view: resource consumption can be summed per user, per program name and per container, which answers the recurring question of who consumed the memory on a shared host.

## The source tree separates collection from display

Looking at the file layout, collection and display are kept apart. photoproc.c and photosyst.c sit beside rawlog.c, cgroups.c, ifprop.c and procdbase.c, while the drawing side lives in drawbar.c, showlinux.c, showsys.c and showprocs.c. A separate daemon binary, atopacctd, is built from atopacctd.c and netlink.o, so process accounting is not folded into the interactive program. Optional counters have their own files too, with netatopif.c and netatopbpfif.c for network activity and gpucom.c for GPU activity. Output is not locked to the screen: json.c and parseable.c are part of the tree, and helper binaries such as atopcat, atopconvert and atophide are built alongside the monitor, with a man/ directory holding the manual pages.

## Raw counters on disk, and atopsar for the long view

atop keeps a raw counter log so the past stays available. The counters are compressed at the moment of writing to keep disk space down, and the daily log files are preserved for 28 days by default. System activity reports are generated from such a log file with the atopsar command. In the Makefile atopsar is not a separate program but a symlink to atop, so one binary switches behaviour depending on how it is invoked. The log is the reason atop survives contact with an incident: a live screen cannot show the process that exited two minutes ago, but a raw log can. The project also points to third party tooling for these files, including a graphical viewer for raw log files, a graphical representation of system resource utilization, and a cheatsheet for the interactive keys.

## Per process network and GPU numbers are optional extras

Two headline features depend on pieces you have to add yourself. Per process and per thread network counters come either from the optional netatop kernel module or from the netatop-bpf implementation, and they cover the number of TCP and UDP packets transferred and the bandwidth each process consumed. GPU counters come from the optional atopgpud daemon, which reports load and memory utilization per GPU at system level and per process. A plain build therefore gives you process CPU, memory and disk numbers but not per process traffic or GPU usage, and the repository ships a service unit for the GPU daemon alongside the ones for the monitor, the rotation job and the accounting daemon. This is the sharpest boundary in the project: two of the most requested numbers are extras rather than defaults.

## Building atop: the Makefile is the install manual

The project description does not give an installation recipe; it points readers to the project site at http://www.atoptool.nl for downloads. Building from the source tree is where the layout of an installed system is actually written down, and the Makefile spells out the destinations. DESTDIR is empty by default, and the paths are fixed:

```bash
BINPATH  = /usr/bin
SBINPATH = /usr/sbin
SCRPATH  = /usr/share/atop
LOGPATH  = /var/log/atop
```

So the monitor binary belongs in /usr/bin, the daemons in /usr/sbin, the shared files in /usr/share/atop, and the raw logs in /var/log/atop. The default target builds the whole set of tools in one go:

```bash
all: atop atopsar atopacctd atopconvert atopcat atophide
```

The monitor links against the wide character ncurses library, zlib, the math and realtime libraries, while glib is located through pkg-config:

```bash
$(CC) atop.o $(ALLMODS) -o atop -lncursesw -lz -lm -lrt $(LDFLAGS)
```

atopsar is then linked to the same binary rather than compiled a second time:

```bash
ln -sf atop atopsar
```

Packaging is largely settled too, since the tree holds a systemd unit, a rotation service and timer, an init script for both init systems, a daily cron file and an RPM spec file.

## Where atop is the wrong tool

atop is a poor fit in several ordinary situations. It is a terminal program that draws an ASCII interface, so it needs an interactive console and does not serve as a dashboard or feed a time series database on its own. The project ships no built in web interface or export agent; the web interface it links to is maintained by somebody else. It is Linux only, and per process network numbers need a kernel module or a BPF program, which is a real obstacle in locked down environments. Per cgroup reporting covers CPU, memory and disk, so a container platform that needs fine grained GPU or network attribution will not find it here. The GPL-2.0 licence also shapes what you can do with the source itself if you intend to ship a closed product that includes it.

## Conclusion

atop fits Linux operators who have to explain what a process did during a specific interval, and it fits incident work where the interesting process exited before anyone could attach to it. It is a poor fit if you need a dashboard, a time series feed, or per process network and GPU counters without adding a kernel module, a BPF program or the atopgpud daemon. Before adopting it, confirm your kernel can carry netatop if per process traffic matters to you, and decide who will read the 28 day raw logs with atopsar.

## FAQ

### How do I install atop on Linux?

The project points to http://www.atoptool.nl for downloads, and the Makefile shows where a source build lands: binaries in /usr/bin, daemons in /usr/sbin, shared files in /usr/share/atop and raw logs in /var/log/atop.

### Does atop show per process network traffic out of the box?

No. Per process and per thread TCP and UDP counters come from the optional netatop kernel module or from the netatop-bpf implementation, and GPU numbers come from the optional atopgpud daemon, so a plain build reports CPU, memory and disk per process only.

### How long are atop raw log files kept?

Raw counters are compressed when they are written, and the daily log files are preserved for 28 days by default. System activity reports are produced from a log file with the atopsar command.

### What is the difference between atop and atopsar?

atop is the full screen monitor you watch live, while atopsar generates system activity reports from a log file. The Makefile builds atopsar as a symlink to atop, so both come from the same binary.

## Sources

- [Atoptool/atop on GitHub](https://github.com/Atoptool/atop)
- [Issues](https://github.com/Atoptool/atop/issues)
- [License: GPL-2.0](https://github.com/Atoptool/atop/blob/master/LICENSE)
- [README](https://github.com/Atoptool/atop/blob/master/README.md)
- [Releases](https://github.com/Atoptool/atop/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/atoptool-atop