OBI network metrics quickstart

OBI can generate network metrics in any environment (physical host, virtual host, or container). It’s recommended to use a Kubernetes environment, as OBI is able to decorate each metric with the metadata of the source and destination Kubernetes entities.

The instructions in this quickstart guide focus on deploying directly to Kubernetes with the kubectl command line utility. This tutorial describes how to deploy OBI in Kubernetes from scratch. To use Helm, consult the Deploy OBI in Kubernetes with Helm documentation.

Deploy OBI with network metrics

To enable network metrics, set the following option in your OBI configuration:

Environment variables:

export OBI_NETWORK_METRICS=true

Network metrics requires metrics to be decorated with Kubernetes metadata. To enable this feature, set the following option in your OBI configuration:

Environment variables:

export OBI_KUBE_METADATA_ENABLE=true

For more configuration options, refer to the OBI configuration options.

To learn more about OBI configuration, consult the OBI configuration documentation.

Simple setup

Deploy OBI

The following YAML configuration provides a simple OBI deployment for network metrics:

apiVersion: v1
kind: ServiceAccount
metadata:
  namespace: obi
  name: obi
---
apiVersion: v1
kind: ConfigMap
metadata:
  namespace: obi
  name: obi-config
data:
  obi-config.yml: |
    network:
      enable: true
    attributes:
      kubernetes:
        enable: true
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  namespace: obi
  name: obi
spec:
  selector:
    matchLabels:
      instrumentation: obi
  template:
    metadata:
      labels:
        instrumentation: obi
    spec:
      serviceAccountName: obi
      hostNetwork: true
      dnsPolicy: ClusterFirstWithHostNet
      containers:
        - name: obi-config
          configMap:
            name: obi-config
        - name: obi
          image: otel/ebpf-instrument:latest
          securityContext:
            privileged: true
          volumeMounts:
            - mountPath: /config
              name: obi-config
          env:
            - name: OBI_CONFIG_PATH
              value: '/config/obi-config.yml'

Some observations about this configuration:

• The container image uses the latest under-development otel/ebpf-instrument:latest image.
• OBI needs to run as a DaemonSet, as it is requires only one OBI instance per node
• To listen to network packets on the host, OBI requires the hostNetwork: true permission

Verify network metrics generation

If everything works as expected, your OBI instances should be capturing and processing network flows. To test this, check the logs for the OBI DaemonSet to see some debug information being printed:

kubectl logs daemonset/obi -n obi | head

The output would be something like:

network_flow: obi.ip=172.18.0.2 iface= direction=255 src.address=10.244.0.4 dst.address=10.96.0.1

Export metrics to OpenTelemetry endpoint

After you have confirmed that network metrics are being collected, configure OBI to export the metrics in OpenTelemetry format to a collector endpoint.

Check the data export documentation to configure the OpenTelemetry exporter.

Allowed attributes

Be default, OBI includes the following attributes in the obi.network.flow.bytes metric:

• k8s.src.owner.name
• k8s.src.namespace
• k8s.dst.owner.name
• k8s.dst.namespace
• k8s.cluster.name

OBI only includes a subset of the available attributes to avoid leading to a cardinality explosion.

For example:

network:
  allowed_attributes:
    - k8s.src.owner.name
    - k8s.src.owner.type
    - k8s.dst.owner.name
    - k8s.dst.owner.type

The equivalent Prometheus metric would be:

obi.network.flow.bytes:
  k8s_src_owner_name="frontend"
  k8s_src_owner_type="deployment"
  k8s_dst_owner_name="backend"
  k8s_dst_owner_type="deployment"

The previous example would aggregate the obi.network.flow.bytes value by source and destination Kubernetes owner name and type, instead of individual pod names.

CIDR configuration

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 OBI_NETWORK_CIDRS environment variable) accepts a list of CIDR ranges, and the corresponding name.

For example, to track metrics by predefined networks:

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:
  src_cidr="cluster-internal"
  dst_cidr="private"