Per-Process Linux Network Bandwidth Monitoring Tools - 夜莺博客

Per-Process Linux Network Bandwidth Monitoring Tools

"The network is slow" is not a diagnosis, and interface counters alone cannot tell you whether the culprit is a backup job, a runaway container or a compromised host. The Linux ecosystem has a small set of mature tools that answer three distinct questions — which process, which conversation, and how much over time — and choosing the wrong one wastes the exact minutes you do not have. This article compares iftop, nethogs, vnstat, nload and bmon, shows the commands that matter, and explains the measurement-layer differences that make two tools show numbers 15% apart on the same flow.

Pick the Tool by the Question

Tool Granularity Data source History Answers
vnstat Per interface, over time Daemon polling kernel counters into SQLite Months How much did we move last month
nethogs Per process (PID/program) libpcap + /proc socket ownership None Which program is doing it
iftop Per connection pair libpcap capture None Who is talking to whom
nload Per interface /proc/net/dev Session only Is the link busy right now
bmon Interface + error counters netlink / /proc Session only Rates together with driver errors

The default set worth installing everywhere is small: vnstat because it is the only one that can answer questions about the past (and it cannot backfill), plus iftop and nethogs on any host you may have to debug interactively.

vnstat: Install It Before You Need It

apt install vnstat
systemctl enable --now vnstat
vnstat --add -i ens224            # register the interface with the daemon

vnstat -i ens224                  # monthly / daily / top-day summary
vnstat -i ens224 -h               # hourly breakdown
vnstat -i ens224 -l               # live mode
vnstat -i ens224 --json | jq .    # machine-readable, for dashboards

Choose the database update interval deliberately: a 5-minute poll interval is fine for capacity planning and keeps SD-card wear low on small devices. If you enable --sync mode or FastCGI, vnstat can also serve a lightweight web chart yourself.

nethogs: Which Process

sudo nethogs                    # all interfaces
sudo nethogs ens224             # single interface
sudo nethogs -d 5 -t -c 3 ens224   # text mode, 5 s refresh, 3 samples (scriptable)
sudo nethogs -v 3 ens224        # display in KB/s instead of cumulative KB

nethogs maps sockets to PIDs through /proc/net/tcp and inode matching, then resolves the program name from /proc/<pid>/cmdline. Two honest caveats: the first sample is always low because it reports a converging rolling average, and traffic whose socket closed before lookup lands in an unknown TCP row. On a busy server that row can be substantial — treat nethogs as a strong hint, not an audit.

iftop: Which Conversation

sudo iftop -i ens224
sudo iftop -i ens224 -n -P     # no DNS lookups, show ports
sudo iftop -i ens224 -f "port 443"
sudo iftop -t -s 30            # text mode, single 30 s snapshot

iftop captures packets with libpcap and aggregates by host/port pair, showing 2 s, 10 s and 40 s averages side by side. The three columns disagreeing with each other is not a bug — it is the averaging window doing its job. Use -n -P in production: reverse DNS lookups on a busy interface can delay the display enough to make the tool useless during an incident.

Why Two Tools Disagree

Running a single iperf3 flow while watching five tools is a useful calibration exercise. A ~41 Mbit/s TCP payload typically reads as:

  • iperf3: 40.9 Mbit/s — application payload only, headers and retransmissions excluded.
  • nload / bmon / ifstat: ~42.7 Mbit/s — every byte that left the NIC, including framing.
  • iftop: ~39.7 Mbit/s — counted at the IP layer, excluding Ethernet framing.
  • nethogs: ~34.7 Mbit/s — still converging on its first samples.

The 4.4% gap between application goodput and interface throughput is pure framing overhead on a 1514-byte frame with a 1448-byte payload. And the spread is arithmetic, not measurement error. Rule: compare numbers only when the layer and the averaging window match.

Non-Obvious Operational Notes

  • On Debian and Ubuntu, iftop and nethogs install into /usr/sbin; command -v iftop as a normal user reports nothing and people assume the package failed. Run with sudo.
  • In containers, nethogs and iftop need NET_ADMIN and NET_RAW capabilities; vnstat works with network_mode: host and nothing else.
  • For scriptable output prefer vnstat --json, nethogs -t or ifstat -t — parsing ncurses output is a maintenance trap.
  • Package counters into your monitoring stack so the data outlives the incident: see our SNMP exporter notes for the switch side of the same graph.

Related reading: ss, netstat and tcpdump workflow and ethtool ring buffer and coalescing tuning.

原文链接:https://pistack.xyz/posts/vnstat-vs-nethogs-vs-iftop-self-hosted-bandwidth-monitoring-guide-2026