How to Configure Host sFlow on Linux: Real-Time Network Traffic and KVM Monitoring

Network tutorial - IT technology blog
Network tutorial - IT technology blog

The Challenge: Capturing Network Flows Without Overloading Your Server

Think of an office network like a busy intersection during rush hour. When congestion hits, stationing someone to manually record the license plate, color, and speed of every single vehicle will exhaust them within minutes. Worse, stopping cars for inspection grinds traffic to a complete halt. This is precisely what happens when you run tcpdump indiscriminately on a heavily loaded 10 Gbps interface.

Instead of inspecting every vehicle, a smarter approach is to snap a random photo once every 400 cars. At the same time, you log traffic density every 20 seconds. You still capture 95–99% of the full picture: which tanker truck is overloaded, and which on-ramp is driving the heaviest traffic flow—all without squandering system resources. That is the core philosophy behind sFlow (Sampled Flow).

Back when I managed an office infrastructure for 50 staff alongside a KVM server cluster, sudden network slowdowns were a routine headache. On one occasion, a backup VM unexpectedly unleashed a flood of traffic at 2 PM, saturating our primary uplink. The instinctive reaction at the time was to SSH in and fire up tcpdump. The result: a CPU core spiked to 100%, the .pcap file devoured 40 GB of disk space in 10 minutes, and the root cause remained unresolved.

sFlow cleanly solves this problem using two completely decoupled mechanisms:

  • Packet sampling: Randomly captures the header of 1 in every N packets passing through the interface (typically 1/400 or 1/1000).
  • Counter polling: Periodically polls hardware and system counters (interface bytes, CPU load, RAM usage).

All captured data is packed into lightweight UDP datagrams and streamed to a centralized Collector. Written in pure C, the Host sFlow (hsflowd) daemon runs quietly in the background on Linux, rarely consuming more than 1% CPU.

Installing Host sFlow on Linux

hsflowd runs seamlessly across most popular distributions, from Ubuntu and Debian to Rocky Linux and AlmaLinux. With zero heavy dependencies, installation takes less than two minutes.

1. Installation on Ubuntu / Debian

Recent Ubuntu releases include hsflowd directly in their official repositories:

sudo apt update
sudo apt install -y hsflowd

If you need the latest build or if the package is missing from your distribution’s default repositories, download the .deb package directly from the project’s GitHub releases:

# Example for version 2.0.51 on Ubuntu 22.04 LTS
wget https://github.com/sflow/host-sflow/releases/download/v2.0.51-1/hsflowd-ubuntu22_2.0.51-1_amd64.deb
sudo dpkg -i hsflowd-ubuntu22_2.0.51-1_amd64.deb

2. Installation on RHEL / Rocky Linux / AlmaLinux

Within the Enterprise Linux ecosystem, the package is available through EPEL:

sudo dnf install -y epel-release
sudo dnf install -y hsflowd

Configuring Host sFlow

All Host sFlow configurations reside in /etc/hsflowd.conf. While the daemon supports automatic Collector discovery via DNS-SD (DNS Service Discovery), specifying a static Collector IP is the safest and most predictable approach for production environments.

1. Standard Configuration for Standalone Servers

Open the configuration file with root privileges:

sudo nano /etc/hsflowd.conf

You only need to configure three primary parameters: the Collector address, the sampling rate, and the polling interval:

sflow {
  # Collector IP address and listening port (default is UDP 6343)
  collector {
    ip = 192.168.10.50
    udpport = 6343
  }

  # Sample 1 out of every 400 packets at random
  sampling = 400

  # Poll CPU, RAM, Disk, and Interface counters every 20 seconds
  polling = 20
}

2. Monitoring KVM / Libvirt Virtual Machines

One of hsflowd’s standout capabilities is its native hypervisor integration. By hooking into libvirt, the agent automatically detects running VMs, resolves their names, and tracks traffic across each virtual network interface (vnetX)—all without installing guest agents inside the VMs.

Add the libvirt block inside /etc/hsflowd.conf:

sflow {
  collector {
    ip = 192.168.10.50
    udpport = 6343
  }

  sampling = 400
  polling = 20

  # Automatically sync metadata and metrics from the libvirt hypervisor
  libvirt {
  }

  # Uncomment if you are using Open vSwitch instead of Linux Bridge
  # ovs {
  # }
}

3. Enabling the Service with systemd

Apply the new configuration and enable the service to start on boot:

sudo systemctl daemon-reload
sudo systemctl enable --now hsflowd

# Verify service status
sudo systemctl status hsflowd

An Active: active (running) status in green indicates that the agent has started collecting and exporting metrics.

Verifying Data Flow & Deploying a Collector

Once the agent is active, verify that UDP packets are properly egressing the host before standing up a monitoring dashboard.

1. Inspect Outgoing UDP Packets

Run the following command directly on the host running hsflowd:

sudo tcpdump -n -i any udp port 6343

You should observe output similar to:

14:25:01.120450 IP 192.168.10.15.42150 > 192.168.10.50.6343: UDP, length 1412
14:25:02.135112 IP 192.168.10.15.42150 > 192.168.10.50.6343: UDP, length 1380

Consistent outgoing datagrams confirm that the sFlow agent is operating as expected.

2. Spin Up an sFlow-RT Collector with Docker

On your Collector host (designated as 192.168.10.50 in this guide), the fastest way to analyze traffic in real time is sFlow-RT. You can launch a test instance using Docker in under 30 seconds:

docker run -d --name sflow-collector \
  -p 6343:6343/udp \
  -p 8008:8008 \
  sflow/sflow-rt

Once running, navigate to http://192.168.10.50:8008/html/index.html in your browser. The sFlow-RT web UI surfaces key operational metrics right away:

  • Top Talkers: Internal IPs generating the heaviest load or external IPs consuming abnormal amounts of bandwidth.
  • Top Protocols & Ports: Traffic distribution across application protocols (HTTP/S, SSH, DNS, MySQL, etc.).
  • System Metrics: Real-time telemetry for CPU utilization, RAM usage, and per-interface throughput across physical and KVM virtual ports.

3. Three Hard-Earned Production Tips

Keep these three practical lessons in mind when rolling out sFlow in production to prevent data loss or monitoring bottlenecks:

  • Ensure the UDP port is open: Port 6343 runs on UDP, not TCP. A frequent pitfall is wondering why metrics aren’t arriving, only to find the engineer forgot to permit UDP traffic through the host firewall (sudo ufw allow 6343/udp) or cloud Security Groups.
  • Tune sampling rates to link capacity: For 1 Gbps links, a sampling rate of 400 or 500 provides high statistical accuracy with negligible overhead. However, on 10 Gbps or 40 Gbps uplinks, increase this value to 1000 or 2500. Over-sampling high-throughput pipes can quickly overrun your Collector’s memory buffers.
  • Integrate automated alerts: sFlow-RT provides a standard REST API to export metrics into Prometheus. Forwarding this data to Grafana enables instant alerting for port-scanning spikes, Distributed Denial of Service (DDoS) attacks, or rogue KVM instances saturating your Internet gateway.
Share: