openshift · gwynnemonahan · Oct 24, 2025 · Oct 27, 2025 · Oct 27, 2025 · Oct 27, 2025
diff --git a/observability/network_observability/configuring-operator.adoc b/observability/network_observability/configuring-operator.adoc
@@ -7,8 +7,10 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-You can update the `FlowCollector` API resource to configure the Network Observability Operator and its managed components. The  `FlowCollector` is explicitly created during installation. Since this resource operates cluster-wide, only a single `FlowCollector` is allowed, and it must be named `cluster`. For more information, see the xref:../../observability/network_observability/flowcollector-api.adoc#network-observability-flowcollector-api-specifications_network_observability[FlowCollector API reference].
+[role="_abstract"]
+Configure the Network Observability Operator by updating the cluster-wide `FlowCollector` API resource, which must be named `cluster`. This action allows you to manage all component configurations and cluster flow collection settings.
 
+The `FlowCollector` is explicitly created during installation. Since this resource operates cluster-wide, only a single `FlowCollector` is allowed, and it must be named `cluster`. For more information, see the xref:../../observability/network_observability/flowcollector-api.adoc#network-observability-flowcollector-api-specifications_network_observability[FlowCollector API reference].
 
 include::modules/network-observability-flowcollector-view.adoc[leveloffset=+1]
 

diff --git a/observability/network_observability/flowcollector-api.adoc b/observability/network_observability/flowcollector-api.adoc
@@ -7,7 +7,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-FlowCollector is the Schema for the network flows collection API, which pilots and configures the underlying deployments.
-
+[role="_abstract"]
+The `FlowCollector` API is the underlying schema used to pilot and configure the deployments for collecting network flows. This reference guide helps you manage those critical settings.
 
 include::modules/network-observability-flowcollector-api-specifications.adoc[leveloffset=+1]
diff --git a/observability/network_observability/flowmetric-api.adoc b/observability/network_observability/flowmetric-api.adoc
@@ -7,6 +7,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-`FlowMetric` is the API allowing to create custom metrics from the collected flow logs.
+[role="_abstract"]
+The `FlowMetric` API is used to generate custom observability metrics from collected network flow logs.
 
 include::modules/network-observability-flowmetric-api-specifications.adoc[leveloffset=+1]
diff --git a/observability/network_observability/installing-operators.adoc b/observability/network_observability/installing-operators.adoc
@@ -7,7 +7,15 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
+[role="_abstract"]
+Installing the Loki Operator is recommended before using the Network Observability Operator. You can use network observability without Loki, but special considerations apply if you only need metrics or external exporters.
+
+////
+- Commenting out for now.
+- This may need to be reworked as part of NetObserv moving to the stand alone format. Network Observability Operator without Loki may be a separate user journey to setup.
+
 Installing Loki is a recommended prerequisite for using the Network Observability Operator. You can choose to use xref:../../observability/network_observability/installing-operators.adoc#network-observability-without-loki_network_observability[Network observability without Loki], but there are some considerations for doing this, described in the previously linked section.
+////
 
 The {loki-op} integrates a gateway that implements multi-tenancy and authentication with Loki for data flow storage. The `LokiStack` resource manages Loki, which is a scalable, highly-available, multi-tenant log aggregation system, and a web proxy with {product-title} authentication. The `LokiStack` proxy uses {product-title} authentication to enforce multi-tenancy and facilitate the saving and indexing of data in Loki log stores.
 

diff --git a/observability/network_observability/json-flows-format-reference.adoc b/observability/network_observability/json-flows-format-reference.adoc
@@ -7,6 +7,7 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-These are the specifications for network flows format, used both internally and when exporting flows to Kafka.
+[role="_abstract"]
+Specifications for the network flow format. This format is used both internally and when exporting flow data to Kafka.
 
 include::modules/network-observability-flows-format.adoc[leveloffset=+1]
diff --git a/observability/network_observability/metrics-alerts-dashboards.adoc b/observability/network_observability/metrics-alerts-dashboards.adoc
@@ -7,7 +7,8 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-The Network Observability Operator uses the `flowlogs-pipeline` to generate metrics from flow logs. You can utilize these metrics by setting custom alerts and viewing dashboards.
+[role="_abstract"]
+The Network Observability Operator uses the `flowlogs-pipeline` component to generate metrics from flow logs. Use these metrics to set custom alerts and view dashboards for network activity analysis.
 
 include::modules/network-observability-viewing-dashboards.adoc[leveloffset=+1]
 

diff --git a/observability/network_observability/network-observability-network-policy.adoc b/observability/network_observability/network-observability-network-policy.adoc
@@ -7,7 +7,8 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-As a user with the `admin` role, you can create a network policy for the `netobserv` namespace to secure inbound access to the Network Observability Operator.
+[role="_abstract"]
+As an administrator, you can create a network policy for the `netobserv` namespace. This policy secures inbound access to the Network Observability Operator.
 
 include::modules/network-observability-deploy-network-policy.adoc[leveloffset=+1]
 

