Overview

Host Network Analytics helps you understand how your Kubernetes pods communicate over the network, without changing your application code or kernel modules.

With this feature, you can:

• See how pods, nodes, and services talk to each other
• Analyze network traffic (packets, bytes, latency)
• Track ingress and egress traffic
• Detect packet drops and TCP retransmissions
• Visualize the network topology between services
• Quickly identify network performance or connectivity issues

How Host Network Analytics enhances Kubernetes 2.0

How Host Network Analytics works

• A Host Network worker (eworer) pod is deployed as a DaemonSet.
  • One worker pod runs on each node in the cluster.
• Each worker:
  • Uses Host Network Analytics to collect kernel-level network data.
  • Enriches every packet information with:
    • Pod name, namespace, node
    • Application resource (Deployment, DaemonSet, ReplicaSet, StatefulSet)
    • FQDN
    • Traffic type (internal / external)
  • Aggregates based on pods and sends enriched data to OpsRamp cloud.

Proxy support

If your cluster uses a proxy:

• The agent automatically detects configured proxy settings.
• All Host Network (eBPF) telemetry is sent via the proxy when present.

For proxy configuration details, see Kubernetes 2.0 Agent Installation guide.

Prerequisites

Before enabling Host Network Analytics, ensure the following:

1. Supported container runtimes

Your Kubernetes cluster must use one of these container runtimes:

• CRI-O
• Containerd
• Docker

Refer to the Compatibility Matrix for exact version support.

2. Custom runtime socket path

If your environment uses a custom container runtime socket (path different from default), you must pass it during Helm install or upgrade, for example:
Docker

--set containerSockFile.docker=/var/run/docker.sock

--set containerSockFile.cri-o=/var/run/crio/crio.sock

--set containerSockFile.containerd=/var/run/containerd/containerd.sock

3. Enable Host Network Analytics during agent installation

• During installation of the Kubernetes 2.0 agent, ensure that the Host Network Analytics option is enabled and the appropriate container engine is selected.
• For more details, refer to the Kubernetes 2.0 Agent Installation guide.

Limitations

• Only CRI-O, Containerd, and Docker runtimes are supported.
• Unsupported runtimes may cause Host Network worker (eworker) pod failures or no data collection.
• Cgroup v2 is required on the node OS.
• Host Network Analytics is supported only with Kubernetes 2.0 agent (not Kubernetes 1.x).
• If the NetworkObservability CR is misconfigured (e.g., wrong namespace or selectors), some pods/nodes may not be monitored.

The above limitations are important for troubleshooting: If you do not see data, first check:

• Runtime type and version
• Cgroup version (must be v2)
• eworker pod status and logs
• NetworkObservability CR configuration

Permissions

Following permissions required to install the Linux OS Integration:

Refer to the Permission Sets document for more details on obtaining the necessary permissions.

Compatibility Matrix

Use this table to verify that your environment is supported.

Steps to Configure

By default, Host Network Analytics monitors all pods and all nodes in the cluster. If you want to:

• Include or exclude pods from specific namespaces or nodes
• Limit monitoring to selected workloads you can do so by configuring the NetworkObservability Custom Resource (CR).

Step 1: Check whether the CR already exists

kubectl get netobs network-observability-config -n <opsramp-agent-namespace>

Step 2: If the CR exists, edit it using the sample configuration below

kubectl edit netobs network-observability-config -n <opsramp-agent-namespace>

Step 3: If the CR does not exist, create it using a YAML file and apply the configuration

kubectl apply -f netobs-sample.yaml

Sample Configurations

1. Include (whitelist) all namespaces

apiVersion: network.agent.opsramp.com/v1
kind: NetworkObservability
metadata:
  name: network-observability-config
  namespace: <opsramp-agent-namespace>
spec:
  targetCgroupSelectors:
    - action: include
      namespaces:
        - "*"

• Meaning: Monitor pods in all namespaces ("*").

2. Include (whitelist) all nodes

