Skip to content
Start free

See how your services talk, connection by connection

The collector records TCP connections on Linux hosts and Kubernetes nodes with eBPF, or from socket statistics where eBPF cannot run, and names the pod and workload at each end, with throughput, retransmits and round-trip time.

Start freeBook a demoRead the network docs
  • eBPF on Linux 5.8+
  • Pods and workloads
  • Retransmits · RTT p95

How it works

From a socket on a node to a named conversation

Nothing changes in your applications. The collector you already run on each node does the recording.

  1. 01InstallDeploy the collector to your cluster with Helm, or to Linux hosts, with network flows turned on.
  2. 02CaptureeBPF probes record each TCP connection on the node; socket polling takes over where eBPF cannot run.
  3. 03MeasureEvery 30 seconds, bytes each way, retransmits and round-trip time for each conversation.
  4. 04NameEach end is labelled with its workload and namespace, or its country and network outside the cluster.
  5. 05ExploreGroup and filter conversations on the Network tab, then open one for its TCP health and NAT.

Identity

Pods come and go. The workload name stays.

Every conversation is labelled at insert time with the workload behind each address, so a week of traffic between two Deployments reads as one line, however many pods have been rescheduled since.

  • ReplicaSets fold into their Deployment, and StatefulSets, DaemonSets and Jobs keep their own names
  • Traffic sent to a Kubernetes Service address is traced through NAT to the pod that answered
  • Group by workload, namespace, address or port, and filter by cluster, transport, port or the server's country and network

Collection

eBPF where the kernel allows it, socket polling where it does not

In its default mode the collector tries eBPF first and falls back on its own, and every record says which method produced it, so you know how complete a node's view is.

  • eBPF first

    Linux 5.8 or later with BTF and a privileged pod catches even short-lived connections.

  • Polling fallback

    Elsewhere, kernel socket statistics every 30 seconds; brief connections can be missed.

  • TCP by default

    UDP is opt-in, and its byte counts need eBPF. IPv4 and IPv6 both work.

  • On in Kubernetes

    The Kubernetes integration collects network flows unless you turn it off.

Better together

The connection underneath every slow request

Conversations sit next to your traces, cluster state and security graph, so a slow span and the retransmits beneath it are one click apart.

FAQ

Questions platform teams ask first

Talk to an engineer
Does it read VPC flow logs?
No. Cloud network monitoring records connections on the hosts and nodes where the collector runs. AWS VPC Flow Logs can be collected separately as a security log source, but they do not feed this view, and Azure and Google Cloud flow logs are not supported.
Is there a map of which services talk to each other?
Not for these conversations yet. They appear as charts and a ranked table. The APM service map shows how traced services call each other.
Which platforms are supported?
Linux hosts and Kubernetes nodes. eBPF needs Linux 5.8 or later with BTF and a privileged pod; elsewhere the collector polls socket statistics instead. Windows and macOS hosts are not covered.
Does it capture UDP or DNS?
TCP is captured by default. UDP is opt-in, and its byte counts need eBPF. DNS queries and packet counts are not recorded.

Turn on network flows in your cluster

Install the collector with Helm. The Kubernetes integration collects network flows by default, and conversations appear on the Network tab.

Start freeRead the guide