[enterprise-4.16] OBSDOCS-2226: fix issues identified by the CQA

modules/monitoring-common-terms.adoc

@@ -58,7 +58,7 @@ Metrics Server::
 The Metrics Server monitoring component collects resource metrics and exposes them in the `metrics.k8s.io` Metrics API service for use by other tools and APIs, which frees the core platform Prometheus stack from handling this functionality.
 
 node::
-A worker machine in the {product-title} cluster. A node is either a virtual machine (VM) or a physical machine.
+A compute machine in the {product-title} cluster. A node is either a virtual machine (VM) or a physical machine.
 
 Operator::
 The preferred method of packaging, deploying, and managing a Kubernetes application in an {product-title} cluster. An Operator takes human operational knowledge and encodes it into software that is packaged and shared with customers.
@@ -79,7 +79,7 @@ Prometheus::
 Prometheus is the monitoring system on which the {product-title} monitoring stack is based. Prometheus is a time-series database and a rule evaluation engine for metrics. Prometheus sends alerts to Alertmanager for processing.
 
 Prometheus Operator::
-The Prometheus Operator (PO) in the `openshift-monitoring` project creates, configures, and manages platform Prometheus and Alertmanager instances. It also automatically generates monitoring target configurations based on Kubernetes label queries.
+The Prometheus Operator in the `openshift-monitoring` project creates, configures, and manages platform Prometheus and Alertmanager instances. It also automatically generates monitoring target configurations based on Kubernetes label queries.
 
 Silences::
 A silence can be applied to an alert to prevent notifications from being sent when the conditions for an alert are true. You can mute an alert after the initial notification, while you work on resolving the underlying issue.

modules/monitoring-components-for-monitoring-user-defined-projects.adoc

@@ -10,7 +10,7 @@
 ifndef::openshift-dedicated,openshift-rosa[]
 {product-version}
 endif::openshift-dedicated,openshift-rosa[]
-includes an optional enhancement to the monitoring stack that enables you to monitor services and pods in user-defined projects. This feature includes the following components:
+includes an optional enhancement to the monitoring stack that helps you monitor services and pods in user-defined projects. This feature includes the following components:
 
 .Components for monitoring user-defined projects
 [options="header"]
@@ -19,10 +19,10 @@ includes an optional enhancement to the monitoring stack that enables you to mon
 |Component|Description
 
 |Prometheus Operator
-|The Prometheus Operator (PO) in the `openshift-user-workload-monitoring` project creates, configures, and manages Prometheus and Thanos Ruler instances in the same project.
+|The Prometheus Operator in the `openshift-user-workload-monitoring` project creates, configures, and manages Prometheus and Thanos Ruler instances in the same project.
 
 |Prometheus
-|Prometheus is the monitoring system through which monitoring is provided for user-defined projects. Prometheus sends alerts to Alertmanager for processing.
+|Prometheus is the monitoring system that provides monitoring for user-defined projects. Prometheus sends alerts to Alertmanager for processing.
 
 |Thanos Ruler
 |The Thanos Ruler is a rule evaluation engine for Prometheus that is deployed as a separate process. In {product-title}
@@ -39,8 +39,8 @@ endif::openshift-dedicated,openshift-rosa[]
 ifndef::openshift-dedicated,openshift-rosa[]
 [NOTE]
 ====
-The components in the preceding table are deployed after monitoring is enabled for user-defined projects.
+The components in the preceding table are deployed after you enable monitoring for user-defined projects.
 ====
 endif::openshift-dedicated,openshift-rosa[]
 
-All of these components are monitored by the stack and are automatically updated when {product-title} is updated.
+The monitoring stack monitors all components for user-defined projects. The components are automatically updated when {product-title} is updated.

modules/monitoring-default-monitoring-components.adoc

@@ -6,7 +6,7 @@
 [id="default-monitoring-components_{context}"]
 = Default monitoring components
 
-By default, the {product-title} {product-version} monitoring stack includes these components:
+By default, the {product-title} {product-version} monitoring stack includes the following components:
 
 .Default monitoring stack components
 [options="header"]
@@ -18,10 +18,10 @@ By default, the {product-title} {product-version} monitoring stack includes thes
 |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.
+|The Prometheus Operator 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.
 
 |Prometheus
-|Prometheus is the monitoring system on which the {product-title} monitoring stack is based. Prometheus is a time-series database and a rule evaluation engine for metrics. Prometheus sends alerts to Alertmanager for processing.
+|The {product-title} monitoring stack is based on the Prometheus monitoring system. Prometheus is a time-series database and a rule evaluation engine for metrics. Prometheus sends alerts to Alertmanager for processing.
 
 |Metrics Server
 |The Metrics Server component (MS in the preceding diagram) collects resource metrics and exposes them in the `metrics.k8s.io` Metrics API service for use by other tools and APIs, which frees the core platform Prometheus stack from handling this functionality. Note that with the {product-title} 4.16 release, Metrics Server replaces Prometheus Adapter.