diff --git a/observability/network_observability/network-observability-operator-monitoring.adoc b/observability/network_observability/network-observability-operator-monitoring.adoc
@@ -7,7 +7,8 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-You can use the web console to monitor alerts related to the health of the Network Observability Operator.
+[role="_abstract"]
+Use the {product-title} web console to monitor alerts related to the Network Observability Operator's health. This helps you maintain system stability and quickly detect operational issues.
 
 include::modules/network-observability-health-dashboard-overview.adoc[leveloffset=+1]
 

diff --git a/observability/network_observability/network-observability-overview.adoc b/observability/network_observability/network-observability-overview.adoc
@@ -7,7 +7,10 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-Red Hat offers cluster administrators and developers the Network Observability Operator to observe the network traffic for {product-title} clusters. The Network Observability Operator uses the eBPF technology to create network flows, which are then enriched with {product-title} information. The flows are available as Prometheus metrics or as logs in Loki. You can view and analyze this stored information in the {product-title} console for further insight and troubleshooting.
+[role="_abstract"]
+Cluster administrators and developers use the Network Observability Operator for {product-title} to observe network traffic using eBPF technology. This helps provide insights and troubleshooting data via Prometheus metrics or as logs in Loki.
+
+You can view and analyze this stored information in the {product-title} console for further insight and troubleshooting.
 
 include::modules/network-observability-operator.adoc[leveloffset=+1]
 

diff --git a/...rvability/network_observability/network-observability-scheduling-resources.adoc b/...rvability/network_observability/network-observability-scheduling-resources.adoc
@@ -5,7 +5,8 @@
 include::_attributes/common-attributes.adoc[]
 :context: network_observability_scheduling
 
-Taints and tolerations allow the node to control which pods should (or should not) be scheduled on them.
+[role="_abstract"]
+Taints and tolerations help you control which nodes host certain pods. Use these tools, along with node selectors, to guide the placement of network observability components.
 
 A node selector specifies a map of key/value pairs that are defined using custom labels on nodes and selectors specified in pods.
 

diff --git a/observability/network_observability/network-observability-secondary-networks.adoc b/observability/network_observability/network-observability-secondary-networks.adoc
@@ -6,7 +6,9 @@ include::_attributes/common-attributes.adoc[]
 :context: network-observability-secondary-networks
 
 toc::[]
-You can configure the Network Observability Operator to collect and enrich network flow data from secondary networks, such as SR-IOV and OVN-Kubernetes.
+
+[role="_abstract"]
+You can configure the Network Observability Operator to collect and enrich network flow data from secondary networks, such as `SR-IOV` and `OVN-Kubernetes`.
 
 // Note to tech review:
 // Is the existing SR-IOV example we have, "Configuring monitoring for SR-IOV interface traffic", an example of secondary network? If so, it is not through a VM, right?

diff --git a/observability/network_observability/observing-network-traffic.adoc b/observability/network_observability/observing-network-traffic.adoc
@@ -7,7 +7,8 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-As an administrator, you can observe the network traffic in the {product-title} console for detailed troubleshooting and analysis. This feature helps you get insights from different graphical representations of traffic flow. There are several available views to observe the network traffic.
+[role="_abstract"]
+As an administrator, you can observe the network traffic in the {product-title} web console for detailed troubleshooting and analysis. This feature helps you get insights from different graphical representations of traffic flow.
 
 //Overview
 include::modules/network-observability-network-traffic-overview-view.adoc[leveloffset=+1]

diff --git a/observability/network_observability/troubleshooting-network-observability.adoc b/observability/network_observability/troubleshooting-network-observability.adoc
@@ -7,7 +7,8 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-To assist in troubleshooting network observability issues, you can perform some troubleshooting actions.
+[role="_abstract"]
+To assist in troubleshooting issues with network observability, you can perform several diagnostic actions.
 
 include::modules/troubleshooting-network-observability-must-gather.adoc[leveloffset=+1]
 

diff --git a/...ability/network_observability/understanding-network-observability-operator.adoc b/...ability/network_observability/understanding-network-observability-operator.adoc
@@ -7,7 +7,8 @@ include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
-Network Observability is an OpenShift operator that deploys a monitoring pipeline to collect and enrich network traffic flows that are produced by the Network Observability eBPF agent.
+[role="_abstract"]
+The Network Observability Operator for {product-title} deploys a monitoring pipeline. This pipeline collects and enriches network traffic flows generated by the `eBPF agent`.
 
 include::modules/nw-network-observability-operator.adoc[leveloffset=+1]