Linux Network Traffic Monitoring Tools: CLI Utilities, Flow Analyzers and Fleet Platforms

Linux exposes network data in layers: kernel interface counters, captured packets, exported flow records and SNMP tables. Each layer suits a different tool, and picking the wrong layer is the most common reason admins end up with graphs that cannot answer the question being asked.

This guide groups the tools by the job they do, from a ten-second check on a single server to continuous monitoring across a fleet. It builds on our broader Linux network monitor overview and focuses on traffic volume, top talkers and bandwidth history. Standards matter here: SNMP counters follow RFC 1157, and flow export is defined in RFC 7011 (IPFIX).

What data Linux gives you about network traffic

Linux keeps cumulative byte and packet counters for every interface, and tools read these counters, capture packets, or collect flow records. Counters are cheap and reliable, packets are detailed but heavy, and flows summarize conversations without storing payloads.

• Interface counters: the kernel tracks bytes, packets, errors and drops per interface. Lightweight tools such as vnStat read these values instead of sniffing traffic.
• Packet capture: libpcap-based tools like iftop, iptraf-ng and tcpdump inspect packets as they cross the interface, which costs CPU on busy links.
• Flow records: routers, switches and software probes export conversation summaries over NetFlow or IPFIX. See our guide to NetFlow analyzers and collectors.
• SNMP: network devices and Linux hosts running snmpd expose interface tables that polling platforms read on a schedule. Our SNMP monitoring tools comparison covers that layer.

Command-line tools for live traffic checks

Command-line tools answer one question quickly: who is using the bandwidth on this server right now. They need shell access, show only the present moment and store nothing, so use them for diagnosis rather than reporting.

iftop

iftop draws a live list of host pairs on a chosen interface, ordered by bandwidth, with rolling averages over 2, 10 and 40 seconds. It is the fastest way to find a noisy client or a runaway backup job.

• Data source: packet capture through libpcap, so it needs elevated privileges.
• Strength: instant visibility into which two hosts are talking the most.
• Limit: no history, and it shows hosts rather than applications.

nload and iptraf-ng

nload plots incoming and outgoing throughput as two scrolling graphs per interface, which makes link saturation obvious at a glance. iptraf-ng goes deeper, with per-connection and per-protocol statistics in a console interface.

• nload: minimal setup, ideal when you only need to confirm a link is full.
• iptraf-ng: breaks traffic down by TCP, UDP and ICMP, useful over SSH on headless servers.
• Shared limit: both are live views without long-term storage.

tcpdump and ss

tcpdump captures packets for later analysis, and ss lists sockets with state and queue sizes. Together they explain why traffic behaves badly, not just how much of it there is.

• tcpdump: filter by host, port or protocol to capture a narrow sample.
• ss: shows established connections, listening ports and retransmission hints.
• Caution: captures can contain sensitive payloads, so handle files under your data policy.

Tools that keep bandwidth history

History tools store traffic over days or months so you can plan capacity and prove what happened last Tuesday. They read counters on a schedule and write compact time series, which is why they use very little CPU.

vnStat

vnStat runs as a small daemon, records interface totals and reports them per hour, day and month. Because it reads kernel counters rather than capturing packets, the overhead is negligible even on small virtual machines.

• Ideal for: monthly transfer tracking on cloud instances billed by egress.
• Output: console summaries and optional image graphs.
• Limit: totals per interface only, with no per-host breakdown.

Cacti and RRDtool

Cacti polls devices over SNMP and stores results in round-robin databases, then renders graphs in a web interface. It remains a common choice for teams that want graphs of switch ports and Linux interfaces with minimal storage growth.

• Data source: SNMP polling at fixed intervals.
• Strength: predictable storage because round-robin files have a fixed size.
• Limit: configuration is manual compared with modern auto-discovery platforms.

Web-based traffic analysis with ntopng and EtherApe

ntopng presents hosts, protocols and flows in a browser, which turns packet and flow data into something a whole team can read. EtherApe offers a graphical map where hosts and links are colored by protocol.

• ntopng: good for spotting unusual protocols, top talkers and geographic traffic patterns without buying a commercial suite; it also works with exported flow data through companion tools.
• EtherApe: useful for small networks and teaching, but it is a desktop application and not built for continuous alerting.
• Trade-off: richer detail means more storage and CPU, so size the collector for peak traffic, not the average.

Platforms for monitoring traffic across a fleet

When you manage dozens of Linux servers and network devices, a platform collects the same data centrally, stores history, correlates alerts and integrates with ticketing. These SaaSPodium-listed products cover the main styles.

Zabbix

Zabbix is free to license and uses agents, SNMP and templates to collect interface traffic, then fires triggers when thresholds are crossed. You pay in hosting and administration time. Vendor site: Zabbix. See the SaaSPodium listing.

• Architecture: server, database and optional proxies for remote sites.
• Integrations: API and webhooks for chat and ticketing.
• Deployment: self-hosted, with SaaSPodium listing it as free.

Paessler PRTG Network Monitor and ManageEngine OpManager

Both are freemium commercial platforms with auto-discovery, traffic sensors and dashboards. PRTG is organized around sensors per metric, while OpManager combines network and server views in one console. Compare the PRTG listing and the OpManager listing.

• Setup: wizard-driven discovery of devices and interfaces.
• Protocols: SNMP, WMI and flow data depending on edition.
• Pricing model: license tied to sensors or devices, so count both before buying.

Nagios XI, SolarWinds NPM and Datadog Network Monitoring

Nagios XI is plugin-driven and SaaSPodium lists it from $1,995 as of November 2026. SolarWinds Network Performance Monitor is listed from $1,700, and Datadog Network Monitoring is a freemium cloud-native option. See Nagios XI, SolarWinds NPM and Datadog Network Monitoring.

• Nagios XI: large plugin ecosystem for custom checks.
• SolarWinds NPM: enterprise-scale multi-vendor polling.
• Datadog: strongest fit when workloads already run in cloud environments.

How to calculate bandwidth utilization

Bandwidth utilization compares the data moved during a polling interval with what the link could carry. Polling platforms use two counter readings, and the same arithmetic works for any tool that shows raw byte counts.

ΔOctets is the change in the interface byte counter between two polls, ΔSeconds is the time between them, and link speed is the interface rate. A 1 Gbps link that moved 3.75 GB in 60 seconds ran at 50% utilization. Track the 95th percentile rather than the average when planning capacity, because short bursts cause user-visible slowness.

How to choose the right tool

Choose by the question you need answered. Live diagnosis needs a command-line tool, usage history needs vnStat or Cacti, traffic analysis needs ntopng, and ongoing alerting across many systems needs a platform. Most teams end up with one of each.

• One or two servers: iftop for diagnosis plus vnStat for history.
• Mixed server and switch estate: a platform such as Zabbix or PRTG with SNMP and agents.
• Security-minded teams: add flow analysis so you can see lateral movement and data exfiltration patterns. Continuous measurement is also recommended in NIST SP 800-137 for information security monitoring.

Whatever you pick, set a baseline during a normal week, alert on deviation from that baseline, and review the alerts monthly. Browse more options in our Network Monitoring Software category.

Frequently Asked Questions

What is the best tool to see which process is using network bandwidth on Linux?
Per-process attribution needs a tool that maps sockets to processes, such as nethogs, while iftop shows host pairs and not processes. Use iftop to find the remote host first, then ss or a per-process tool to find the owning process.

Is vnStat enough for a production server?
vnStat is excellent for interface-level history with almost no overhead, but it cannot show which hosts or protocols generate the traffic and has no alerting. Pair it with a platform such as Zabbix when you need triggers and per-host detail.

How long should I keep network traffic history?
Keep high-resolution data for 30 to 90 days for troubleshooting and downsampled hourly or daily summaries for 12 months or more for capacity planning. Retention rules for flow records may also be set by your compliance policy.