You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: modules/network-observability-resource-recommendations.adoc
+7-3Lines changed: 7 additions & 3 deletions
Original file line number
Diff line number
Diff line change
@@ -11,10 +11,14 @@ The following settings can help you manage resources and performance from the ou
11
11
12
12
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.
13
13
14
+
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.
15
+
16
+
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.
17
+
14
18
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.
15
19
16
-
The following settings can be used to fine-tune performance after the Network Observability has been running for a while:
20
+
Performance fine-tuning:: The following settings can be used to fine-tune performance after the Network Observability has been running for a while:
17
21
18
-
Resource requirements and limits:: Adapt the resource requirements and limits to the load and memory usage you expect on your cluster by using the `spec.agent.ebpf.resources` and `spec.processor.resources` specifications. The default limits of 800MB might be sufficient for most medium-sized clusters.
22
+
* *Resource requirements and limits*: Adapt the resource requirements and limits to the load and memory usage you expect on your cluster by using the `spec.agent.ebpf.resources` and `spec.processor.resources` specifications. The default limits of 800MB might be sufficient for most medium-sized clusters.
19
23
20
-
Cache max flows timeout:: Control how often flows are reported by the agents by using the eBPF agent's `spec.agent.ebpf.cacheMaxFlows` and `spec.agent.ebpf.cacheActiveTimeout` specifications. A larger value results in less traffic being generated by the agents, which correlates with a lower CPU load. However, a larger value leads to a slightly higher memory consumption, and might generate more latency in the flow collection.
24
+
* *Cache max flows timeout*: Control how often flows are reported by the agents by using the eBPF agent's `spec.agent.ebpf.cacheMaxFlows` and `spec.agent.ebpf.cacheActiveTimeout` specifications. A larger value results in less traffic being generated by the agents, which correlates with a lower CPU load. However, a larger value leads to a slightly higher memory consumption, and might generate more latency in the flow collection.
The following table outlines averages of total resource usage for clusters with a sampling value of 1, 50, and 400 for 3 different tests: `Test 1`, `Test 2`, and `Test 3`. The tests differ in the following ways:
8
+
The following table outlines averages of total resource usage for clusters with a sampling value of `1`and `50` for two different tests: `Test 1`and `Test 2`. The tests differ in the following ways:
9
9
10
-
- `Test 1` takes into account the total number of namespace, pods and services in an {product-title} cluster, places load on the eBPF agent, and represents use cases with a high number of workloads for a given cluster size. For example, `Test 1` consists of 76 Namespaces, 5153 Pods, and 2305 Services.
11
-
- `Test 2` takes into account a high ingress traffic volume.
12
-
- `Test 3` takes into account the total number of namespace, pods and services in an {product-title} cluster, places load on the eBPF agent on a larger scale than `Test 1`, and represents use cases with a high number of workloads for a given cluster size. For example, `Test 3` consists of 553 Namespaces, 6998 Pods, and 2508 Services.
10
+
- `Test 1` takes into account high ingress traffic volume in addition to the total number of namespace, pods and services in an {product-title} cluster, places load on the eBPF agent, and represents use cases with a high number of workloads for a given cluster size. For example, `Test 1` consists of 76 Namespaces, 5153 Pods, and 2305 Services with a network traffic scale of ~350 MB/s.
11
+
- `Test 2` takes into account high ingress traffic volume in addition to the total number of namespace, pods and services in an {product-title} cluster and represents use cases with a high number of workloads for a given cluster size. For example, `Test 2` consists of 553 Namespaces, 6998 Pods, and 2508 Services with a network traffic scale of ~950 MB/s.
13
12
14
-
Since different types of cluster use cases are exemplified in the different tests, the numbers in this table cannot be linearly compared side-by-side, but instead are intended to be used as a benchmark for evaluating your personal cluster usage. The examples outlined in the table demonstrate scenarios that are tailored to specific workloads. Consider each example only as a baseline from which adjustments can be made to accommodate your workload needs.
13
+
Since different types of cluster use cases are exemplified in the different tests, the numbers in this table do not scale linearly when compared side-by-side. Instead, they are intended to be used as a benchmark for evaluating your personal cluster usage. The examples outlined in the table demonstrate scenarios that are tailored to specific workloads. Consider each example only as a baseline from which adjustments can be made to accommodate your workload needs.
15
14
16
15
[NOTE]
17
16
====
@@ -21,26 +20,13 @@ Metrics exported to Prometheus can impact the resource usage. Cardinality values
21
20
.Total average resource usage
22
21
[%autowidth, options="header"]
23
22
|===
24
-
| Sampling value | Parameters | Test 1 (25 nodes) | Test 2 (65 nodes) | Test 3 (120 nodes)
Summary: This table shows average total resource usage of Network Observability (Agents+FLP+Kafka+Loki).
32
+
Summary: This table shows average total resource usage of Network Observability, which includes Agents, FLP, Kafka, and Loki with all features enabled. For details about what features are enabled, see the features covered in "Observing the network traffic", which comprises all the features that are enabled for this testing.
* xref:../../observability/network_observability/json-flows-format-reference.adoc#network-observability-flows-format_json_reference[Network Flows format reference].
34
+
* xref:../network_observability/observing-network-traffic.adoc#network-observability-trafficflow_nw-observe-network-traffic[Observing the network traffic from the traffic flows view]
35
+
* xref:../network_observability/installing-operators.adoc#network-observability-without-loki_network_observability[Network Observability without Loki]
36
+
* xref:../network_observability/json-flows-format-reference.adoc#network-observability-flows-format_json_reference[Network Flows format reference]
0 commit comments