Chapter 1. Network Observability Operator release notes 1.10


With the Network Observability Operator, administrators can observe and analyze network traffic flows for OpenShift Container Platform clusters.

These release notes track the development of the Network Observability Operator in the OpenShift Container Platform.

For an overview of the Network Observability Operator, see About Network Observability Operator.

1.1. Network Observability Operator 1.10 advisory

Review the advisory that is available for the Network Observability Operator 1.10:

The Network Observability Operator 1.10 release enhances security, improves performance, and introduces new CLI UI tools for better network flow management.

1.2.1. Network policy updates

The Network Observability Operator now supports configuring both ingress and egress network policies to control pod traffic. This enhancement improves security.

By default, the spec.NetworkPolicy.enable specification is now set to true. This means that if you use Loki or Kafka, it is recommended that you deploy the Loki Operator and Kafka instances into dedicated namespaces. This ensures that the network policies can be configured correctly to allow communication between all components.

This release brings the following new features and updates to the Network Observability Operator CLI (oc netobserv) user interface (UI):

Table view enhancements

  • Customizable columns: Click Manage Columns to select which columns to display, and tailor the table to your needs.
  • Smart filtering: Live filters now include auto-suggestions, making it easier to select the right keys and values.
  • Packet preview: When capturing packets, click a row to inspect the pcap content directly.

Terminal-based line charts enhancements

  • Metrics visualization: Real-time graphs are rendered directly in the CLI.
  • Panel selection: Choose from predefined views or customize views by using the Manage Panels pop-up menu to selectively view charts of specific metrics.

1.2.3. Network observability console improvements

The network observability console plugin includes a new view to configure the FlowCollector custom resource (CR). From this view, you can complete the following tasks:

  • Configure the FlowCollector CR.
  • Calculate your resource footprint.
  • Gain increased of issues such as configuration warnings or high metrics cardinality.

1.2.4. Performance improvements

Network Observability Operator 1.10 has improved the performance and memory footprint of the Operator, especially visible on large clusters.

This release introduces new alert functionality, and custom alert configuration. These capabilities are Technology Preview features, and must be explicitly enabled.

To view the new alerts, in the OpenShift Container Platform web console, click Observe Alerting Alerting rules.

When you enable the Technology Preview alerts functionality in the Network Observability Operator, you can view a a new Network Health dashboard in the OpenShift Container Platform web console by clicking Observe.

The Network Health dashboard provides a summary of triggered alerts, distinguishing between critical, warning, and minor issues, and also shows pending alerts.

Review the removed features that might affect your use of the Network Observability Operator 1.10 release.

The FlowCollector custom resource (CR) API version v1beta1 has been removed and is no longer supported. Use the v1beta2 version.

Review the following known issues and their recommended workarounds (where available) that might affect your use of the Network Observability Operator 1.10 release.

Upgrading to the Network Observability Operator 1.10 on OpenShift Container Platform 4.14 and earlier can fail due to a FlowCollector custom resource definition (CRD) validation error in the software catalog.

To workaround this problem, you must:

  1. Uninstall both versions of the Network Observability Operator from the software catalog in the OpenShift Container Platform web console.

    1. Keep the FlowCollector CRD installed so that it doesn’t cause any disruption in the flow collection process.
  2. Check the current name of the FlowCollector CRD by running the following command:

    $ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].name}'
    Copy to Clipboard Toggle word wrap

    Expected output:

    v1beta1
    Copy to Clipboard Toggle word wrap
  3. Check the current serving status of the FlowCollector CRD by running the following command:

    $ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].served}'
    Copy to Clipboard Toggle word wrap

    Expected output:

    true
    Copy to Clipboard Toggle word wrap
  4. Set the served flag for the v1beta1 version to false by running the following command:

    $ oc patch crd flowcollectors.flows.netobserv.io --type='json' -p "[{'op': 'replace', 'path': '/spec/versions/0/served', 'value': false}]"
    Copy to Clipboard Toggle word wrap
  5. Verify that the served flag is set to false by running the following command:

    $ oc get crd flowcollectors.flows.netobserv.io -o jsonpath='{.spec.versions[0].served}'
    Copy to Clipboard Toggle word wrap

    Expected output:

    false
    Copy to Clipboard Toggle word wrap
  6. Install Network Observability Operator 1.10.

OCPBUGS-63208, NETOBSERV-2451

The eBPF agent used in the Network Observability Command Line Interface (CLI) packet capture feature is incompatible with OpenShift Container Platform versions 4.16 and older.

This limitation prevents the eBPF-based Packet Capture Agent (PCA) from functioning correctly on those older clusters.

To work around this problem, you must manually configure PCA to use an older, compatible eBPF agent container image. For more information, see the Red Hat Knowledgebase Solution eBPF agent compatibility with older Openshift versions in Network Observability CLI 1.10+.

NETOBSERV-2358

When running Network Observability Operator 1.10 on OpenShift Container Platform 4.14 clusters that use the OpenShiftSDN CNI plugin, the eBPF agent is unable to send flow records to the flowlogs-pipeline component. This occurs when the FlowCollector custom resource is created with NetworkPolicy enabled (spec.networkPolicy.enable: true).

As a consequence, flow data is not processed by the flowlogs-pipeline component and does not appear in the Network Traffic dashboard or the configured storage (Loki). The eBPF agent pod logs show i/o timeout errors when attempting to connect to the collector:

time="2025-10-17T13:53:44Z" level=error msg="couldn't send flow records to collector" collector="10.0.68.187:2055" component=exporter/GRPCProto error="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing: dial tcp 10.0.68.187:2055: i/o timeout\""
Copy to Clipboard Toggle word wrap

To work around this problem, set spec.networkPolicy.enable to false to disable NetworkPolicy in the FlowCollector resource for Network Observability Operator 1.10.

This will allow the eBPF agent to communicate with the flowlogs-pipeline component without interference from the automatically deployed network policy.

NETOBSERV-2450

The Network Observability Operator 1.10 release contains several fixed issues that improve performance and the user experience.

1.7.1. MetricName and Remap fields are validated

Before this update, users could create a FlowMetric custom resource (CR) with an invalid metric name. Although the FlowMetric CR was successfully created, the underlying metric would fail silently without providing any error feedback to the user.

With this release, the FlowMetric, metricName, and remap fields are now validated before creation, so users are immediately notified if they enter an invalid name.

NETOBSERV-2348

1.7.2. Improved html-to-image export performance

Before this update, performance issues in the underlying library caused the html-to-image export function to take a long time, leading to browser freezing.

With this release, the performance of the html-to-image library has been improved, reducing export wait times and eliminating browser freezing during image generation.

NETOBSERV-2314

1.7.3. Improved warnings for eBPF privileged mode

Before this update, when users selected eBPF features that require privileged mode, the features would often fail without clearly informing the user that privileged mode was missing or needed to be enabled.

With this release, a validation hook immediately warns the user if the configuration is inconsistent. This improves user understanding and prevents misconfiguration.

NETOBSERV-2268

Before this update, the OpenTelemetry metrics exporter was missing the network flow labels SrcSubnetLabel and DstSubnetLabel, causing them to show as empty.

With this release, these labels are now correctly provided by the exporter. They have also been renamed to source.subnet.label and destination.subnet.label for improved clarity and consistency with OpenTelemetry standards.

NETOBSERV-2405

Before this update, a default toleration was set on all network observability components to allow them to be scheduled on any node, including those tainted with NoSchedule. This could potentially block cluster upgrades.

With this release, the default toleration is now only maintained for the eBPF agents and the Flowlogs-Pipeline when configured in Direct mode. The toleration has been removed from the OpenShift Container Platform web console plugin and the Flowlogs-Pipeline when configured in Kafka mode.

Additionally, while tolerations were always configurable in the FlowCollector custom resource (CR), it was previously impossible to replace the tolerations with an empty list. It is now possible to replace the tolerations with an empty list.

NETOBSERV-2434

Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat