OSDOCS-14543 [NETOBSERV] Change Network Observability to network observability when not referencing the Operator

gwynnemonahan · gwynnemonahan · commit 3ee19e9389fe · 2025-08-01T13:52:35.000-05:00
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-create-network-policy.adoc b/modules/network-observability-create-network-policy.adoc
@@ -5,7 +5,8 @@
 
 :_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:
 
 .Example `netobserv` network policy
diff --git a/modules/network-observability-deploy-network-policy.adoc b/modules/network-observability-deploy-network-policy.adoc
@@ -6,7 +6,8 @@
 :_mod-docs-content-type: PROCEDURE
 [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,13 +4,14 @@
 
 :_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".
 
 When looking for these metrics in Prometheus, such as in the Console through *Observe* -> *Metrics*, or when defining alerts, all the metrics names are prefixed with `netobserv_`. For example, `netobserv_namespace_flows_total`. Available metrics names are as follows:
 
 includeList metrics names::
-Names followed by an asterisk `*` are enabled by default. 
+Names followed by an asterisk `*` are enabled by default.
 
 * `namespace_egress_bytes_total`
 * `namespace_egress_packets_total`
diff --git a/modules/network-observability-multitenancy.adoc b/modules/network-observability-multitenancy.adoc
@@ -4,8 +4,9 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-multi-tenancy_{context}"]
-= 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. 
+= 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.
 
 For Developers, multi-tenancy is available for both Loki and Prometheus but requires different access rights.
 
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-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-tcp-flag-syn-flood.adoc b/modules/network-observability-tcp-flag-syn-flood.adoc
@@ -5,14 +5,14 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-tcp-flag-syn-flood_{context}"]
 = Detecting SYN flooding using the FlowMetric API and TCP flags
-You can create an `AlertingRule` resouce to alert for SYN flooding. 
+You can create an `AlertingRule` resouce to alert for SYN flooding.
 
 .Procedure
 . In the web console, navigate to *Operators* -> *Installed Operators*.
 . In the *Provided APIs* heading for the *NetObserv Operator*, select *FlowMetric*.
-. In the *Project*  dropdown list, select the project of the Network Observability Operator instance. 
+. In the *Project*  dropdown list, select the project of the Network Observability Operator instance.
 . Click *Create FlowMetric*.
-. Create `FlowMetric` resources to add the following configurations: 
+. Create `FlowMetric` resources to add the following configurations:
 +
 .Configuration counting flows per destination host and resource, with TCP flags
 [source,yaml]
@@ -81,5 +81,5 @@ metadata:
 .Verification
 . In the web console, click *Manage Columns* in the *Network Traffic* table view and click *TCP flags*.
 . In the *Network Traffic* table view, filter on *TCP protocol SYN TCPFlag*. A large number of flows with the same *byteSize* indicates a SYN flood.
-. Go to *Observe* -> *Alerting* and select the *Alerting Rules* tab. 
-. Filter on *netobserv-synflood-in alert*. The alert should fire when SYN flooding occurs. 
+. Go to *Observe* -> *Alerting* and select the *Alerting Rules* tab.
+. Filter on *netobserv-synflood-in alert*. The alert should fire when SYN flooding occurs.
diff --git a/modules/network-observability-viewing-dashboards.adoc b/modules/network-observability-viewing-dashboards.adoc
@@ -4,7 +4,8 @@
 
 :_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.
 
 .Procedure
@@ -16,7 +17,7 @@ On the *Overview* tab in the {product-title} console, you can view the overall a
  * *DNS*
  * *RTT*
 
-. Select the *Netobserv/Health* dashboard. 
+. Select the *Netobserv/Health* dashboard.
 . View metrics about the health of the Operator in the following categories, with each having the subset per node, namespace, source, and destination.
 
 * *Flows*
diff --git a/modules/network-observability-without-loki.adoc b/modules/network-observability-without-loki.adoc
@@ -3,8 +3,9 @@
 
 :_mod-docs-content-type: REFERENCE
 [id="network-observability-without-loki_{context}"]
-= 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.
+= 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.
 
 .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
@@ -32,5 +32,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
