Red Hat Summit Red Hat SummitSupportKonsoleEntwicklerDemo startenKontakt

Dieser Inhalt ist in der von Ihnen ausgewählten Sprache nicht verfügbar.

Chapter 5. Network Observability Operator in OpenShift Container Platform

The Network Observability Operator for OpenShift Container Platform deploys a monitoring pipeline. This pipeline collects and enriches network traffic flows generated by the 

eBPF agent
.

5.1. Viewing statuses
Link kopieren

The Network Observability Operator provides the Flow Collector API. When a Flow Collector resource is created, it deploys pods and services to create and store network flows in the Loki log store, as well as to display dashboards, metrics, and flows in the OpenShift Container Platform web console.

Procedure

  1. Run the following command to view the state of 

    FlowCollector
    : 

    $ oc get flowcollector/cluster

    Example output

    NAME      AGENT   SAMPLING (EBPF)   DEPLOYMENT MODEL   STATUS
cluster   EBPF    50                DIRECT             Ready

  2. Check the status of pods running in the 

    netobserv
    namespace by entering the following command: 

    $ oc get pods -n netobserv

    Example output

    NAME                              READY   STATUS    RESTARTS   AGE
flowlogs-pipeline-56hbp           1/1     Running   0          147m
flowlogs-pipeline-9plvv           1/1     Running   0          147m
flowlogs-pipeline-h5gkb           1/1     Running   0          147m
flowlogs-pipeline-hh6kf           1/1     Running   0          147m
flowlogs-pipeline-w7vv5           1/1     Running   0          147m
netobserv-plugin-cdd7dc6c-j8ggp   1/1     Running   0          147m

    The 

    flowlogs-pipeline
    pods collect flows, enriches the collected flows, then send flows to the Loki storage. 
    netobserv-plugin
    pods create a visualization plugin for the OpenShift Container Platform Console.

  3. Check the status of pods running in the namespace 

    netobserv-privileged
    by entering the following command: 

    $ oc get pods -n netobserv-privileged

    Example output

    NAME                         READY   STATUS    RESTARTS   AGE
netobserv-ebpf-agent-4lpp6   1/1     Running   0          151m
netobserv-ebpf-agent-6gbrk   1/1     Running   0          151m
netobserv-ebpf-agent-klpl9   1/1     Running   0          151m
netobserv-ebpf-agent-vrcnf   1/1     Running   0          151m
netobserv-ebpf-agent-xf5jh   1/1     Running   0          151m

    The 

    netobserv-ebpf-agent
    pods monitor network interfaces of the nodes to get flows and send them to 
    flowlogs-pipeline
    pods.

  4. If you are using the Loki Operator, check the status of the 

    component
    pods of 
    LokiStack
    custom resource in the 
    netobserv
    namespace by entering the following command: 

    $ oc get pods -n netobserv

    Example output

    NAME                                                READY   STATUS    RESTARTS   AGE
lokistack-compactor-0                               1/1     Running   0          18h
lokistack-distributor-654f87c5bc-qhkhv              1/1     Running   0          18h
lokistack-distributor-654f87c5bc-skxgm              1/1     Running   0          18h
lokistack-gateway-796dc6ff7-c54gz                   2/2     Running   0          18h
lokistack-index-gateway-0                           1/1     Running   0          18h
lokistack-index-gateway-1                           1/1     Running   0          18h
lokistack-ingester-0                                1/1     Running   0          18h
lokistack-ingester-1                                1/1     Running   0          18h
lokistack-ingester-2                                1/1     Running   0          18h
lokistack-querier-66747dc666-6vh5x                  1/1     Running   0          18h
lokistack-querier-66747dc666-cjr45                  1/1     Running   0          18h
lokistack-querier-66747dc666-xh8rq                  1/1     Running   0          18h
lokistack-query-frontend-85c6db4fbd-b2xfb           1/1     Running   0          18h
lokistack-query-frontend-85c6db4fbd-jm94f           1/1     Running   0          18h

5.2. Network Observablity Operator architecture
Link kopieren

The Network Observability Operator provides the 

FlowCollector
API, which is instantiated at installation and configured to reconcile the 
eBPF agent
, the 
flowlogs-pipeline
, and the 
netobserv-plugin
components. Only a single 
FlowCollector
per cluster is supported.

The 

eBPF agent
runs on each cluster node with some privileges to collect network flows. The 
flowlogs-pipeline
receives the network flows data and enriches the data with Kubernetes identifiers. If you choose to use Loki, the 
flowlogs-pipeline
sends flow logs data to Loki for storing and indexing. The 
netobserv-plugin
, which is a dynamic OpenShift Container Platform web console plugin, queries Loki to fetch network flows data. Cluster-admins can view the data in the web console.

If you do not use Loki, you can generate metrics with Prometheus. Those metrics and their related dashboards are accessible in the web console. For more information, see "Network Observability without Loki".

Network Observability eBPF export architecture

There are three deployment model options for the Network Observability Operator.

Note

The Network Observability Operator does not manage Loki or other data stores. You must install Loki separately by using the Loki Operator. If you use Kafka, you must install it separately by using the Kafka Operator.

Service deployment model
When the spec.deploymentModel field in the FlowCollector resource is set to Service, agents are deployed per node as daemon sets. The flowlogs-pipeline is a standard deployment with a service. You can scale the flowlogs-pipeline component by using the spec.processor.consumerReplicas field.
Direct deployment model
When the spec.deploymentModel field is set to Direct, agents and the flowlogs-pipeline are both deployed per node as daemon sets. This model is suitable for technology assessments and small clusters. However, it is less memory-efficient in large clusters because each instance of flowlogs-pipeline caches the same cluster information.
Kafka deployment model (optional)

If you use the Kafka option, the 

eBPF agent
sends the network flow data to Kafka. You can scale the 
flowlogs-pipeline
component by using the 
spec.processor.consumerReplicas
field. The 
flowlogs-pipeline
component reads from the Kafka topic before sending data to Loki, as shown in the following diagram.

Network Observability using Kafka

5.3. Viewing Network Observability Operator status and configuration
Link kopieren

You can inspect the status and view the details of the 

FlowCollector
using the 
oc describe
command.

Procedure

  1. Run the following command to view the status and configuration of the Network Observability Operator: 

    $ oc describe flowcollector/cluster
Red Hat logoGithubredditYoutubeTwitter

Lernen

Testen, kaufen und verkaufen

Communitys

Über Red Hat Dokumentation

Wir helfen Red Hat Benutzern, mit unseren Produkten und Diensten innovativ zu sein und ihre Ziele zu erreichen – mit Inhalten, denen sie vertrauen können. Entdecken Sie unsere neuesten Updates.

Mehr Inklusion in Open Source

Red Hat hat sich verpflichtet, problematische Sprache in unserem Code, unserer Dokumentation und unseren Web-Eigenschaften zu ersetzen. Weitere Einzelheiten finden Sie in Red Hat Blog.

Über Red Hat

Wir liefern gehärtete Lösungen, die es Unternehmen leichter machen, plattform- und umgebungsübergreifend zu arbeiten, vom zentralen Rechenzentrum bis zum Netzwerkrand.

Theme

© 2026 Red HatNach oben