@@ -46,11 +46,11 @@ You can use {cmo-full} config map settings to manage monitoring-plugin resources
 |Thanos Querier aggregates and optionally deduplicates core {product-title} metrics and metrics for user-defined projects under a single, multi-tenant interface.
 
 |Telemeter Client
-|Telemeter Client sends a subsection of the data from platform Prometheus instances to Red Hat to facilitate Remote Health Monitoring for clusters.
+|Telemeter Client sends a subsection of the data from platform Prometheus instances to Red{nbsp}Hat to enable remote health monitoring for clusters.
 
 |===
 
-All of the components in the monitoring stack are monitored by the stack and are automatically updated when {product-title} is updated.
+The monitoring stack monitors all components within the stack. The components are automatically updated when {product-title} is updated.
 
 [NOTE]
 ====

modules/monitoring-understanding-the-monitoring-stack.adoc

@@ -3,33 +3,30 @@
 // * virt/support/virt-openshift-cluster-monitoring.adoc
 // * observability/monitoring/monitoring-overview.adoc
 
-// This module uses a conditionalized title so that the module
-// can be re-used in associated products but the title is not
-// included in the existing OpenShift assembly.
-
 :_mod-docs-content-type: CONCEPT
 [id="understanding-the-monitoring-stack_{context}"]
 = Understanding the monitoring stack
 
 The monitoring stack includes the following components:
 
-* *Default platform monitoring components*.
+Default platform monitoring components::
 ifndef::openshift-dedicated,openshift-rosa[]
-A set of platform monitoring components are installed in the `openshift-monitoring` project by default during an OpenShift Container Platform installation. This provides monitoring for core cluster components including Kubernetes services. The default monitoring stack also enables remote health monitoring for clusters.
+A set of platform monitoring components are installed in the `openshift-monitoring` project by default during an {product-title} installation. This provides monitoring for core cluster components including Kubernetes services. The default monitoring stack also enables remote health monitoring for clusters.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
-A set of platform monitoring components are installed in the `openshift-monitoring` project by default during a {product-title} installation. Red Hat Site Reliability Engineers (SRE) use these components to monitor core cluster components including Kubernetes services. This includes critical metrics, such as CPU and memory, collected from all of the workloads in every namespace.
+A set of platform monitoring components are installed in the `openshift-monitoring` project by default during a {product-title} installation. Red{nbsp}Hat Site Reliability Engineers (SRE) use these components to monitor core cluster components including Kubernetes services. This includes critical metrics, such as CPU and memory, collected from all of the workloads in every namespace.
 endif::openshift-dedicated,openshift-rosa[]
 +
-These components are illustrated in the *Installed by default* section in the following diagram.
+You can see these components in the *Installed by default* section in the following diagram.
 
-* *Components for monitoring user-defined projects*.
+Components for monitoring user-defined projects::
 ifndef::openshift-dedicated,openshift-rosa[]
-After optionally enabling monitoring for user-defined projects, additional monitoring components are installed in the `openshift-user-workload-monitoring` project. This provides monitoring for user-defined projects.
+If you enable monitoring for user-defined projects, additional monitoring components are installed in the `openshift-user-workload-monitoring` project. This provides optional monitoring for user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
 ifdef::openshift-dedicated,openshift-rosa[]
 A set of user-defined project monitoring components are installed in the `openshift-user-workload-monitoring` project by default during a {product-title} installation. You can use these components to monitor services and pods in user-defined projects.
 endif::openshift-dedicated,openshift-rosa[]
-These components are illustrated in the *User* section in the following diagram.
++
+You can see these components in the *User* section in the following diagram.
 
 image:monitoring-architecture.png[{product-title} monitoring architecture]

observability/monitoring/about-ocp-monitoring/monitoring-stack-architecture.adoc

@@ -10,7 +10,7 @@ The {product-title}
 ifdef::openshift-rosa[]
 (ROSA)
 endif::openshift-rosa[]
-monitoring stack is based on the link:https://prometheus.io/[Prometheus] open source project and its wider ecosystem. The monitoring stack includes default monitoring components and components for monitoring user-defined projects.
+monitoring stack is based on the link:https://prometheus.io/[Prometheus] open source project and its wider ecosystem. You can learn about the monitoring stack architecture, which includes default monitoring components and components for monitoring user-defined projects.
 
 // Understanding the monitoring stack
 include::modules/monitoring-understanding-the-monitoring-stack.adoc[leveloffset=+1]
@@ -48,9 +48,3 @@ ifndef::openshift-dedicated,openshift-rosa[]
 * xref:../../../observability/monitoring/configuring-user-workload-monitoring/preparing-to-configure-the-monitoring-stack-uwm.adoc#granting-users-permission-to-monitor-user-defined-projects_preparing-to-configure-the-monitoring-stack-uwm[Granting users permissions for monitoring for user-defined projects]
 * xref:../../../security/tls-security-profiles.adoc#tls-security-profiles[Configuring TLS security profiles]
 endif::openshift-dedicated,openshift-rosa[]
-
-
-
-
-
-