openshift-docs/modules/network-observability-architecture.adoc

//Module included in the following assemblies:
//
// network_observability/understanding-network-observability.adoc

:_mod-docs-content-type: CONCEPT
[id="network-observability-architecture_{context}"]
= Network Observablity Operator architecture

[role="_abstract"]
Review the Network Observability Operator architecture, detailing how the `FlowCollector` resource manages the `eBPF agent`, which collects and enriches flows, sending the data to Loki for storage or Prometheus for metrics.

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 {product-title} 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".

image::network-observability-architecture.png[Network Observability eBPF export architecture]

If you are using the Kafka option, the eBPF agent sends the network flow data to Kafka, and the `flowlogs-pipeline` reads from the Kafka topic before sending to Loki, as shown in the following diagram.

image::network-observability-arch-kafka-FLP.png[Network Observability using Kafka]