---
title: OBI network observability
description: Monitor service-to-service network traffic and TCP connection health with OBI's kernel-level network metrics.
url: https://coralogix.com/docs/opentelemetry/instrumentation-options/ebpf-auto-instrumentation/network-observability/
product: apm
feature: eBPF Agent
feature_id: apm-ebpf-agent
feature_identifier: apm/apm-ebpf-agent
last_updated: '2026-10-28'
---

# OBI network observability

OBI observes network traffic at the kernel level, so it can report how your services talk to each other, how much data moves between them, and how healthy their TCP connections are, without any code changes, sidecars, or SDKs. Network metrics come from the same eBPF agent that produces OBI's traces and application metrics, and they follow the OpenTelemetry conventions on both the OTLP and Prometheus export paths.

Network observability is Kubernetes-first. OBI runs as a DaemonSet on each node, attributes each flow to the workloads on both ends, and enriches it with Kubernetes metadata.

## What OBI captures

OBI's network telemetry falls into two groups:

* **Network flows**: the volume of traffic between a source and a destination, including bytes and packets transmitted and, within Kubernetes, bytes that cross availability zones. Use these to see which services exchange the most traffic and where cross-zone egress adds cost.
* **TCP connection stats**: the health of the connections underneath that traffic, including bytes transferred, segment retransmissions, and connections that completed or failed their three-way handshake (labeled by whether OBI observed the client or the server side). Use these to spot connection churn, packet loss, and services that are failing to connect.

For the exact metric names, types, and units in both OTLP and Prometheus formats, see the **Network** family in [Exposed metrics](https://coralogix.com/docs/opentelemetry/instrumentation-options/ebpf-auto-instrumentation/exported-metrics.md#application-metrics).

## Enabling network metrics

In a Kubernetes Helm deployment, the quickest way to turn on network metrics is the `networkMetrics` preset, which is off by default:

```
opentelemetry-ebpf-instrumentation:

  presets:

    networkMetrics:

      enabled: true
```

The preset exports node-wide network-flow and TCP connection metrics between Kubernetes workloads, runs the DaemonSet with `hostNetwork`, and mounts `tracefs`. To keep the number of series bounded, it labels metrics at the workload level (owner, namespace, and cluster) and leaves out IP addresses, ports, and Pod names. It also omits `obi.network.flow.packets` and `obi.stat.tcp.io`, which are high-volume and largely duplicate other series.

For finer control, or outside the Helm preset, set the underlying metrics features directly through `metrics->features`:

* `network` turns on the network-flow metrics. Add `network_flow_packets` for packet counts and `network_inter_zone` for cross-zone bytes.
* `stats` turns on the TCP connection stats.

```
metrics:

  features:

    - application

    - network

    - stats
```

The Collector receiver exposes the same `metrics.features` list. Cross-zone bytes (`obi.network.inter.zone.bytes`) are Experimental and are produced only inside Kubernetes clusters.

## Dimensions you can slice by

Network metrics carry the endpoints and context you need to group and filter them:

* **Endpoints**: `src.address` and `dst.address`, plus the network `iface`.
* **Zones**: `src.zone` and `dst.zone`, for cross-zone analysis.
* **Kubernetes metadata**: cluster, namespace, workload, and pod attributes on both ends, when Kubernetes metadata is enabled.
* **Connection role**: `network.tcp.handshake.role` (`client` or `server`) on the TCP connection metrics.

Most of these attributes are hidden by default to keep series cardinality manageable, and you select the ones you need through `attributes->select`. The cross-zone metric is the exception: it exposes `k8s.cluster.name`, `src.zone`, and `dst.zone` by default. The `networkMetrics` Helm preset narrows the set further, keeping only workload-level labels (owner, namespace, and cluster) and leaving out `src.address`, `dst.address`, ports, and Pod names. See [Attribute selection for OBI metrics](https://coralogix.com/docs/opentelemetry/instrumentation-options/ebpf-auto-instrumentation/exported-metrics.md#attribute-selection-for-obi-metrics).

## How the data is used

Because every flow is attributed to the workloads on both ends, OBI's network metrics describe your service topology from the network up, independent of any single product surface:

* **Service-to-service traffic maps**: aggregate flow bytes by source and destination workload to see who talks to whom, and how much.
* **Cross-zone traffic cost**: watch `obi.network.inter.zone.bytes` to find traffic crossing availability zones, a common source of cloud egress charges.
* **Connection health**: track failed against successful connections and retransmissions to catch connectivity problems and network degradation before they surface as application errors.

**Example: Coralogix APM.** [Coralogix APM](https://coralogix.com/docs/user-guides/apm/features/service-map.md) is one place to put these signals to work. Its service map visualizes how your services connect, and OBI's network metrics quantify the traffic and connection health between them. APM is only one consumer, though. Because the metrics follow the OpenTelemetry conventions, you can build your own [custom dashboards](https://coralogix.com/docs/user-guides/custom-dashboards/introduction.md) and alerting rules on them just as easily.

## Limitations

* **Cross-zone metrics are Experimental and Kubernetes-only.** `obi.network.inter.zone.bytes` is produced only inside Kubernetes clusters and may change.
* **Most attributes are hidden by default.** To keep series cardinality manageable, OBI hides most network attributes until you select them through `attributes->select`.
* **The failure `reason` label is off by default** on `obi.stat.tcp.failed.connections`. Enable it only when you need per-reason breakdowns.