nload vs bmon vs vnstat: Linux bandwidth monitoring compared

nload, bmon, and vnstat are the three Linux bandwidth monitoring tools worth knowing. They solve different problems and the right answer is usually a combination of two. This post covers what each one is good at, where it falls short, and which to reach for in a given situation.

nload: real-time throughput at a glance

nload is a terminal tool that shows live throughput on a single interface using ASCII graphs, one for incoming and one for outgoing traffic. It reads /proc/net/dev directly, so it runs without root and uses negligible CPU.

Launch it with the interface name:

nload eth0

Useful flags:

• -u M changes the display unit to MB/s (defaults to bits per second)
• -m shows multiple interfaces on one screen, no graphs
• -t 1000 sets the refresh interval in milliseconds

Press F2 in-session to tweak refresh rate and graph scaling without restarting.

What you get on screen: current rate, average, min, max, and total transferred during the session. That is enough to confirm a server is pushing the traffic you expect, or to spot a sudden spike. What you do not get: per-process attribution, per-connection breakdown, or any historical data. Close the terminal and the session stats are gone.

Reach for nload when you want to answer "is this server saturating its link right now?" in under five seconds.

bmon: monitoring multiple interfaces

bmon takes a different approach. Instead of one interface in full detail, it shows every interface on the host at once. The top pane lists each one with current RX and TX rates. The bottom pane draws a graph for whichever interface you have selected. Arrow keys move between them.

This is the tool you want on virtualisation hosts, routers, dedicated servers with multiple NICs, or anything running Docker, where the interface list runs into the dozens. Cycling through them one at a time with nload would be tedious.

Press d in-session for the detailed statistics view, which adds packet counts, error rates, dropped packets, and collisions. That data is essential for diagnosing flapping links, MTU mismatches, or NIC driver issues that do not show up as a throughput problem.

Filter the interface list with -p to cut visual clutter:

bmon -p "eth*,ens*"

bmon can also export structured data with -o in JSON, XML, ASCII, or HTML formats, which is handy for scripted snapshots or feeding into another tool:

bmon -o ascii -p eth0 > /tmp/eth0-stats.txt

Same limitation as nload though: no persistent history. Close it and the data is gone.

vnstat: long-term usage tracking

vnstat fills the gap the other two leave. It runs as a background daemon (vnstatd) and writes traffic counters to a binary database in /var/lib/vnstat/. The database survives reboots and retains 5-minute samples for 48 hours, hourly data for 4 days, daily totals for 2 months, and monthly and yearly summaries indefinitely.

Enable it on day one:

systemctl enable --now vnstat

The critical point: vnstat only counts traffic from when the daemon starts. It cannot retroactively measure usage from before installation. On a new server, install it during provisioning or you will have no data when you need it.

Standard queries:

vnstat              # summary
vnstat -d           # daily breakdown
vnstat -m           # monthly totals
vnstat -h           # last 24 hours, hourly
vnstat -t           # top days
vnstat --json       # JSON export
vnstat -i eth0      # specific interface

vnstat is the right tool for answering "how much did we push last month?", "are we on track for our monthly cap?", and "what does the long-term trend look like?". The --alert flag lets you set thresholds tied to a custom billing cycle, useful when your provider's month does not align with the calendar.

Pair it with vnstati for PNG output if you need graphs in a status page or report:

vnstati -s -i eth0 -o /var/www/html/traffic.png

What vnstat does not do well: real-time diagnostics. The -l live mode exists but it is just a counter, no graphs, no per-interface detail. For incident response, you still want nload or bmon open in another pane.

Quick comparison

None of these tools tell you which process or connection is responsible for traffic. For that, iftop (per-connection) and nethogs (per-process) are the right tools, and they pair well with everything above.

Which tool to use when

For a single-interface VPS with a monthly cap, install vnstat on day one and use nload when you need a quick check. That covers 95% of cases.

For dedicated servers, virtualisation hosts, or anything running containers, swap nload for bmon. The multi-interface view saves real time once you have more than three or four NICs and bridges.

For capacity planning across a fleet, vnstat's JSON export feeds neatly into Prometheus, Grafana, or whatever you already use for metrics. Set it up once and forget about it until you need a monthly report.

When traffic looks wrong and you need to find the source, none of these three will tell you. That is where iftop (top connections by bandwidth) and nethogs (top processes) earn their keep.

All three tools read kernel counters rather than capturing packets, so the overhead is negligible even on a saturated 10Gbps link. There is no reason not to have all three installed.

Wrapping up

nload, bmon, and vnstat each cover a different question: what is happening right now on one interface, what is happening across many interfaces, and what has happened over time. Pick one for each question and you have bandwidth monitoring sorted with a setup that takes about five minutes and adds no measurable load.

If your workload pushes consistent traffic and you want to stop worrying about overage bills, an unmetered VPS gives you a flat-rate port and predictable cost, which makes the historical data from vnstat a planning tool rather than a billing alarm.