OBSDOCS-819: Add and implement attributes for the Cluster Monitoring Operator

eromanova97 · eromanova97 · commit bdee332017c5 · 2024-07-09T15:16:23.000+02:00
diff --git a/_attributes/common-attributes.adoc b/_attributes/common-attributes.adoc
@@ -147,6 +147,10 @@ endif::[]
 //observability
 :ObservabilityLongName: Red Hat OpenShift Observability
 :ObservabilityShortName: Observability
+// Cluster Monitoring Operator
+:cmo-first: Cluster Monitoring Operator (CMO)
+:cmo-full: Cluster Monitoring Operator
+:cmo-short: CMO
 //power monitoring
 :PM-title-c: Power monitoring for Red Hat OpenShift
 :PM-title: power monitoring for Red Hat OpenShift
diff --git a/modules/cluster-monitoring-operator.adoc b/modules/cluster-monitoring-operator.adoc
@@ -3,12 +3,12 @@
 // * operators/operator-reference.adoc
 
 [id="cluster-monitoring-operator_{context}"]
-= Cluster Monitoring Operator
+= {cmo-full}
 
 [discrete]
 == Purpose
 
-The Cluster Monitoring Operator manages and updates the Prometheus-based cluster monitoring stack deployed on top of {product-title}.
+The {cmo-first} manages and updates the Prometheus-based cluster monitoring stack deployed on top of {product-title}.
 
 [discrete]
 == Project
diff --git a/modules/infrastructure-moving-monitoring.adoc b/modules/infrastructure-moving-monitoring.adoc
@@ -7,7 +7,7 @@
 = Moving the monitoring solution
 
 The monitoring stack includes multiple components, including Prometheus, Thanos Querier, and Alertmanager.
-The Cluster Monitoring Operator manages this stack. To redeploy the monitoring stack to infrastructure nodes, you can create and apply a custom config map.
+The {cmo-full} manages this stack. To redeploy the monitoring stack to infrastructure nodes, you can create and apply a custom config map.
 
 .Procedure
 
diff --git a/modules/monitoring-common-terms.adoc b/modules/monitoring-common-terms.adoc
@@ -14,8 +14,8 @@ Alertmanager handles alerts received from Prometheus. Alertmanager is also respo
 Alerting rules::
 Alerting rules contain a set of conditions that outline a particular state within a cluster. Alerts are triggered when those conditions are true. An alerting rule can be assigned a severity that defines how the alerts are routed.
 
-Cluster Monitoring Operator::
-The Cluster Monitoring Operator (CMO) is a central component of the monitoring stack. It deploys and manages Prometheus instances such as, the Thanos Querier, the Telemeter Client, and metrics targets to ensure that they are up to date. The CMO is deployed by the Cluster Version Operator (CVO).
+{cmo-full}::
+The {cmo-first} is a central component of the monitoring stack. It deploys and manages Prometheus instances such as, the Thanos Querier, the Telemeter Client, and metrics targets to ensure that they are up to date. The {cmo-short} is deployed by the Cluster Version Operator (CVO).
 
 Cluster Version Operator::
 The Cluster Version Operator (CVO) manages the lifecycle of cluster Operators, many of which are installed in {product-title} by default.
diff --git a/modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc b/modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc
@@ -11,7 +11,7 @@ You can configure different alert receivers for default platform alerts and user
 * All default platform alerts are sent to a receiver owned by the team in charge of these alerts.
 * All user-defined alerts are sent to another receiver so that the team can focus only on platform alerts.
 
-You can achieve this by using the `openshift_io_alert_source="platform"` label that is added by the Cluster Monitoring Operator to all platform alerts:
+You can achieve this by using the `openshift_io_alert_source="platform"` label that is added by the {cmo-full} to all platform alerts:
 
 * Use the `openshift_io_alert_source="platform"` matcher to match default platform alerts.
 * Use the `openshift_io_alert_source!="platform"` or `'openshift_io_alert_source=""'` matcher to match user-defined alerts.
diff --git a/modules/monitoring-configuring-pod-topology-spread-constraints.adoc b/modules/monitoring-configuring-pod-topology-spread-constraints.adoc
@@ -8,7 +8,7 @@
 
 You can configure pod topology spread constraints for 
 ifndef::openshift-dedicated,openshift-rosa[]
-all the pods deployed by the Cluster Monitoring Operator
+all the pods deployed by the {cmo-full}
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 all the pods for user-defined monitoring
diff --git a/modules/monitoring-configuring-the-monitoring-stack.adoc b/modules/monitoring-configuring-the-monitoring-stack.adoc
@@ -7,10 +7,10 @@
 = Configuring the monitoring stack
 
 ifndef::openshift-dedicated,openshift-rosa[]
-In {product-title} {product-version}, you can configure the monitoring stack using the `cluster-monitoring-config` or `user-workload-monitoring-config` `ConfigMap` objects. Config maps configure the Cluster Monitoring Operator (CMO), which in turn configures the components of the stack.
+In {product-title} {product-version}, you can configure the monitoring stack using the `cluster-monitoring-config` or `user-workload-monitoring-config` `ConfigMap` objects. Config maps configure the {cmo-first}, which in turn configures the components of the stack.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
-In {product-title}, you can configure the stack that monitors workloads for user-defined projects by using the `user-workload-monitoring-config` `ConfigMap` object. Config maps configure the Cluster Monitoring Operator (CMO), which in turn configures the components of the stack.
+In {product-title}, you can configure the stack that monitors workloads for user-defined projects by using the `user-workload-monitoring-config` `ConfigMap` object. Config maps configure the {cmo-first}, which in turn configures the components of the stack.
 endif::openshift-dedicated,openshift-rosa[]
 
 .Prerequisites
diff --git a/modules/monitoring-creating-cluster-monitoring-configmap.adoc b/modules/monitoring-creating-cluster-monitoring-configmap.adoc
@@ -6,7 +6,7 @@
 [id="creating-cluster-monitoring-configmap_{context}"]
 = Creating a cluster monitoring config map
 
-You can configure the core {product-title} monitoring components by creating the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project. The Cluster Monitoring Operator (CMO) then configures the core components of the monitoring stack.
+You can configure the core {product-title} monitoring components by creating the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project. The {cmo-first} then configures the core components of the monitoring stack.
 
 [NOTE]
 ====
diff --git a/modules/monitoring-creating-user-defined-workload-monitoring-configmap.adoc b/modules/monitoring-creating-user-defined-workload-monitoring-configmap.adoc
@@ -6,7 +6,7 @@
 [id="creating-user-defined-workload-monitoring-configmap_{context}"]
 = Creating a user-defined workload monitoring config map
 
-You can configure the user workload monitoring components with the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project. The Cluster Monitoring Operator (CMO) then configures the components that monitor user-defined projects.
+You can configure the user workload monitoring components with the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project. The {cmo-first} then configures the components that monitor user-defined projects.
 
 [NOTE]
 ====
diff --git a/modules/monitoring-default-monitoring-components.adoc b/modules/monitoring-default-monitoring-components.adoc
@@ -14,8 +14,8 @@ By default, the {product-title} {product-version} monitoring stack includes thes
 
 |Component|Description
 
-|Cluster Monitoring Operator
-|The Cluster Monitoring Operator (CMO) is a central component of the monitoring stack. It deploys, manages, and automatically updates Prometheus and Alertmanager instances, Thanos Querier, Telemeter Client, and metrics targets. The CMO is deployed by the Cluster Version Operator (CVO).
+|{cmo-full}
+|The {cmo-first} is a central component of the monitoring stack. It deploys, manages, and automatically updates Prometheus and Alertmanager instances, Thanos Querier, Telemeter Client, and metrics targets. The {cmo-short} is deployed by the Cluster Version Operator (CVO).
 
 |Prometheus Operator
 |The Prometheus Operator (PO) in the `openshift-monitoring` project creates, configures, and manages platform Prometheus instances and Alertmanager instances. It also automatically generates monitoring target configurations based on Kubernetes label queries.
@@ -34,7 +34,7 @@ By default, the {product-title} {product-version} monitoring stack includes thes
 
 |monitoring-plugin
 |The monitoring-plugin dynamic plugin component deploys the monitoring pages in the *Observe* section of the {product-title} web console.
