:_mod-docs-content-type: ASSEMBLY
include::_attributes/common-attributes.adoc[]
[id="configuring-performance-and-scalability-uwm"]
= Configuring performance and scalability for user workload monitoring
:context: configuring-performance-and-scalability-uwm

toc::[]

You can configure the monitoring stack to optimize the performance and scale of your clusters. The following documentation provides information about how to distribute the monitoring components and control the impact of the monitoring stack on CPU and memory resources.

[id="controlling-placement-and-distribution-of-monitoing-components_{context}"]
== Controlling the placement and distribution of monitoring components

You can move the monitoring stack components to specific nodes:

* Use the `nodeSelector` constraint with labeled nodes to move any of the monitoring stack components to specific nodes.
* Assign tolerations to enable moving components to tainted nodes.

By doing so, you control the placement and distribution of the monitoring components across a cluster.

By controlling placement and distribution of monitoring components, you can optimize system resource use, improve performance, and separate workloads based on specific requirements or policies.

[role="_additional-resources"]
.Additional resources

* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#using-node-selectors-to-move-monitoring-components_key-concepts[Using node selectors to move monitoring components]

include::modules/monitoring-moving-monitoring-components-to-different-nodes.adoc[leveloffset=+2,tags=**;!CPM;UWM]

[role="_additional-resources"]
.Additional resources
// The nodes topics may apply to OSD/ROSA when that content is ported from OCP.
ifndef::openshift-dedicated,openshift-rosa[]
* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
* xref:../../../nodes/nodes/nodes-nodes-working.adoc#nodes-nodes-working-updating_nodes-nodes-working[Understanding how to update labels on nodes]
* xref:../../../nodes/scheduling/nodes-scheduler-node-selectors.adoc#nodes-scheduler-node-selectors[Placing pods on specific nodes using node selectors]
endif::openshift-dedicated,openshift-rosa[]
* link:https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector[`nodeSelector` (Kubernetes documentation)]

include::modules/monitoring-assigning-tolerations-to-monitoring-components.adoc[leveloffset=+2,tags=**;!CPM;UWM]

[role="_additional-resources"]
.Additional resources

ifndef::openshift-dedicated,openshift-rosa[]
* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
endif::openshift-dedicated,openshift-rosa[]
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
* xref:../../../nodes/scheduling/nodes-scheduler-taints-tolerations.adoc#nodes-scheduler-taints-tolerations[Controlling pod placement using node taints]
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
* link:https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/[Taints and tolerations (Kubernetes documentation)]

[id="managing-cpu-and-memory-resources-for-monitoring-components_{context}"]
== Managing CPU and memory resources for monitoring components

You can ensure that the containers that run monitoring components have enough CPU and memory resources by specifying values for resource limits and requests for those components.

You can configure these limits and requests for monitoring components that monitor user-defined projects in the `openshift-user-workload-monitoring` namespace.

include::modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc[leveloffset=+2,tags=**;!CPM;UWM]

[role="_additional-resources"]
.Additional resources
* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#about-specifying-limits-and-requests-for-monitoring-components_key-concepts[About specifying limits and requests for monitoring components]
* link:https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/#requests-and-limits[Requests and limits (Kubernetes documentation)]

[id="controlling-the-impact-of-unbound-attributes-in-user-defined-projects_{context}"]
== Controlling the impact of unbound metrics attributes in user-defined projects

ifndef::openshift-dedicated,openshift-rosa[]
Cluster administrators
endif::openshift-dedicated,openshift-rosa[]
ifdef::openshift-dedicated,openshift-rosa[]
A `dedicated-admin`
endif::openshift-dedicated,openshift-rosa[]
can use the following measures to control the impact of unbound metrics attributes in user-defined projects:

* Limit the number of samples that can be accepted per target scrape in user-defined projects
* Limit the number of scraped labels, the length of label names, and the length of label values
* Configure the intervals between consecutive scrapes and between Prometheus rule evaluations
ifndef::openshift-dedicated,openshift-rosa[]
* Create alerts that fire when a scrape sample threshold is reached or when the target cannot be scraped
endif::openshift-dedicated,openshift-rosa[]

[NOTE]
====
Limiting scrape samples can help prevent the issues caused by adding many unbound attributes to labels. Developers can also prevent the underlying cause by limiting the number of unbound attributes that they define for metrics. Using attributes that are bound to a limited set of possible values reduces the number of potential key-value pair combinations.
====

[role="_additional-resources"]
.Additional resources

* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#controlling-the-impact-of-unbound-attributes-in-user-defined-projects_key-concepts[Controlling the impact of unbound metrics attributes in user-defined projects]
ifndef::openshift-dedicated,openshift-rosa[]
* xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#enabling-monitoring-for-user-defined-projects-uwm_preparing-to-configure-the-monitoring-stack-uwm[Enabling monitoring for user-defined projects]
endif::openshift-dedicated,openshift-rosa[]
* xref:../../../observability/monitoring/troubleshooting-monitoring-issues.adoc#determining-why-prometheus-is-consuming-disk-space_troubleshooting-monitoring-issues[Determining why Prometheus is consuming a lot of disk space]

include::modules/monitoring-setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects.adoc[leveloffset=+2]

ifndef::openshift-dedicated,openshift-rosa[]
include::modules/monitoring-creating-scrape-sample-alerts.adoc[leveloffset=+2]
endif::openshift-dedicated,openshift-rosa[]

//Configuring pod topology spread constraints for monitoring of user-defined projects
include::modules/monitoring-configuring-pod-topology-spread-constraints.adoc[leveloffset=+1,tags=**;!CPM;UWM]

[role="_additional-resources"]
.Additional resources

* xref:../../../observability/monitoring/about-ocp-monitoring/key-concepts.adoc#using-pod-topology-spread-constraints-for-monitoring_key-concepts[About pod topology spread constraints for monitoring]
ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
* xref:../../../nodes/scheduling/nodes-scheduler-pod-topology-spread-constraints.adoc#nodes-scheduler-pod-topology-spread-constraints-about[Controlling pod placement by using pod topology spread constraints]
endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[]
* link:https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/[Pod topology spread constraints (Kubernetes documentation)]
