Open in ChatGPTOpen in Claude

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.

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.

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 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 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.