Merge pull request #69521 from bburt-rh/OBSDOCS-644-add-attributes-for-cluster-observability-operator

bburt-rh · web-flow · commit 8ca9624db2b7 · 2023-12-18T14:01:32.000-05:00
OBSDOCS#644: Add attributes for Cluster Observability Operator
diff --git a/_attributes/common-attributes.adoc b/_attributes/common-attributes.adoc
@@ -249,3 +249,7 @@ endif::[]
 :oci: OCI
 :ocvs-first: Oracle(R) Cloud VMware Solution (OCVS)
 :ocvs: OCVS
+// Cluster Observability Operator
+:coo-first: Cluster Observability Operator (COO)
+:coo-full: Cluster Observability Operator
+:coo-short: COO
diff --git a/modules/monitoring-creating-a-monitoringstack-object-for-cluster-observability-operator.adoc b/modules/monitoring-creating-a-monitoringstack-object-for-cluster-observability-operator.adoc
@@ -4,15 +4,15 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="creating-a-monitoringstack-object-for-cluster-observability-operator_{context}"]
-= Creating a MonitoringStack object for the Cluster Observability Operator
+= Creating a MonitoringStack object for the {coo-full}
 
-To scrape the metrics data exposed by the target `prometheus-coo-example-app` service, create a `MonitoringStack` object that references the `ServiceMonitor` object you created in the "Specifying how a service is monitored for Cluster Observability Operator" section.
+To scrape the metrics data exposed by the target `prometheus-coo-example-app` service, create a `MonitoringStack` object that references the `ServiceMonitor` object you created in the "Specifying how a service is monitored for {coo-full}" section.
 This `MonitoringStack` object can then discover the service and scrape the exposed metrics data from it.
 
 .Prerequisites
 
 * You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with administrative permissions for the namespace.
-* You have installed the Cluster Observability Operator.
+* You have installed the {coo-full}.
 * You have deployed the `prometheus-coo-example-app` sample service in the `ns1-coo` namespace.
 * You have created a `ServiceMonitor` object named `prometheus-coo-example-monitor` in the `ns1-coo` namespace.
 
diff --git a/modules/monitoring-deploying-a-sample-service-for-cluster-observability-operator.adoc b/modules/monitoring-deploying-a-sample-service-for-cluster-observability-operator.adoc
@@ -4,7 +4,7 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="deploying-a-sample-service-for-cluster-observability-operator_{context}"]
-= Deploying a sample service for Cluster Observability Operator
+= Deploying a sample service for {coo-full}
 
 This configuration deploys a sample service named `prometheus-coo-example-app` in the user-defined `ns1-coo` project. 
 The service exposes the custom `version` metric.
diff --git a/modules/monitoring-specifying-how-a-service-is-monitored-by-cluster-observability-operator.adoc b/modules/monitoring-specifying-how-a-service-is-monitored-by-cluster-observability-operator.adoc
@@ -4,9 +4,9 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="specifying-how-a-service-is-monitored-by-cluster-observability-operator_{context}"]
-= Specifying how a service is monitored by Cluster Observability Operator
+= Specifying how a service is monitored by {coo-full}
 
-To use the metrics exposed by the sample service you created in the "Deploying a sample service for Cluster Observability Operator" section, you must configure monitoring components to scrape metrics from the `/metrics` endpoint. 
+To use the metrics exposed by the sample service you created in the "Deploying a sample service for {coo-full}" section, you must configure monitoring components to scrape metrics from the `/metrics` endpoint. 
 
 You can create this configuration by using a `ServiceMonitor` object that specifies how the service is to be monitored, or a `PodMonitor` object that specifies how a pod is to be monitored. 
 The `ServiceMonitor` object requires a `Service` object. The `PodMonitor` object does not, which enables the `MonitoringStack` object to scrape metrics directly from the metrics endpoint exposed by a pod.
@@ -16,7 +16,7 @@ This procedure shows how to create a `ServiceMonitor` object for a sample servic
 .Prerequisites
 
 * You have access to the cluster as a user with the `cluster-admin` cluster role or as a user with administrative permissions for the namespace.
-* You have installed the Cluster Observability Operator.
+* You have installed the {coo-full}.
 * You have deployed the `prometheus-coo-example-app` sample service in the `ns1-coo` namespace.
 +
 [NOTE]
diff --git a/modules/monitoring-understanding-the-cluster-observability-operator.adoc b/modules/monitoring-understanding-the-cluster-observability-operator.adoc
@@ -4,29 +4,29 @@
 
 :_mod-docs-content-type: CONCEPT
 [id="understanding-the-cluster-observability-operator_{context}"]
-= Understanding the Cluster Observability Operator
+= Understanding the {coo-full}
 
-A default monitoring stack created by the Cluster Observability Operator (COO) includes a highly available Prometheus instance capable of sending metrics to an external endpoint by using remote write.
+A default monitoring stack created by the {coo-first} includes a highly available Prometheus instance capable of sending metrics to an external endpoint by using remote write.
 
