OSDOCS-16182 [NETOBSERV] Rename sampling ratio/rate to internval

Author: gwynnemonahan

modules/network-observability-con_filter-network-flows-at-ingestion.adoc

@@ -78,6 +78,6 @@ spec:
         sampling: 10  <2>
 ----
 <1> Sends matching flows to a specific output, such as Loki, Prometheus, or an external system. When omitted, sends to all configured outputs.
-<2> Optional. Applies a sampling ratio to limit the number of matching flows to be stored or exported. For example, `sampling: 10` means 1/10 of the flows are kept.
+<2> Optional. Applies a sampling interval to limit the number of matching flows to be stored or exported. For example, `sampling: 10` means that there is a 1 in 10 chance that a flow will be kept.
 
 

modules/network-observability-filtering-ebpf-rule.adoc

@@ -52,8 +52,8 @@ spec:
 ----
 <1> To enable eBPF flow filtering, set `spec.agent.ebpf.flowFilter.enable` to `true`.
 <2> To define the action for the flow filter rule, set the required `action` parameter. Valid values are `Accept` or `Reject`.
-<3> To define the IP address and CIDR mask for the flow filter rule, set the required `cidr` parameter. This parameter supports both IPv4 and IPv6 address formats. To match any IP address, use `0.0.0.0/0` for IPv4 or `::/0` for IPv6.
-<4> To define the sampling rate for matched flows and override the global sampling setting `spec.agent.ebpf.sampling`, set the `sampling` parameter.
+<3> To define the IP address and CIDR mask for the flow filter rule, set the required `cidr` parameter. This parameter supports both IPv4 and IPv6 address formats. To match any IP address, use `0.0.0.0/0` for IPv4 or ``::/0` for IPv6.
+<4> To define the sampling interval for matched flows and override the global sampling setting `spec.agent.ebpf.sampling`, set the `sampling` parameter.
 <5> To filter flows by Peer IP CIDR, set the `peerCIDR` parameter.
 
 .Example YAML to filter flows with packet drops

modules/network-observability-flowcollector-view.adoc

@@ -78,7 +78,7 @@ spec:
         dst_kind: 'Service'
 ----
 <1> The Agent specification, `spec.agent.type`, must be `EBPF`. eBPF is the only {product-title} supported option.
-<2> You can set the Sampling specification, `spec.agent.ebpf.sampling`, to manage resources. Lower 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. The lower the value, the 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. It is recommend to start with default values and refine empirically, to determine which setting your cluster can manage.
+<2> You can set the Sampling specification, `spec.agent.ebpf.sampling`, to manage resources. By default, eBPF sampling is set to `50`, so a flow has a 1 in 50 chance of being sampled. A lower sampling interval value requires more computational, memory, and storage resources. A value of `0` or `1` means all flows are sampled. It is recommended to start with the default value and refine it empirically to determine the optimal setting for your cluster.
 <3> The Processor specification `spec.processor.` can be set to enable conversation tracking. When enabled, conversation events are queryable in the web console. The `spec.processor.logTypes` value is `Flows`. The `spec.processor.advanced` values are `Conversations`, `EndedConversations`, or `ALL`. Storage requirements are highest for `All` and lowest for `EndedConversations`.
 <4> The Loki specification, `spec.loki`, specifies the Loki client. The default values match the Loki install paths mentioned in the Installing the Loki Operator section. If you used another installation method for Loki, specify the appropriate client information for your install.
 <5> The `LokiStack` mode automatically sets a few configurations: `querierUrl`, `ingesterUrl` and `statusUrl`, `tenantID`, and corresponding TLS configuration. Cluster roles and a cluster role binding are created for reading and writing logs to Loki. And `authToken` is set to `Forward`. You can set these manually using the `Manual` mode.

modules/network-observability-resource-recommendations.adoc

@@ -9,11 +9,11 @@ The amount of resources required by network observability depends on the size of
 
 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 Sampling:: You can set the Sampling specification, `spec.agent.ebpf.sampling`, to manage resources. By default, eBPF sampling is set to `50`, so a flow has a 1 in 50 chance of being sampled. A lower sampling interval value requires more computational, memory, and storage resources. A value of `0` or `1` means all flows are sampled. It is recommended to start with the default value and refine it empirically to determine the optimal setting for your cluster.
 
 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 interval 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.
 

modules/network-observability-resources-table.adoc

@@ -19,7 +19,7 @@ The examples outlined in the table demonstrate scenarios that are tailored to sp
 | *Worker Node vCPU and memory*       | 4 vCPUs\| 16GiB mem ^[1]^ | 16 vCPUs\| 64GiB mem  ^[1]^  |16 vCPUs\| 64GiB Mem ^[1]^
 | *LokiStack size*                    | `1x.extra-small`         | `1x.small`          | `1x.medium`
 | *Network Observability controller memory limit* | 400Mi (default)        | 400Mi (default)    | 400Mi (default)
-| *eBPF sampling rate*                | 50 (default)           | 50 (default)      | 50 (default)
+| *eBPF sampling interval*                | 50 (default)           | 50 (default)      | 50 (default)
 | *eBPF memory limit*                 | 800Mi (default)        | 800Mi (default)   | 1600Mi
 | *cacheMaxSize*                      | 50,000                 | 100,000 (default) | 100,000 (default)
 | *FLP memory limit*                  | 800Mi (default)        | 800Mi (default)   | 800Mi (default)