ntopng Traffic Analysis: Finding Bandwidth Hogs Without Losing Your Mind
It's 3:14 AM. PagerDuty fires. The WAN link on your primary DC is pinned at 98% and has been for 40 minutes. You SSH into the edge router, run show interface GigabitEthernet0/0/0, and see... bytes. Lots of bytes. No idea who. You open a second terminal, run iftop, watch it scroll for ten minutes, and learn exactly nothing actionable. Meanwhile the on-call Slack channel fills with "is it the network?" from people who should know better.
This is the failure mode ntopng exists to eliminate. Flow-based analysis tells you who is talking, to whom, over what protocol, and for how long — in seconds, not after a packet capture marathon. Packet capture has its place (deep forensics, payload inspection, protocol debugging), but for the question "what is eating my bandwidth right now," flows win every time.
This guide is for sysadmins, NetOps, and SecOps engineers who already know their way around a terminal. By the end you'll have a working ntopng deployment, flow export from your edge, dashboards that answer real questions, alerting that doesn't fire on noise, and a mental model for scaling it. If you're still running show interface in a loop as your bandwidth strategy, this is for you.
:::note[TL;DR]
- ntopng is an analysis layer, not a flow store. Pair it with ClickHouse or InfluxDB for anything past a week of retention.
- Flow export (NetFlow/IPFIX/sFlow) scales; direct packet capture does not. Use flows for capacity, packets for forensics.
- Default thresholds are wrong for your environment. Baseline for two weeks, then set alerts at 3σ.
- Never expose port 3000 to the internet. Reverse proxy with auth or don't bother.
- Bandwidth analysis is a security control. The crypto miner you didn't notice is a bandwidth hog you did notice. :::
Prerequisites
- A Linux host (Debian 12, Ubuntu 22.04/24.04, or RHEL 9) with at least 4 vCPU, 8 GB RAM, and 100 GB SSD for a small-to-mid deployment.
- Docker and Docker Compose v2 (for the recommended install path).
- A router or switch capable of NetFlow v9, IPFIX, or sFlow export.
- Root or sudo on the collector host, and the ability to open UDP 2055 (NetFlow/IPFIX) and 6343 (sFlow).
- Basic familiarity with Redis and a time-series database — you'll be running both.
Why ntopng and Not the Other Twelve Tools
The tooling landscape for traffic analysis is crowded and mostly mediocre. nfdump/nfsen is fast and scriptable but has a UI from 2008 and no real-time view worth using. Elastic with Packetbeat is fine until you discover the ingest cost of doing it at line rate. PRTG and SolarWinds NTA are commercial products priced for enterprises that mostly want a checkbox. Wireshark is a protocol analyzer, not a monitoring platform — using it for capacity analysis is like using a microscope to survey a highway.
ntopng wins because it does real-time flow analysis with a usable UI, ships with Lua scripting for custom logic, has built-in alerting, and deploys in under ten minutes. It loses because long-term retention is genuinely weak — the built-in timeseries is fine for days, not months. Treat it as the analysis layer and push history somewhere else.
⚠️ TRUNCATED VERSION
This is an abbreviated cross-post. Full article (all config files, architecture diagrams, images): valtersit.com
🛠️ Partner Tools for Developers
ValtersIT curates partner deals for developers and sysadmins — VPS hosting, security tools, monitoring platforms and dev productivity gear. No filler, no affiliate spam.
Top comments (0)