ntopng: Real-Time Network Traffic Monitoring

ntopng turns packets or flow records into an interactive picture of who is talking to whom, at what rate and with which protocol, with a web UI your colleagues can read without training. It is the fastest way to answer "what is saturating this link" or "which host opened 4,000 connections" without building a dashboard from scratch. This guide covers both ingestion modes, the settings that matter in production, and the alerts worth enabling.

Two ingestion paths

• Direct capture - ntopng reads a NIC in promiscuous mode (or a switch SPAN/mirror port). Simple, but CPU-bound: for a 10 Gbps link you will want PF_RING or a capture card.
• Flow collection - the router exports NetFlow/IPFIX/sFlow to nProbe, which forwards to ntopng over ZMQ. This scales to high-speed links because the router does the aggregation. sFlow vs NetFlow vs IPFIX: Network Monitoring Protocols Compared explains which flow protocol suits which platform.

Install and configure

sudo apt-get install ntopng redis-server
# /etc/ntopng/ntopng.conf
-i="ens3"                      # or -i=tcp://127.0.0.1:5556 for nProbe input
-w=3000                        # web UI port
-d=/var/lib/ntopng
-m="10.20.0.0/16,10.30.0.0/16" # local subnets: distinguishes internal from remote
--community
--max-num-flows=200000
--max-num-hosts=100000
--redis=127.0.0.1:6379

-m is not optional housekeeping: without local network definitions every host looks remote, and the "local vs remote" statistics - the ones you actually use - are meaningless. Redis backs the session store; check it is reachable, or the web UI will start but stay empty.

Flow ingestion with nProbe

# /etc/nprobe/nprobe.conf
-i=none
--collector-port=2055
--zmq=tcp://127.0.0.1:5556
-m=10.20.0.0/16
# ntopng.conf: -i=tcp://127.0.0.1:5556
sudo systemctl enable --now nprobe && sudo systemctl restart ntopng

Set the exporter to send to UDP 2055, then confirm with tcpdump -ni ens3 udp port 2055 before debugging ntopng itself.

Alerts and what to enable first

1. Interface alerts - traffic thresholds per interface, the fastest signal for saturation.
2. Host alerts - new host discovered, host exceeding a bandwidth threshold, host contacting a blacklisted address.
3. Flow alerts - port scans, suspicious TCP flag combinations, long-lived flows.
4. Endpoints: Syslog is the cheapest; email via your internal relay, or a webhook into the existing incident tooling.

Set thresholds from observed baselines, not guesses. A busy 10 Gbps uplink and a branch link need completely different numbers, and an alert policy that fires hourly gets muted within a week.

Tuning and verification

• sudo systemctl status ntopng, then curl -I http://localhost:3000; the API at /lua/rest/v2/get/interface/top_hosts.lua gives scriptable top-talkers data.
• On capture interfaces, disable segmentation offload (ethtool -K ens3 gro off gso off tso off) or reported sizes will be wrong.
• Cap --max-num-hosts/--max-num-flows on small VMs; unbounded flow tables are the usual cause of an ntopng that grows until the OOM killer arrives.
• Firewall the web UI to the management network, and change the default admin password on first login.

ntopng complements SNMP-based state monitoring: use Prometheus snmp_exporter: Monitoring Switches and Routers or Zabbix SNMP Switch Monitoring with LLD for availability and thresholds, and ntopng when you need to know what the traffic actually was.

原文链接：https://www.ntop.org/guides/ntopng/