-You can use Cluster Monitoring Operator (CMO) config map settings to manage monitoring-plugin resources for the web console pages.
+You can use {cmo-full} config map settings to manage monitoring-plugin resources for the web console pages.
 
 |openshift-state-metrics agent
 |The openshift-state-metrics exporter (OSM in the preceding diagram) expands upon kube-state-metrics by adding metrics for {product-title}-specific resources.
diff --git a/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc b/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc
@@ -6,8 +6,7 @@
 [id="enabling-query-logging-for-thanos-querier_{context}"]
 = Enabling query logging for Thanos Querier
 
-[role="_abstract"]
-For default platform monitoring in the `openshift-monitoring` project, you can enable the Cluster Monitoring Operator to log all queries run by Thanos Querier.
+For default platform monitoring in the `openshift-monitoring` project, you can enable the {cmo-first} to log all queries run by Thanos Querier.
 
 [IMPORTANT]
 ====
diff --git a/modules/monitoring-maintenance-and-support.adoc b/modules/monitoring-maintenance-and-support.adoc
@@ -5,9 +5,9 @@
 [id="maintenance-and-support_{context}"]
 = Maintenance and support for monitoring
 
-Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the Cluster Monitoring Operator using the options described in the "Config map reference for the Cluster Monitoring Operator". *Do not use other configurations, as they are unsupported.*
+Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the {cmo-first} using the options described in the "Config map reference for the {cmo-short}". *Do not use other configurations, as they are unsupported.*
 
-Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the "Config map reference for the Cluster Monitoring Operator", your changes will disappear because the Cluster Monitoring Operator automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
+Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the "Config map reference for the {cmo-full}", your changes will disappear because the {cmo-short} automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
 
 ifdef::openshift-dedicated,openshift-rosa[]
 [IMPORTANT]
diff --git a/modules/monitoring-setting-audit-log-levels-for-the-prometheus-adapter.adoc b/modules/monitoring-setting-audit-log-levels-for-the-prometheus-adapter.adoc
@@ -105,7 +105,7 @@ $ oc -n openshift-monitoring exec deploy/prometheus-adapter -c prometheus-adapte
 +
 [NOTE]
 ====
-If you enter an unrecognized `profile` value for the Prometheus Adapter in the `ConfigMap` object, no changes are made to the Prometheus Adapter, and an error is logged by the Cluster Monitoring Operator.
+If you enter an unrecognized `profile` value for the Prometheus Adapter in the `ConfigMap` object, no changes are made to the Prometheus Adapter, and an error is logged by the {cmo-full}.
 ====
 
 . Review the audit log for the Prometheus Adapter:
diff --git a/modules/monitoring-understanding-the-cluster-observability-operator.adoc b/modules/monitoring-understanding-the-cluster-observability-operator.adoc
@@ -15,7 +15,7 @@ Each {coo-short} stack also includes an optional Thanos Querier component, which
 
 The `MonitoringStack` CRD used by the {coo-short} offers an opinionated default monitoring configuration for {coo-short}-deployed monitoring components, but you can customize it to suit more complex requirements.
 
-Deploying a {coo-short}-managed monitoring stack can help meet monitoring needs that are difficult or impossible to address by using the core platform monitoring stack deployed by the Cluster Monitoring Operator (CMO).
+Deploying a {coo-short}-managed monitoring stack can help meet monitoring needs that are difficult or impossible to address by using the core platform monitoring stack deployed by the {cmo-first}.
 A monitoring stack deployed using {coo-short} has the following advantages over core platform and user workload monitoring:
 
 Extendability:: Users can add more metrics to a {coo-short}-deployed monitoring stack, which is not possible with core platform monitoring without losing support.
diff --git a/modules/prometheus-database-storage-requirements.adoc b/modules/prometheus-database-storage-requirements.adoc
@@ -48,7 +48,7 @@ Red{nbsp}Hat performed various tests for different scale sizes.
 
 Approximately 20 percent of the expected size was added as overhead to ensure that the storage requirements do not exceed the calculated value.
 
-The above calculation is for the default {product-title} Cluster Monitoring Operator.
+The above calculation is for the default {product-title} {cmo-full}.
 
 [NOTE]
 ====
