You've probably experienced this: an app throws a timeout or a failed request, and the real cause turns out to be a dropped connection somewhere in the cluster or a DNS lookup gone wrong, but you can’t see it from inside the app itself. Most teams don't have a clear, real-time view into their own network traffic, pod to pod, namespace to namespace, or workload to the outside world, until something breaks and they have to dig through logs to figure out what's actually calling what.
In a typical microservices cluster, traffic crosses namespaces all the time: an ecommerce workload calling payments, a workload egressing to an external HTTPS endpoint, one path suddenly carrying a lot more traffic than the rest. Without enrichment, you'll see pod IPs and ports, but you won't see workload identity, and you can't tell which connections need prioritization.
The addition of Network Observability to Fairwinds Insights changes that. It turns cluster flow and DNS telemetry into a workload-aware service map and a drillable event stream, so you can see who's talking to whom, identify what's leaving the cluster, and debug dependencies in Kubernetes terms: pod, namespace, and workload owner.
It's captured through eBPF via Inspektor Gadget. Instead of an address like 10.244.0.104:40015, you see ecommerce/Deployment/backend, so you can separate real application traffic from platform noise and follow a dependency straight into the event stream.
Network Observability runs as two components.
The agent, network-flow, is a DaemonSet that runs on every node. It attaches eBPF programs to the kernel to capture TCP connections, traffic volumes, and DNS activity, then streams what it captures to the aggregator.
The aggregator, network-flow-aggregator, is a deployment that enriches those raw events with Kubernetes metadata, such as pod, namespace, and workload owner. It buffers the data and forwards it on to Insights. And while the agent needs elevated permissions to do this work, the aggregator doesn't. It runs with no elevated privileges.
You can turn on Network Observability either from the Cluster Install Hub or by adding this line to your values.yaml:
network-observability:
enabled: true
The agent finds the in-cluster aggregator on its own, and the aggregator forwards enriched flow data to Insights. Once flow data starts coming in, you'll find Network Observability under Home → Clusters → Network.
For agent and aggregator options like batch size, buffer limits, and flush intervals, the full reference is in the insights-agent chart README.
The page splits into two tabs.
Service Map draws a live graph of traffic for the time window you select: namespace groups like e-commerce, accounting, and payments, plus an External group for outside peers. Nodes are labeled by kind, such as Deployment, Service, or external IP. Edges show traffic direction, and thicker lines mean more traffic. Click a node or edge and the Live Events table filters down to that connection.
DNS Summary aggregates DNS queries by name, sorted by failures first, so you can spot a workload that's failing lookups without digging through agent logs. Click a row and the Live Events table filters down to that DNS name, showing query type, response code, and resolved addresses.
Both tabs share the same filters and a Live Events table. You can filter by mode ( Application hides known platform namespaces like kube-system and local-path-storage by default, Platform surfaces just those platform namespaces, and All applies no filtering), time range, destination scope (internal, external, or both), and by App Groups, source namespace, or source workload, plus toggles for things like unresolved destinations or the Kubernetes API server. Live Events streams up to 500 recent events and supports CSV export for the selected time range and filters, which is useful for audits or attaching detailed information to a ticket.
A few ways teams might choose to use this include: filter to Destination Internal and click a Service node to see who's calling it, switch to Destination External to review what's actually leaving the cluster, and sort DNS Summary by failures to catch a workload chasing a bad DNS name.
Before you turn Network Observability on, check whether your cluster can actually run it.
Your nodes need to be Linux, with the bpf and debugfs filesystems available. Windows nodes aren't supported.
Because the agent works through eBPF, it also needs a set of elevated Linux capabilities and host filesystem mounts. The chart configures these automatically, but your cluster has to permit them.
Network Observability became generally available on July 28, 2026. It's part of the same Insights platform that already shows you cost, policy, and security data, now extended to cover the network layer. If you're already running the Insights Agent, add the config above and you'll start seeing flow data shortly. If you're not yet using Fairwinds Insights, get in touch with our team to learn more.
For the full technical reference, see the Network Observability documentation.