-Each COO stack also includes an optional Thanos Querier component, which you can use to query a highly available Prometheus instance from a central location, and an optional Alertmanager component, which you can use to set up alert configurations for different services.
+Each {coo-short} stack also includes an optional Thanos Querier component, which you can use to query a highly available Prometheus instance from a central location, and an optional Alertmanager component, which you can use to set up alert configurations for different services.
 
 [id="advantages-of-using-cluster-observability-operator_{context}"]
-== Advantages of using Cluster Observability Operator
+== Advantages of using the {coo-full}
 
-The `MonitoringStack` CRD used by the COO offers an opinionated default monitoring configuration for COO-deployed monitoring components, but you can customize it to suit more complex requirements.
+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-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).
-A monitoring stack deployed using COO has the following advantages over core platform and user workload monitoring:
+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).
+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-deployed monitoring stack, which is not possible with core platform monitoring without losing support.
-In addition, COO-managed stacks can receive certain cluster-specific metrics from core platform monitoring by using federation.
-Multi-tenancy support:: The COO can create a monitoring stack per user namespace.
+Extendability:: Users can add more metrics to a {coo-short}-deployed monitoring stack, which is not possible with core platform monitoring without losing support.
+In addition, {coo-short}-managed stacks can receive certain cluster-specific metrics from core platform monitoring by using federation.
+Multi-tenancy support:: The {coo-short} can create a monitoring stack per user namespace.
 You can also deploy multiple stacks per namespace or a single stack for multiple namespaces.
 For example, cluster administrators, SRE teams, and development teams can all deploy their own monitoring stacks on a single cluster, rather than having to use a single shared stack of monitoring components.
 Users on different teams can then independently configure features such as separate alerts, alert routing, and alert receivers for their applications and services.
-Scalability:: You can create COO-managed monitoring stacks as needed.
+Scalability:: You can create {coo-short}-managed monitoring stacks as needed.
 Multiple monitoring stacks can run on a single cluster, which can facilitate the monitoring of very large clusters by using manual sharding. This ability addresses cases where the number of metrics exceeds the monitoring capabilities of a single Prometheus instance.
-Flexibility:: Deploying the COO with Operator Lifecycle Manager (OLM) decouples COO releases from {product-title} release cycles.
+Flexibility:: Deploying the {coo-short} with Operator Lifecycle Manager (OLM) decouples {coo-short} releases from {product-title} release cycles.
 This method of deployment enables faster release iterations and the ability to respond rapidly to changing requirements and issues.
-Additionally, by deploying a COO-managed monitoring stack, users can manage alerting rules independently of {product-title} release cycles.
-Highly customizable:: The COO can delegate ownership of single configurable fields in custom resources to users by using Server-Side Apply (SSA), which enhances customization.
+Additionally, by deploying a {coo-short}-managed monitoring stack, users can manage alerting rules independently of {product-title} release cycles.
+Highly customizable:: The {coo-short} can delegate ownership of single configurable fields in custom resources to users by using Server-Side Apply (SSA), which enhances customization.
diff --git a/modules/monitoring-uninstalling-cluster-observability-operator-using-the-web-console.adoc b/modules/monitoring-uninstalling-cluster-observability-operator-using-the-web-console.adoc
@@ -4,8 +4,8 @@
 
 :_mod-docs-content-type: PROCEDURE
 [id="uninstalling-the-cluster-observability-operator-using-the-web-console_{context}"]
-= Uninstalling the Cluster Observability Operator using the web console
-If you have installed the Cluster Observability Operator (COO) by using OperatorHub, you can uninstall it in the {product-title} web console.
+= Uninstalling the {coo-full} using the web console
+If you have installed the {coo-first} by using OperatorHub, you can uninstall it in the {product-title} web console.
 
 .Prerequisites
 
@@ -16,6 +16,6 @@ If you have installed the Cluster Observability Operator (COO) by using Operator
 
 . Go to *Operators* -> *Installed Operators*.
 
-. Locate the *Cluster Observability Operator* entry in the list.
+. Locate the *{coo-full}* entry in the list.
 
 . Click {kebab} for this entry and select *Uninstall Operator*.
diff --git a/monitoring/cluster_observability_operator/cluster-observability-operator-overview.adoc b/monitoring/cluster_observability_operator/cluster-observability-operator-overview.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="cluster-observability-operator-overview"]
-= Cluster Observability Operator overview
+= {coo-full} overview
 include::_attributes/common-attributes.adoc[]
 :context: cluster_observability_operator_overview
 
@@ -9,16 +9,16 @@ toc::[]
 :FeatureName: The Cluster Observability Operator
 include::snippets/technology-preview.adoc[leveloffset=+2]
 
-The Cluster Observability Operator (COO) is an optional component of the {product-title}. You can deploy it to create standalone monitoring stacks that are independently configurable for use by different services and users.
+The {coo-first} is an optional component of the {product-title}. You can deploy it to create standalone monitoring stacks that are independently configurable for use by different services and users.
 
-The COO deploys the following monitoring components:
+The {coo-short} deploys the following monitoring components:
 
 * Prometheus
 * Thanos Querier (optional)
 * Alertmanager (optional)
 
-The COO 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 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 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.
 
 include::modules/monitoring-understanding-the-cluster-observability-operator.adoc[leveloffset=+1]
 
diff --git a/monitoring/cluster_observability_operator/cluster-observability-operator-release-notes.adoc b/monitoring/cluster_observability_operator/cluster-observability-operator-release-notes.adoc
@@ -1,23 +1,23 @@
 // Cluster Observability Operator Release Notes
 :_mod-docs-content-type: ASSEMBLY
+include::_attributes/common-attributes.adoc[]
 [id="cluster-observability-operator-release-notes"]
-= Cluster Observability Operator release notes
+= {coo-full} release notes
 :context: cluster-observability-operator-release-notes
-include::_attributes/common-attributes.adoc[]
 
 toc::[]
 
 :FeatureName: The Cluster Observability Operator
 include::snippets/technology-preview.adoc[leveloffset=+2]
 
-The Cluster Observability Operator (COO) 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-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.
 
-COO 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 Cluster Monitoring Operator (CMO). 
 
-These release notes track the development of the Cluster Observability Operator in {product-title}.
+These release notes track the development of the {coo-full} in {product-title}.
 
 [id="cluster-observability-operator-release-notes-0-1"]
-== Cluster Observability Operator 0.1
+== {coo-full} 0.1
 
-This release makes a Technology Preview version of Cluster Observability Operator available on OperatorHub.
+This release makes a Technology Preview version of the {coo-full} available on OperatorHub.
 
diff --git a/monitoring/cluster_observability_operator/configuring-the-cluster-observability-operator-to-monitor-a-service.adoc b/monitoring/cluster_observability_operator/configuring-the-cluster-observability-operator-to-monitor-a-service.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="configuring-the-cluster-observability-operator-to-monitor-a-service"]
-= Configuring the Cluster Observability Operator to monitor a service
+= Configuring the {coo-full} to monitor a service
 include::_attributes/common-attributes.adoc[]
 :context: configuring_the_cluster_observability_operator_to_monitor_a_service
 
@@ -9,12 +9,12 @@ toc::[]
 :FeatureName: The Cluster Observability Operator
 include::snippets/technology-preview.adoc[leveloffset=+2]
 
-You can monitor metrics for a service by configuring monitoring stacks managed by the Cluster Observability Operator (COO).
+You can monitor metrics for a service by configuring monitoring stacks managed by the {coo-first}.
 
 To test monitoring a service, follow these steps:
 
 * Deploy a sample service that defines a service endpoint.
-* Create a `ServiceMonitor` object that specifies how the service is to be monitored by the COO.
+* Create a `ServiceMonitor` object that specifies how the service is to be monitored by the {coo-short}.
 * Create a `MonitoringStack` object to discover the `ServiceMonitor` object.
 
 // Deploy a sample service for Cluster Observability Operator
diff --git a/monitoring/cluster_observability_operator/installing-the-cluster-observability-operator.adoc b/monitoring/cluster_observability_operator/installing-the-cluster-observability-operator.adoc
@@ -1,6 +1,6 @@
 :_mod-docs-content-type: ASSEMBLY
 [id="installing-cluster-observability-operators"]
-= Installing the Cluster Observability Operator
+= Installing the {coo-full}
 include::_attributes/common-attributes.adoc[]
 :context: installing_the_cluster_observability_operator
 
@@ -9,10 +9,10 @@ toc::[]
 :FeatureName: The Cluster Observability Operator
 include::snippets/technology-preview.adoc[leveloffset=+2]
 
-As a cluster administrator, you can install the Cluster Observability Operator (COO) from OperatorHub by using the {product-title} web console or CLI.
+As a cluster administrator, you can install the {coo-first} from OperatorHub by using the {product-title} web console or CLI.
 OperatorHub is a user interface that works in conjunction with Operator Lifecycle Manager (OLM), which installs and manages Operators on a cluster.
 
-To install the COO using OperatorHub, follow the procedure described in xref:../../operators/admin/olm-adding-operators-to-cluster.adoc[Adding Operators to a cluster].
+To install the {coo-short} using OperatorHub, follow the procedure described in xref:../../operators/admin/olm-adding-operators-to-cluster.adoc[Adding Operators to a cluster].
 
 // Uninstalling COO using the OCP web console
 include::modules/monitoring-uninstalling-cluster-observability-operator-using-the-web-console.adoc[leveloffset=+1]
