Merge pull request #97036 from openshift-cherrypick-robot/cherry-pick-96966-to-enterprise-4.19

lahinson · web-flow · commit a1f2b2707488 · 2025-08-01T13:11:52.000-04:00
[enterprise-4.19] OSDOCS-14543 [NETOBSERV] Change Network Observability to network observability when not referencing the Operator
diff --git a/modules/network-observability-cli-capturing-metrics.adoc b/modules/network-observability-cli-capturing-metrics.adoc
@@ -5,7 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-cli-capturing-metrics_{context}"]
 = Capturing metrics
-You can generate on-demand dashboards in Prometheus by using a service monitor for Network Observability.
+You can generate on-demand dashboards in Prometheus by using a service monitor for network observability.
 
 .Prerequisites
 * Install the {oc-first}.
@@ -20,7 +20,7 @@ You can generate on-demand dashboards in Prometheus by using a service monitor f
 $ oc netobserv metrics --enable_filter=true --cidr=0.0.0.0/0 --protocol=TCP --port=49051
 ----
 . Open the link provided in the terminal to view the *NetObserv / On-Demand* dashboard:
-+ 
++
 .Example URL
 [source,terminal]
 ----
diff --git a/modules/network-observability-con_filter-network-flows-at-ingestion.adoc b/modules/network-observability-con_filter-network-flows-at-ingestion.adoc
@@ -6,7 +6,7 @@
 [id="network-observability-filter-network-flows-at-ingestion_{context}"]
 = Filter network flows at ingestion
 
-You can create filters to reduce the number of generated network flows. Filtering network flows can reduce the resource usage of the Network Observability components.
+You can create filters to reduce the number of generated network flows. Filtering network flows can reduce the resource usage of the network observability components.
 
 You can configure two kinds of filters:
 
diff --git a/modules/network-observability-create-network-policy.adoc b/modules/network-observability-create-network-policy.adoc
@@ -5,7 +5,7 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-network-policy_{context}"]
-= Creating a network policy for Network Observability
+= Creating a network policy for network observability
 
 If you want to further customize the network policies for the `netobserv` and `netobserv-privileged` namespaces, you must disable the managed installation of the policy from the `FlowCollector` CR, and create your own. You can use the network policy resources that are enabled from the `FlowCollector` CR as a starting point for the procedure that follows:
 
diff --git a/modules/network-observability-deploy-network-policy.adoc b/modules/network-observability-deploy-network-policy.adoc
@@ -7,7 +7,7 @@
 [id="network-observability-deploy-network-policy_{context}"]
 = Configuring an ingress network policy by using the FlowCollector custom resource
 
-You can configure the `FlowCollector` custom resource (CR) to deploy an ingress network policy for Network Observability by setting the `spec.NetworkPolicy.enable` specification to `true`. By default, the specification is `false`.
+You can configure the `FlowCollector` custom resource (CR) to deploy an ingress network policy for network observability by setting the `spec.NetworkPolicy.enable` specification to `true`. By default, the specification is `false`.
 
 If you have installed Loki, Kafka or any exporter in a different namespace that also has a network policy, you must ensure that the Network Observability components can communicate with them. Consider the following about your setup:
 
diff --git a/modules/network-observability-ebpf-agent-alert.adoc b/modules/network-observability-ebpf-agent-alert.adoc
@@ -5,11 +5,11 @@
 [id="network-observability-netobserv-dashboard-ebpf-agent-alerts_{context}"]
 = Using the eBPF agent alert
 
-An alert, `NetObservAgentFlowsDropped`, is triggered when the Network Observability eBPF agent hashmap table is full or when the capacity limiter is triggered. If you see this alert, consider increasing the `cacheMaxFlows` in the `FlowCollector`, as shown in the following example.
+An alert, `NetObservAgentFlowsDropped`, is triggered when the network observability eBPF agent hashmap table is full or when the capacity limiter is triggered. If you see this alert, consider increasing the `cacheMaxFlows` in the `FlowCollector`, as shown in the following example.
 
 [NOTE]
 ====
-Increasing the `cacheMaxFlows` might increase the memory usage of the eBPF agent. 
+Increasing the `cacheMaxFlows` might increase the memory usage of the eBPF agent.
 ====
 
 .Procedure
@@ -31,7 +31,7 @@ spec:
   namespace: netobserv
   deploymentModel: Direct
   agent:
-    type: eBPF                                
+    type: eBPF
     ebpf:
       cacheMaxFlows: 200000 <1>
 ----
diff --git a/modules/network-observability-flowcollector-view.adoc b/modules/network-observability-flowcollector-view.adoc
@@ -11,9 +11,9 @@ You can view and edit YAML directly in the {product-title} web console.
 .Procedure
 . In the web console, navigate to *Operators* -> *Installed Operators*.
 . Under the *Provided APIs* heading for the *NetObserv Operator*, select *Flow Collector*.