apiVersion: network.agent.opsramp.com/v1
kind: NetworkObservability
metadata:
  name: network-observability-config
  namespace: <opsramp-agent-namespace>
spec:
  targetCgroupSelectors:
    - action: include
      nodeNames:
        - "*"

• Meaning: Monitor pods on all nodes ("*").

3. Include only selected namespaces

apiVersion: network.agent.opsramp.com/v1
kind: NetworkObservability
metadata:
  name: network-observability-config
  namespace: <opsramp-agent-namespace>
spec:
  targetCgroupSelectors:
    - action: include
      namespaces:
        - "default"
        - "opsramp-agent"

• Meaning: Monitor pods only in the default and opsramp-agent namespaces.

4. Exclude selected namespaces (and include the rest)

apiVersion: network.agent.opsramp.com/v1
kind: NetworkObservability
metadata:
  name: network-observability-config
  namespace: <opsramp-agent-namespace>
spec:
  targetCgroupSelectors:
    - action: exclude
      namespaces:
        - "default"
    - action: include
      namespaces:
        - "*"

• Meaning: Exclude pods in the default namespace, and monitor pods in all other namespaces.

Key Field Definitions

View Host Network Dashboards in OpsRamp Portal

The Host Network Analytics dashboard provides visibility into network traffic, packet flow, latency, and communication patterns between pods and services in a Kubernetes cluster. It helps users understand who is communicating with whom, how much data is transferred, and whether there are network issues such as packet drops or latency.

1. Infrastructure → Host Network Analytics

1. Go to Infrastructure → Host Network Analytics.
2. Use the filters to select:
   • Cluster
   • Namespace
   • Pod
3. View detailed pod-level network metrics and charts.

Host Network Analytics – Fields & UI Elements

In the Host Network Analytics menu, you will see two options that help you manage and analyze network data:

• Packet Drops
• eBPF Configuration

Packet Drops

The Packet Drops option helps you identify network packets that failed to reach their destination due to network, policy, or configuration issues.

Steps to View Packet Drops

1. Select Packet Drops from the menu.
2. The Packet Drops dashboard opens and displays the following details:
   • Drop Count – Number of packets dropped
   • Drop Reason – Cause of the packet drop
   • Cluster – Cluster where the drop occurred
   • Source Namespace
   • Source Pod / IP / Port
   • Destination Pod / IP / Port

eBPF Configuration

Use eBPF Configuration to control how long host network analytics data is retained. You can adjust the retention period based on your monitoring and compliance needs. Data older than the configured period is automatically deleted.

Steps to Configure Retention Period

1. Select eBPF Configuration from the menu.
2. On the eBPF Configuration page, choose the required Retention Period.
3. Click Save to apply the changes.

2. Infrastructure → Search (Pod View)

1. Navigate to Infrastructure → Search.
2. Select your Kubernetes 2.0 cluster → Pods.

   

3. Open a pod’s resource tile.
4. From the three-dot menu, click View Host Network Analytics to view the dashboard.

   

3. Infrastructure → Traces

The Traces view combines application traces with network metrics from Host Network Analysis.

3.1 View All Trace Services

1. Go to Infrastructure → Traces.
2. The list shows all trace services.
3. Each service includes extra network metrics:
   • Network Latency
   • Network Throughput
   • Network Retransmissions

3.2 View Network-Only Services

1. In the Traces view, enable the Network Only toggle.
2. The list now shows network-level services enriched by Host Network Analytics.
3. Click any service to open detailed analytics.

You will see sections like:

• Service Metrics
• Network RTT
• Network Throughput
• Network Retransmissions

3.3 Network Topology View

When a service is selected, you can open the Network Topology graph.

This graph helps you:

• Understand how services communicate
• See traffic paths and dependencies
• Quickly locate potential bottlenecks or failure points
• Network-level services are now enriched using host-level service data, allowing visibility into non-instrumented services.

Network Topology Fields

Collected Metrics

Pod‑level Network Metrics

Service / Trace‑level Metrics