diff --git a/modules/telco-core-monitoring.adoc b/modules/telco-core-monitoring.adoc
@@ -12,7 +12,7 @@ New in this release::
 
 Description::
 
-The Cluster Monitoring Operator is included by default on all OpenShift clusters and provides monitoring (metrics, dashboards, and alerting) for the platform components and optionally user projects as well.
+The {cmo-first} is included by default on all OpenShift clusters and provides monitoring (metrics, dashboards, and alerting) for the platform components and optionally user projects as well.
 +
 Configuration of the monitoring operator allows for customization, including:
 +
diff --git a/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc b/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
@@ -17,8 +17,8 @@ The {coo-short} deploys the following monitoring components:
 * Thanos Querier (optional)
 * Alertmanager (optional)
 
-The {coo-short} components function independently of the default in-cluster monitoring stack, which is deployed and managed by the Cluster Monitoring Operator (CMO).
-Monitoring stacks deployed by the two Operators do not conflict. You can use a {coo-short} monitoring stack in addition to the default platform monitoring components deployed by the CMO.
+The {coo-short} components function independently of the default in-cluster monitoring stack, which is deployed and managed by the {cmo-first}.
+Monitoring stacks deployed by the two Operators do not conflict. You can use a {coo-short} monitoring stack in addition to the default platform monitoring components deployed by the {cmo-short}.
 
 include::modules/monitoring-understanding-the-cluster-observability-operator.adoc[leveloffset=+1]
 
diff --git a/observability/cluster_observability_operator/cluster-observability-operator-release-notes.adoc b/observability/cluster_observability_operator/cluster-observability-operator-release-notes.adoc
@@ -12,7 +12,7 @@ include::snippets/technology-preview.adoc[leveloffset=+2]
 
 The {coo-first} is an optional {product-title} Operator that enables administrators to create standalone monitoring stacks that are independently configurable for use by different services and users.
 
-The {coo-short} complements the built-in monitoring capabilities of {product-title}. You can deploy it in parallel with the default platform and user workload monitoring stacks managed by the Cluster Monitoring Operator (CMO).
+The {coo-short} complements the built-in monitoring capabilities of {product-title}. You can deploy it in parallel with the default platform and user workload monitoring stacks managed by the {cmo-first}.
 
 These release notes track the development of the {coo-full} in {product-title}.
 
diff --git a/observability/index.adoc b/observability/index.adoc
@@ -28,9 +28,9 @@ endif::openshift-dedicated,openshift-rosa[]
 
 [id="monitoring-overview-index"]
 == Monitoring
-Monitor the in-cluster health and performance of your applications running on {product-title} with metrics and customized alerts for CPU and memory usage, network connectivity, and other resource usage. Monitoring stack components are deployed and managed by the Cluster Monitoring Operator.
+Monitor the in-cluster health and performance of your applications running on {product-title} with metrics and customized alerts for CPU and memory usage, network connectivity, and other resource usage. Monitoring stack components are deployed and managed by the {cmo-full}.
 
-Monitoring stack components are deployed by default in every {product-title} installation and are managed by the Cluster Monitoring Operator (CMO). These components include Prometheus, Alertmanager, Thanos Querier, and others. The CMO also deploys the Telemeter Client, which sends a subset of data from platform Prometheus instances to Red Hat to facilitate Remote Health Monitoring for clusters.
+Monitoring stack components are deployed by default in every {product-title} installation and are managed by the {cmo-first}. These components include Prometheus, Alertmanager, Thanos Querier, and others. The {cmo-short} also deploys the Telemeter Client, which sends a subset of data from platform Prometheus instances to Red Hat to facilitate Remote Health Monitoring for clusters.
 
 For more information, see xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview] and xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring].
 
diff --git a/observability/monitoring/configuring-the-monitoring-stack.adoc b/observability/monitoring/configuring-the-monitoring-stack.adoc
diff --git a/observability/monitoring/managing-alerts.adoc b/observability/monitoring/managing-alerts.adoc
diff --git a/observability/network_observability/network-observability-operator-release-notes.adoc b/observability/network_observability/network-observability-operator-release-notes.adoc
diff --git a/scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc b/scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc
