[enterprise-4.15] OSDOCS-15287 [NETOBSERV] Line breaks for observing-network-traffic.adoc assembly and its includes

gwynnemonahan · Michael Burke · commit c7b20d6cdbcb · 2025-08-06T11:59:44.000-04:00
diff --git a/modules/network-observability-RTT-overview.adoc b/modules/network-observability-RTT-overview.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-RTT-overview_{context}"]
 = Round-Trip Time
+
 You can use TCP smoothed Round-Trip Time (sRTT) to analyze network flow latencies. You can use RTT captured from the `fentry/tcp_rcv_established` eBPF hookpoint to read sRTT from the TCP socket to help with the following:
 
 
diff --git a/modules/network-observability-RTT.adoc b/modules/network-observability-RTT.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-RTT_{context}"]
 = Working with RTT tracing
+
 You can track RTT by editing the `FlowCollector` to the specifications in the following YAML example.
 
 .Procedure
@@ -30,7 +31,7 @@ spec:
        - FlowRTT   <1>
 ----
 <1> You can start tracing RTT network flows by listing the `FlowRTT` parameter in the `spec.agent.ebpf.features` specification list.
- 
+
 .Verification
 When you refresh the *Network Traffic* page, the *Overview*, *Traffic Flow*, and *Topology* views display new information about RTT:
 
@@ -39,9 +40,9 @@ When you refresh the *Network Traffic* page, the *Overview*, *Traffic Flow*, and
 .. In the *Traffic Flows* view, you can also expand the side panel to view more information about RTT.
 +
 .Example filtering
-... Click the *Common* filters -> *Protocol*. 
+... Click the *Common* filters -> *Protocol*.
 ... Filter the network flow data based on *TCP*, *Ingress* direction, and look for *FlowRTT* values greater than 10,000,000 nanoseconds (10ms).
-... Remove the *Protocol* filter. 
+... Remove the *Protocol* filter.
 ... Filter for *Flow RTT* values greater than 0 in the *Common* filters.
 
 .. In the *Topology* view, click the Display option dropdown. Then click *RTT* in the *edge labels* drop-down list.
diff --git a/modules/network-observability-configuring-options-overview.adoc b/modules/network-observability-configuring-options-overview.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: REFERENCE
 [id="network-observability-configuring-options-overview_{context}"]
 = Configuring advanced options for the Overview view
+
 You can customize the graphical view by using advanced options. To access the advanced options, click *Show advanced options*. You can configure the details in the graph by using the *Display options* drop-down menu. The options available are as follows:
 
 * *Scope*: Select to view the components that network traffic flows between. You can set the scope to *Node*, *Namespace*, *Owner*, *Zones*, *Cluster* or *Resource*. *Owner* is an aggregation of resources. *Resource* can be a pod, service, node, in case of host-network traffic, or an unknown IP address. The default value is *Namespace*.
@@ -14,7 +15,7 @@ You can customize the graphical view by using advanced options. To access the ad
 == Managing panels and display
 You can select the required panels to be displayed, reorder them, and focus on a specific panel. To add or remove panels, click *Manage panels*.
 
-The following panels are shown by default: 
+The following panels are shown by default:
 
 * *Top X average bytes rates*
 * *Top X bytes rates stacked with total*
diff --git a/modules/network-observability-configuring-options-topology.adoc b/modules/network-observability-configuring-options-topology.adoc
@@ -5,12 +5,13 @@
 :_mod-docs-content-type: REFERENCE
 [id="network-observability-configuring-options-topology_{context}"]
 = Configuring the advanced options for the Topology view
+
 You can customize and export the view by using *Show advanced options*. The advanced options view has the following features:
 
 * *Find in view*: To search the required components in the view.
 * *Display options*: To configure the following options:
 +
-** *Edge labels*: To show the specified measurements as edge labels. The default is to show the *Average rate* in *Bytes*. 
+** *Edge labels*: To show the specified measurements as edge labels. The default is to show the *Average rate* in *Bytes*.
 ** *Scope*: To select the scope of components between which the network traffic flows. The default value is *Namespace*.
 ** *Groups*: To enhance the understanding of ownership by grouping the components. The default value is *None*.
 
diff --git a/modules/network-observability-configuring-options-trafficflow.adoc b/modules/network-observability-configuring-options-trafficflow.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-configuring-options-trafficflow_{context}"]
 = Configuring advanced options for the Traffic flows view
+
 You can customize and export the view by using *Show advanced options*.
 You can set the row size by using the *Display options* drop-down menu. The default value is *Normal*.
 
diff --git a/modules/network-observability-dns-overview.adoc b/modules/network-observability-dns-overview.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-dns-overview_{context}"]
 = DNS tracking
+
 You can configure graphical representation of Domain Name System (DNS) tracking of network flows in the *Overview* view. Using DNS tracking with extended Berkeley Packet Filter (eBPF) tracepoint hooks can serve various purposes:
 
 * Network Monitoring: Gain insights into DNS queries and responses, helping network administrators identify unusual patterns, potential bottlenecks, or performance issues.
diff --git a/modules/network-observability-dns-tracking.adoc b/modules/network-observability-dns-tracking.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-dns-tracking_{context}"]
 = Working with DNS tracking
+
 Using DNS tracking, you can monitor your network, conduct security analysis, and troubleshoot DNS issues. You can track DNS by editing the `FlowCollector` to the specifications in the following YAML example.
 
 [IMPORTANT]
@@ -44,5 +45,5 @@ spec:
 
 [NOTE]
 ====
-TCP handshake packets do not have DNS headers. TCP protocol flows without DNS headers are shown in the traffic flow data with *DNS Latency*, *ID*, and *Response code* values of "n/a". You can filter out flow data to view only flows that have DNS headers using the *Common* filter "DNSError" equal to "0". 
+TCP handshake packets do not have DNS headers. TCP protocol flows without DNS headers are shown in the traffic flow data with *DNS Latency*, *ID*, and *Response code* values of "n/a". You can filter out flow data to view only flows that have DNS headers using the *Common* filter "DNSError" equal to "0".
 ====
diff --git a/modules/network-observability-ebpf-rule-flow-filter.adoc b/modules/network-observability-ebpf-rule-flow-filter.adoc
@@ -5,8 +5,11 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-ebpf-flow-rule-filter_{context}"]
 = eBPF flow rule filter
+
 You can use rule-based filtering to control the volume of packets cached in the eBPF flow table. For example, a filter can specify that only packets coming from port 100 should be recorded. Then only the packets that match the filter are cached and the rest are not cached. 
 
+You can apply multiple filter rules.
+
 [id="ingress-and-egress-traffic-filtering_{context}"]
 == Ingress and egress traffic filtering
 CIDR notation efficiently represents IP address ranges by combining the base IP address with a prefix length. For both ingress and egress traffic, the source IP address is first used to match filter rules configured with CIDR notation. If there is a match, then the filtering proceeds. If there is no match, then the destination IP is used to match filter rules configured with CIDR notation. 
@@ -15,4 +18,4 @@ After matching either the source IP or the destination IP CIDR, you can pinpoint
 
 [id="dashboard-and-metrics-integrations_{context}"]
 == Dashboard and metrics integrations
-When this option is enabled, the *Netobserv/Health* dashboard for *eBPF agent statistics* now has the *Filtered flows rate* view. Additionally, in *Observe* -> *Metrics* you can query `netobserv_agent_filtered_flows_total` to observe metrics with the reason in *FlowFilterAcceptCounter*, *FlowFilterNoMatchCounter* or *FlowFilterRecjectCounter*.
+When this option is enabled, the *Netobserv/Health* dashboard for *eBPF agent statistics* now has the *Filtered flows rate* view. Additionally, in *Observe* -> *Metrics* you can query `netobserv_agent_filtered_flows_total` to observe metrics with the reason in *FlowFilterAcceptCounter*, *FlowFilterNoMatchCounter* or *FlowFilterRecjectCounter*.
diff --git a/modules/network-observability-filtering-ebpf-rule.adoc b/modules/network-observability-filtering-ebpf-rule.adoc
@@ -5,7 +5,14 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-filtering-ebpf-rule_{context}"]
 = Filtering eBPF flow data using a global rule
-You can configure the `FlowCollector` to filter eBPF flows using a global rule to control the flow of packets cached in the eBPF flow table.
+
+You can configure the `FlowCollector` custom resource to filter eBPF flows using multiple rules to control the flow of packets cached in the eBPF flow table.
+
+[IMPORTANT]
+====
+* You cannot use duplicate Classless Inter-Domain Routing (CIDRs) in filter rules.
+* When an IP address matches multiple filter rules, the rule with the most specific CIDR prefix (longest prefix) takes precedence.
+====
 
 .Procedure
 . In the web console, navigate to *Operators* -> *Installed Operators*.
@@ -71,4 +78,4 @@ spec:
 <2> The `cidr` value of `0.0.0.0/0` matches against any IP address.
 <3> See flows after `peerIP` is configured with `192.168.127.12`. 
 <4> You must set `spec.agent.ebpf.flowFilter.enable` to `true` to enable the feature.
-====
+====
diff --git a/modules/network-observability-flow-filter-parameters.adoc b/modules/network-observability-flow-filter-parameters.adoc
@@ -5,6 +5,7 @@
 
 [id="network-observability-flowcollector-flowfilter-parameters_{context}"]
 = Flow filter configuration parameters
+
 The flow filter rules consist of required and optional parameters.
 
 .Required configuration parameters
diff --git a/modules/network-observability-histogram-trafficflow.adoc b/modules/network-observability-histogram-trafficflow.adoc
@@ -5,4 +5,5 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-histogram-trafficflow_{context}"]
 == Using the histogram
+
 You can click *Show histogram* to display a toolbar view for visualizing the history of flows as a bar chart. The histogram shows the number of logs over time. You can select a part of the histogram to filter the network flow data in the table that follows the toolbar.
diff --git a/modules/network-observability-network-traffic-overview-view.adoc b/modules/network-observability-network-traffic-overview-view.adoc
@@ -5,4 +5,5 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-network-traffic-overview-view_{context}"]
 = Observing the network traffic from the Overview view
+
 The *Overview* view displays the overall aggregated metrics of the network traffic flow on the cluster. As an administrator, you can monitor the statistics with the available display options.
diff --git a/modules/network-observability-packet-drops.adoc b/modules/network-observability-packet-drops.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-packet-drops_{context}"]
 = Working with packet drops
+
 Packet loss occurs when one or more packets of network flow data fail to reach their destination. You can track these drops by editing the `FlowCollector` to the specifications in the following YAML example.
 
 [IMPORTANT]
diff --git a/modules/network-observability-packet-translation-overview.adoc b/modules/network-observability-packet-translation-overview.adoc
@@ -5,6 +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.
 
 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,6 +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.
 
 .Procedure
diff --git a/modules/network-observability-pktdrop-overview.adoc b/modules/network-observability-pktdrop-overview.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-pktdrop-overview_{context}"]
 = Packet drop tracking
+
 You can configure graphical representation of network flow records with packet loss in the *Overview* view. By employing eBPF tracepoint hooks, you can gain valuable insights into packet drops for TCP, UDP, SCTP, ICMPv4, and ICMPv6 protocols, which can result in the following actions:
 
 * Identification: Pinpoint the exact locations and network paths where packet drops are occurring. Determine whether specific devices, interfaces, or routes are more prone to drops.
@@ -13,11 +14,11 @@ You can configure graphical representation of network flow records with packet l
 
 * Performance optimization: With a clearer picture of packet drops, you can take steps to optimize network performance, such as adjust buffer sizes, reconfigure routing paths, or implement Quality of Service (QoS) measures.
 
-When packet drop tracking is enabled, you can see the following panels in the *Overview* by default: 
+When packet drop tracking is enabled, you can see the following panels in the *Overview* by default:
 
 * *Top X packet dropped state stacked with total*
 * *Top X packet dropped cause stacked with total*
-* *Top X average dropped packets rates* 
+* *Top X average dropped packets rates*
 * *Top X dropped packets rates stacked with total*
 
 Other packet drop panels are available to add in *Manage panels*:
diff --git a/modules/network-observability-quickfilter.adoc b/modules/network-observability-quickfilter.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: REFERENCE
 [id="network-observability-quickfilter{context}"]
 = Filtering the network traffic
+
 By default, the Network Traffic page displays the traffic flow data in the cluster based on the default filters configured in the `FlowCollector` instance. You can use the filter options to observe the required data by changing the preset filter.
 
 Query Options::
diff --git a/modules/network-observability-topology.adoc b/modules/network-observability-topology.adoc
@@ -5,4 +5,5 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-topology_{context}"]
 = Observing the network traffic from the Topology view
+
 The *Topology* view provides a graphical representation of the network flows and the amount of traffic. As an administrator, you can monitor the traffic data across the application by using the *Topology* view.
diff --git a/modules/network-observability-trafficflow.adoc b/modules/network-observability-trafficflow.adoc
@@ -5,4 +5,5 @@
 :_mod-docs-content-type: CONCEPT
 [id="network-observability-trafficflow_{context}"]
 = Observing the network traffic from the Traffic flows view
+
 The *Traffic flows* view displays the data of the network flows and the amount of traffic in a table. As an administrator, you can monitor the amount of traffic across the application by using the traffic flow table.
diff --git a/modules/network-observability-working-with-conversations.adoc b/modules/network-observability-working-with-conversations.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-working-with-conversations_{context}"]
 = Working with conversation tracking
+
 As an administrator, you can group network flows that are part of the same conversation. A conversation is defined as a grouping of peers that are identified by their IP addresses, ports, and protocols, resulting in an unique *Conversation Id*. You can query conversation events in the web console. These events are represented in the web console as follows:
 
 ** *Conversation start*: This event happens when a connection is starting or TCP flag intercepted
diff --git a/modules/network-observability-working-with-overview.adoc b/modules/network-observability-working-with-overview.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-working-with-overview_{context}"]
 = Working with the Overview view
+
 As an administrator, you can navigate to the *Overview* view to see the graphical representation of the flow rate statistics.
 
 .Procedure
diff --git a/modules/network-observability-working-with-topology.adoc b/modules/network-observability-working-with-topology.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-working-with-topology_{context}"]
 = Working with the Topology view
+
 As an administrator, you can navigate to the *Topology* view to see the details and metrics of the component.
 
 .Procedure
diff --git a/modules/network-observability-working-with-trafficflow.adoc b/modules/network-observability-working-with-trafficflow.adoc
@@ -5,6 +5,7 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-working-with-trafficflow_{context}"]
 = Working with the Traffic flows view
+
 As an administrator, you can navigate to *Traffic flows* table to see network flow information.
 
 .Procedure
diff --git a/modules/network-observability-working-with-zones.adoc b/modules/network-observability-working-with-zones.adoc
@@ -5,7 +5,8 @@
 :_mod-docs-content-type: PROCEDURE
 [id="network-observability-zones{context}"]
 = Working with availability zones
-You can configure the `FlowCollector` to collect information about the cluster availability zones. This allows you to enrich network flow data with the link:https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone[`topology.kubernetes.io/zone`] label value applied to the nodes.  
+
+You can configure the `FlowCollector` to collect information about the cluster availability zones. This allows you to enrich network flow data with the link:https://kubernetes.io/docs/reference/labels-annotations-taints/#topologykubernetesiozone[`topology.kubernetes.io/zone`] label value applied to the nodes.
 
 .Procedure
 . In the web console, go to *Operators* -> *Installed Operators*.
@@ -31,5 +32,5 @@ spec:
 When you refresh the *Network Traffic* page, the *Overview*, *Traffic Flow*, and *Topology* views display new information about availability zones:
 
 . In the *Overview* tab, you can see *Zones* as an available *Scope*.
-. In *Network Traffic* -> *Traffic flows*, *Zones* are viewable under the SrcK8S_Zone and DstK8S_Zone fields. 
+. In *Network Traffic* -> *Traffic flows*, *Zones* are viewable under the SrcK8S_Zone and DstK8S_Zone fields.
 . In the *Topology* view, you can set *Zones* as *Scope* or *Group*.
