Network metrics

OpenTelemetry eBPF Instrumentation can be configured to provide network metrics between different endpoints. For example, between physical nodes, containers, Kubernetes pods, services, etc.

Get started

To get started using OBI networking metrics, consult the quickstart setup documentation, and for advanced configuration, consult the configuration documentation.

Network metrics

OBI provides byte and packet flow metrics, plus an inter-zone byte metric:

Flow metrics: capture the bytes sent and received between different endpoints, from the application point of view.

• obi.network.flow.bytes, if it is exported via OpenTelemetry.
• obi_network_flow_bytes_total, if it is exported by a Prometheus endpoint.
• To enable it, add the network option to the OTEL_EBPF_METRICS_FEATURES configuration option.

Flow packet metrics: count the packets sent and received between endpoints.

• obi.network.flow.packets, if exported via OpenTelemetry.
• obi_network_flow_packets_total, if exported by a Prometheus endpoint.
• To enable it, add the network_flow_packets option to OTEL_EBPF_METRICS_FEATURES.

Inter-zone metrics: capture the bytes sent and received between different availability zones, from the application point of view.

• obi.network.inter.zone.bytes, if it is exported via OpenTelemetry.
• obi_network_inter_zone_bytes_total, if it is exported by a Prometheus endpoint.
• To enable it, add the network_inter_zone option to the OTEL_EBPF_METRICS_FEATURES configuration option.

By default, network flow bytes include direction. When Kubernetes metadata is enabled, they also include k8s.src.owner.name, k8s.src.owner.type, k8s.src.namespace, k8s.dst.owner.name, k8s.dst.owner.type, k8s.dst.namespace, and k8s.cluster.name.

For the inter-zone bytes metric, the default attributes are k8s.cluster.name, src.zone, and dst.zone.

Metric attributes

Network metrics are labeled with the following attributes:

Metric reduction

For high-cardinality reductions, the network metrics are pre-aggregated at the process level to reduce the number of metrics sent to the metrics backend.

The metric’s selected attributes determine the aggregation keys. OBI leaves many high-cardinality attributes, including endpoint addresses and ports, out by default. See the exported metrics page for the default selection. Configure additional keys under attributes.select.

For example, to aggregate network metrics only by source and destination Kubernetes owner name and type, you can use the following configuration. It replaces the default attribute selection, including direction:

attributes:
  select:
    obi_network_flow_bytes:
      include:
        - k8s.src.owner.name
        - k8s.dst.owner.name
        - k8s.src.owner.type
        - k8s.dst.owner.type

Then, the equivalent Prometheus metric would be:

obi_network_flow_bytes_total:
  k8s_src_owner_name="frontend"
  k8s_src_owner_type="deployment"
  k8s_dst_owner_name="backend"
  k8s_dst_owner_type="deployment"

This example aggregates obi.network.flow.bytes by source and destination Kubernetes owner name and type. It omits the default direction, namespace, and cluster labels.

CIDR-based metrics

You can configure OBI to also break down metrics by CIDR ranges. This is useful for tracking traffic to specific network ranges, such as cloud provider IP ranges, or internal/external traffic.

The cidrs YAML subsection in network (or the OTEL_EBPF_NETWORK_CIDRS environment variable) accepts a list of CIDR ranges, and the corresponding name. For example:

network:
  cidrs:
    - cidr: 10.0.0.0/8
      name: 'cluster-internal'
    - cidr: 192.168.0.0/16
      name: 'private'
    - cidr: 172.16.0.0/12
      name: 'container-internal'

Then, the equivalent Prometheus metric would be:

obi_network_flow_bytes_total:
  src_cidr="cluster-internal"
  dst_cidr="private"