-. Select *cluster* then select the *YAML* tab. There, you can modify the `FlowCollector` resource to configure the Network Observability operator.
+. Select *cluster* then select the *YAML* tab. There, you can modify the `FlowCollector` resource to configure the Network Observability Operator.
 
-The following example shows a sample `FlowCollector` resource for {product-title} Network Observability operator:
+The following example shows a sample `FlowCollector` resource for {product-title} Network Observability Operator:
 [id="network-observability-flowcollector-configuring-about-sample_{context}"]
 .Sample `FlowCollector` resource
 [source, yaml]
diff --git a/modules/network-observability-metrics-names.adoc b/modules/network-observability-metrics-names.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: REFERENCE
 [id="network-observability-metrics_{context}"]
-= Network Observability metrics
+= Network observability metrics
 
 You can also create alerts by using the `includeList` metrics in Prometheus rules, as shown in the example "Creating alerts".
 
diff --git a/modules/network-observability-multitenancy.adoc b/modules/network-observability-multitenancy.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-multi-tenancy_{context}"]
-= Enabling multi-tenancy in Network Observability
+= Enabling multi-tenancy in network observability
 
 Multi-tenancy in the Network Observability Operator allows and restricts individual user access, or group access, to the flows stored in Loki and or Prometheus. Access is enabled for project administrators. Project administrators who have limited access to some namespaces can access flows for only those namespaces.
 
diff --git a/modules/network-observability-networking-events-overview.adoc b/modules/network-observability-networking-events-overview.adoc
@@ -8,9 +8,9 @@
 :FeatureName: OVN-Kubernetes networking events tracking
 include::snippets/technology-preview.adoc[]
 
-You use network event tracking in Network Observability to gain insight into OVN-Kubernetes events, including network policies, admin network policies, and egress firewalls. You can use the insights from tracking network events to help with the following tasks:
+You use network event tracking in network observability to gain insight into OVN-Kubernetes events, including network policies, admin network policies, and egress firewalls. You can use the insights from tracking network events to help with the following tasks:
 
-* Network monitoring: Monitor allowed and blocked traffic, detecting whether packets are allowed or blocked based on network policies and admin network policies. 
+* Network monitoring: Monitor allowed and blocked traffic, detecting whether packets are allowed or blocked based on network policies and admin network policies.
 
 * Network security: You can track outbound traffic and see whether it adheres to egress firewall rules. Detect unauthorized outbound connections and flag outbound traffic that violates egress rules.
 
diff --git a/modules/network-observability-nodes-taints-tolerations.adoc b/modules/network-observability-nodes-taints-tolerations.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-multi-tenancy{context}"]
-= Network Observability deployment in specific nodes
+= Network observability deployment in specific nodes
 
-You can configure the `FlowCollector` to control the deployment of Network Observability components in specific nodes. The `spec.agent.ebpf.advanced.scheduling`, `spec.processor.advanced.scheduling`, and `spec.consolePlugin.advanced.scheduling` specifications have the following configurable settings:
+You can configure the `FlowCollector` to control the deployment of network observability components in specific nodes. The `spec.agent.ebpf.advanced.scheduling`, `spec.processor.advanced.scheduling`, and `spec.consolePlugin.advanced.scheduling` specifications have the following configurable settings:
 
 * `NodeSelector`
 * `Tolerations`
diff --git a/modules/network-observability-packet-translation-overview.adoc b/modules/network-observability-packet-translation-overview.adoc
@@ -5,7 +5,7 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-packet-translation-overview_{context}"]
 = Endpoint translation (xlat)
-You can gain visibility into the endpoints serving traffic in a consolidated view using Network Observability and extended Berkeley Packet Filter (eBPF). Typically, when traffic flows through a service, egressIP, or load balancer, the traffic flow information is abstracted as it is routed to one of the available pods. If you try to get information about the traffic, you can only view service related info, such as service IP and port, and not information about the specific pod that is serving the request. Often the information for both the service traffic and the virtual service endpoint is captured as two separate flows, which complicates troubleshooting. 
+You can gain visibility into the endpoints serving traffic in a consolidated view using network observability and extended Berkeley Packet Filter (eBPF). Typically, when traffic flows through a service, egressIP, or load balancer, the traffic flow information is abstracted as it is routed to one of the available pods. If you try to get information about the traffic, you can only view service related info, such as service IP and port, and not information about the specific pod that is serving the request. Often the information for both the service traffic and the virtual service endpoint is captured as two separate flows, which complicates troubleshooting.
 
 To solve this, endpoint xlat can help in the following ways:
 
diff --git a/modules/network-observability-packet-translation.adoc b/modules/network-observability-packet-translation.adoc
@@ -5,7 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-packet-translation_{context}"]
 = Working with endpoint translation (xlat)
-You can use Network Observability and eBPF to enrich network flows from a Kubernetes service with translated endpoint information, gaining insight into the endpoints serving traffic.
+You can use network observability and eBPF to enrich network flows from a Kubernetes service with translated endpoint information, gaining insight into the endpoints serving traffic.
 
 .Procedure
 . In the web console, navigate to *Operators* -> *Installed Operators*.
@@ -30,15 +30,15 @@ spec:
        - PacketTranslation   <1>
 ----
 <1> You can start enriching network flows with translated packet information by listing the `PacketTranslation` parameter in the `spec.agent.ebpf.features` specification list.
- 
+
 .Example filtering
 When you refresh the *Network Traffic* page you can filter for information about translated packets:
 
 . Filter the network flow data based on *Destination kind: Service*.
 . You can see the *xlat* column, which distinguishes where translated information is displayed, and the following default columns:
 
 * *Xlat Zone ID*
-* *Xlat Src Kubernetes Object* 
+* *Xlat Src Kubernetes Object*
 * *Xlat Dst Kubernetes Object*
 
 You can manage the display of additional *xlat* columns in *Manage columns*.
diff --git a/modules/network-observability-proc_working-with-udn.adoc b/modules/network-observability-proc_working-with-udn.adoc
@@ -6,14 +6,14 @@
 [id="network-observability-working-with-udn_{context}"]
 = Working with user-defined networks
 
-You can enable user-defined networks (UDN) in Network Observability resources.
+You can enable user-defined networks (UDN) in network observability resources.
 The following example shows the configuration for the `FlowCollector` resource.
 
 .Prerequisite
 * You have configured UDN in {openshift-networking}. For more information, see "Creating a UserDefinedNetwork by using the CLI" or "Creating a UserDefinedNetwork by using the web console."
 
 .Procedure
-. Edit the Network Observability `FlowCollector` resource by running the following command:
+. Edit the network observability `FlowCollector` resource by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/network-observability-resource-recommendations.adoc b/modules/network-observability-resource-recommendations.adoc
@@ -5,15 +5,15 @@
 [id="network-observability-resource-recommendations_{context}"]
 = Resource management and performance considerations
 
-The amount of resources required by Network Observability depends on the size of your cluster and your requirements for the cluster to ingest and store observability data. To manage resources and set performance criteria for your cluster, consider configuring the following settings. Configuring these settings might meet your optimal setup and observability needs.
+The amount of resources required by network observability depends on the size of your cluster and your requirements for the cluster to ingest and store observability data. To manage resources and set performance criteria for your cluster, consider configuring the following settings. Configuring these settings might meet your optimal setup and observability needs.
 
 The following settings can help you manage resources and performance from the outset:
 
 eBPF Sampling:: You can set the Sampling specification, `spec.agent.ebpf.sampling`, to manage resources. Smaller sampling values might consume a large amount of computational, memory and storage resources. You can mitigate this by specifying a sampling ratio value. A value of `100` means 1 flow every 100 is sampled. A value of `0` or `1` means all flows are captured. Smaller values result in an increase in returned flows and the accuracy of derived metrics. By default, eBPF sampling is set to a value of 50, so 1 flow every 50 is sampled. Note that more sampled flows also means more storage needed. Consider starting with the default values and refine empirically, in order to determine which setting your cluster can manage.
 
 eBPF features:: The more features that are enabled, the more CPU and memory are impacted. See "Observing the network traffic" for a complete list of these features.
 
-Without Loki:: You can reduce the amount of resources that Network Observability requires by not using Loki and instead relying on Prometheus. For example, when Network Observability is configured without Loki, the total savings of memory usage are in the 20-65% range and CPU utilization is lower by 10-30%, depending upon the sampling value. See "Network Observability without Loki" for more information.
+Without Loki:: You can reduce the amount of resources that network observability requires by not using Loki and instead relying on Prometheus. For example, when network observability is configured without Loki, the total savings of memory usage are in the 20-65% range and CPU utilization is lower by 10-30%, depending upon the sampling value. See "Network observability without Loki" for more information.
 
 Restricting or excluding interfaces::  Reduce the overall observed traffic by setting the values for `spec.agent.ebpf.interfaces` and `spec.agent.ebpf.excludeInterfaces`. By default, the agent fetches all the interfaces in the system, except the ones listed in `excludeInterfaces` and `lo` (local interface). Note that the interface names might vary according to the Container Network Interface (CNI) used.
 
diff --git a/modules/network-observability-viewing-dashboards.adoc b/modules/network-observability-viewing-dashboards.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-viewing-dashboards_{context}"]
-= Viewing Network Observability metrics dashboards
+= Viewing network observability metrics dashboards
 
 On the *Overview* tab in the {product-title} console, you can view the overall aggregated metrics of the network traffic flow on the cluster. You can choose to display the information by node, namespace, owner, pod, and service. You can also use filters and display options to further refine the metrics.
 
diff --git a/modules/network-observability-without-loki.adoc b/modules/network-observability-without-loki.adoc
@@ -3,9 +3,9 @@
 
 :_mod-docs-content-type: REFERENCE
 [id="network-observability-without-loki_{context}"]
-= Network Observability without Loki
+= Network observability without Loki
 
-You can use Network Observability without Loki by not performing the Loki installation steps and skipping directly to "Installing the Network Observability Operator". If you only want to export flows to a Kafka consumer or IPFIX collector, or you only need dashboard metrics, then you do not need to install Loki or provide storage for Loki. The following table compares available features with and without Loki.
+You can use network observability without Loki by not performing the Loki installation steps and skipping directly to "Installing the Network Observability Operator". If you only want to export flows to a Kafka consumer or IPFIX collector, or you only need dashboard metrics, then you do not need to install Loki or provide storage for Loki. The following table compares available features with and without Loki.
 
 .Comparison of feature availability with and without Loki
 [options="header"]
diff --git a/modules/troubleshooting-network-observability-after-installation.adoc b/modules/troubleshooting-network-observability-after-installation.adoc
@@ -82,7 +82,7 @@ $ oc delete pods -n openshift-console -l app=console
 
 . Clear your browser cache and history.
 
-. Check the status of Network Observability plugin pods by running the following command:
+. Check the status of network observability plugin pods by running the following command:
 +
 [source,terminal]
 ----
@@ -95,7 +95,7 @@ NAME                                READY   STATUS    RESTARTS   AGE
 netobserv-plugin-68c7bbb9bb-b69q6   1/1     Running   0          21s
 ----
 
-. Check the logs of the Network Observability plugin pods by running the following command:
+. Check the logs of the network observability plugin pods by running the following command:
 +
 [source,terminal]
 ----
diff --git a/modules/troubleshooting-network-observability-controller-manager-pod-out-of-memory.adoc b/modules/troubleshooting-network-observability-controller-manager-pod-out-of-memory.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="controller-manager-pod-runs-out-of-memory_{context}"]
-= Network Observability controller manager pod runs out of memory
+= Network observability controller manager pod runs out of memory
 
-You can increase memory limits for the Network Observability operator by editing the `spec.config.resources.limits.memory` specification in the `Subscription` object.
+You can increase memory limits for the Network Observability Operator by editing the `spec.config.resources.limits.memory` specification in the `Subscription` object.
 
 .Procedure
 
@@ -44,4 +44,4 @@ spec:
   startingCSV: <network_observability_operator_latest_version> <2>
 ----
 <1> For example, you can increase the memory limit to `800Mi`.
-<2> This value should not be edited, but note that it changes depending on the most current release of the Operator. 
+<2> This value should not be edited, but note that it changes depending on the most current release of the Operator.
diff --git a/modules/troubleshooting-network-observability-loki-resource-exhausted.adoc b/modules/troubleshooting-network-observability-loki-resource-exhausted.adoc
@@ -5,7 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-troubleshooting-loki-resource-exhausted_{context}"]
 = Troubleshooting Loki ResourceExhausted error
-Loki may return a `ResourceExhausted` error when network flow data sent by Network Observability exceeds the configured maximum message size. If you are using the Red{nbsp}Hat {loki-op}, this maximum message size is configured to 100 MiB.
+Loki may return a `ResourceExhausted` error when network flow data sent by network observability exceeds the configured maximum message size. If you are using the Red{nbsp}Hat {loki-op}, this maximum message size is configured to 100 MiB.
 
 .Procedure
 . Navigate to *Operators* -> *Installed Operators*, viewing *All projects* from the *Project* drop-down menu.
diff --git a/observability/network_observability/configuring-operator.adoc b/observability/network_observability/configuring-operator.adoc
@@ -38,5 +38,5 @@ include::modules/network-observability-total-resource-usage.adoc[leveloffset=+2]
 [role="_additional-resources"]
 .Additional resources
 * xref:../network_observability/observing-network-traffic.adoc#network-observability-trafficflow_nw-observe-network-traffic[Observing the network traffic from the traffic flows view]
-* xref:../network_observability/installing-operators.adoc#network-observability-without-loki_network_observability[Network Observability without Loki]
+* xref:../network_observability/installing-operators.adoc#network-observability-without-loki_network_observability[Network observability without Loki]
 * xref:../network_observability/json-flows-format-reference.adoc#network-observability-flows-format_json_reference[Network Flows format reference]
diff --git a/observability/network_observability/installing-operators.adoc b/observability/network_observability/installing-operators.adoc
diff --git a/observability/network_observability/troubleshooting-network-observability.adoc b/observability/network_observability/troubleshooting-network-observability.adoc
