Passive network flows

Monitor → Infrastructure → Network flows shows TCP activity observed inside the collecting Linux hosts. An eBPF Flow check follows real connections without generating synthetic traffic. It can reveal a struggling dependency even when no active test was configured for that peer.

For router, switch, or firewall exports and traffic-volume breakdowns, use NetFlow bandwidth.

Use this alongside Path Health. Passive TCP evidence describes the host’s connections; active path measurements describe the probe flows and vantage points that were configured. Neither supplies missing evidence for the other.

Enable collection

1. Choose a Linux agent on the host whose traffic matters. An agent on a nearby machine cannot observe that host’s TCP activity through this collector.
2. Verify its BPF and performance-monitoring capabilities and supported kernel probes. See agent capabilities.
3. Create an eBPF Flow check in Configure → Test management. The default reporting interval is 60 seconds.
4. Open the machine’s Network flows tab and inspect Collector for probe attachment, refused probes, and collection losses.
5. Open the Infrastructure-wide Network flows tab to compare peers across collectors.

Start with a remote peer

The Peers table is ordered by retransmits. It includes connection activity, resets, bytes, handshake timing, smoothed RTT, and congestion-window information where sampled. Peer and local-address context help identify which traffic the row describes.

Read the measurements according to their source:

• Retransmits count retransmitted TCP segments. A ratio is shown when the sent-segment denominator is available; it is not a path-probe loss percentage.
• Handshake timing describes observed completed handshakes. No completed handshake sample means the timing is unavailable, not instantaneous.
• SRTT is the TCP stack’s sampled smoothed round-trip estimate. It can be absent even when other connection counters exist.
• Resets and failed connections identify connection behavior to investigate; they do not by themselves identify a failing router or application.
• Congestion-window signals add transport context when the kernel supplied samples and publication is enabled.

The fleet view combines activity across collectors. Open a specific machine before attributing a fleet-wide total to one host or vantage point.

Connect traffic to a process and local interface

With Collect processes enabled, process rows split connection counters by the local task name that opened the connection. This helps distinguish a backup job’s traffic from an application contacting the same peer. Task names are kernel-reported process context, not a full distributed request trace.

Resolve local interface adds local route/interface context where available. Other optional sections add:

• Drop reasons: reasons reported when the kernel frees packets, subject to probe support. These are host-kernel observations, not evidence of a specific remote hop dropping the same packet.
• Queue delay: per-interface queueing activity and delay, useful when the host itself is holding traffic before transmission.
• Kernel counters: host-wide TCP and extended TCP counters from /proc, collected alongside the per-peer observations.

Host-wide counters, per-interface queues, and per-peer records have different scopes. Compare them without treating their totals as interchangeable.

Understand filtering and collection limits

Include ephemeral client ports is off by default. The default filter excludes high remote ports, starting at 32768, which commonly represent inbound clients’ temporary source ports. A real service listening on a high port can also be excluded. Review this setting when an expected dependency is missing.

Advanced controls include Ephemeral port floor, Include subnets, Exclude subnets, kernel map capacity, and rows per flush. Explicit exclusions take precedence. The machine’s Collector reports filtered peers separately from map-full losses and truncated peer or process lists.

Key by local port retains additional connection context but increases row count. Adjust it for a specific investigation instead of assuming that more rows always mean more useful coverage.

Example: one dependency is slow from some hosts

1. Find the dependency’s address in the fleet peer list and compare connection failures, retransmits, and available latency samples over the incident window.
2. Inspect affected machines separately and identify the local processes opening those connections.
3. Check their collector completeness, queue delay, and host resource pressure.
4. Compare active test results from the same vantage and period. Use SNMP interface evidence only where identity and timing support the device association.

This workflow separates several plausible explanations without presenting a single counter as proof of the cause.

Distinguish three empty states

No collector configured means there is no flow evidence. Probes refused means some requested evidence could not be observed; inspect the named probe, capabilities, and kernel. Attached and watching, no TCP peers yet can be a valid result for an idle host, subject to the configured filters.

Map-full losses or truncation make displayed counts incomplete. Increasing a limit can improve coverage but also consumes more kernel memory or produces more records. Use the reported loss information to choose the relevant change.