Copy as Markdown[Open in ChatGPT](https://chatgpt.com/?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fopentelemetry%2Finstrumentation-options%2Febpf-auto-instrumentation%2Fnetwork-observability.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)[Open in Claude](https://claude.ai/new?q=Read%20https%3A%2F%2Fcoralogix.com%2Fdocs%2Fopentelemetry%2Finstrumentation-options%2Febpf-auto-instrumentation%2Fnetwork-observability.md%20and%20help%20me%20with%20my%20question%20about%20this%20Coralogix%20documentation%20page.)

# 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[​](#what-obi-captures "Direct link to 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[​](#enabling-network-metrics "Direct link to 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[​](#dimensions-you-can-slice-by "Direct link to 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[​](#how-the-data-is-used "Direct link to 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[​](#limitations "Direct link to 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.