OBSDOCS-1562 improve COO overview, including article content

gabriel-rh · gabriel-rh · commit 8c16cd744654 · 2025-01-14T12:38:01.000Z
diff --git a/modules/coo-advantages.adoc b/modules/coo-advantages.adoc
@@ -0,0 +1,36 @@
+// Module included in the following assemblies:
+// * observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="coo-advantages_{context}"]
+= Key advantages of using {coo-short}
+
+Deploying {coo-short} helps you address monitoring requirements that are hard to achieve using the default monitoring stack. 
+
+[id="coo-advantages-extensibility_{context}"]
+== Extensibility
+
+- You can add more metrics to a {coo-short}-deployed monitoring stack, which is not possible with core platform monitoring without losing support.
+- You can receive cluster-specific metrics from core platform monitoring through federation.
+- {coo-short} supports advanced monitoring scenarios like trend forecasting and anomaly detection.
+
+[id="coo-advantages-multi-tenancy_{context}"]
+== Multi-tenancy support
+
+- You can create monitoring stacks per user namespace.
+- You can deploy multiple stacks per namespace or a single stack for multiple namespaces.
+- {coo-short} enables independent configuration of alerts and receivers for different teams.
+
+[id="coo-advantages-scalability_{context}"]
+== Scalability
+
+- Supports multiple monitoring stacks on a single cluster.
+- Enables monitoring of large clusters through manual sharding.
+- Addresses cases where metrics exceed the capabilities of a single Prometheus instance.
+
+[id="coo-advantages-scalabilityflexibility_{context}"]
+== Flexibility
+
+- Decoupled from {product-title} release cycles.
+- Faster release iterations and rapid response to changing requirements.
+- Independent management of alerting rules.
diff --git a/modules/coo-target-users.adoc b/modules/coo-target-users.adoc
@@ -0,0 +1,23 @@
+// Module included in the following assemblies:
+// * observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="coo-target-users_{context}"]
+= Target users for {coo-short}
+
+{coo-short} is ideal for users who need high customizability, scalability, and long-term data retention, especially in complex, multi-tenant enterprise environments.
+
+[id="coo-target-users-enterprise_{context}"]
+== Enterprise-level users and administrators
+
+Enterprise users require in-depth monitoring capabilities for {product-title} clusters, including advanced performance analysis, long-term data retention, trend forecasting, and historical analysis. These features help enterprises better understand resource usage, prevent performance issues, and optimize resource allocation.
+
+[id="coo-target-users-multi-tenant_{context}"]
+== Operations teams in multi-tenant environments
+
+With multi-tenancy support, {coo-short} allows different teams to configure monitoring views for their projects and applications, making it suitable for teams with flexible monitoring needs.
+
+[id="coo-target-users-devops_{context}"]
+== Development and operations teams
+
+{coo-short} provides fine-grained monitoring and customizable observability views for in-depth troubleshooting, anomaly detection, and performance tuning during development and operations.
diff --git a/modules/coo-versus-default-ocp-monitoring.adoc b/modules/coo-versus-default-ocp-monitoring.adoc
@@ -0,0 +1,36 @@
+// Module included in the following assemblies:
+
+// * observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="coo-versus-default-ocp-monitoring_{context}"]
+= {coo-short} compared to default monitoring stack
+
+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}.
+
+The key differences between {coo-short} and the default in-cluster monitoring stack are shown in the following table:
+
+[cols="1,3,3", options="header"]
+|===
+| Feature      | {coo-short}      | Default monitoring stack
+
+| **Scope and integration**
+| Offers comprehensive monitoring and analytics for enterprise-level needs, covering cluster and workload performance. 
+
+However, it lacks direct integration with {product-title} and typically requires an external Grafana instance for dashboards.
+| Limited to core components within the cluster, for example, API server and etcd, and to OpenShift-specific namespaces. 
+
+There is deep integration into {product-title} including console dashboards and alert management in the console.
+
+| **Configuration and customization**
+| Broader configuration options including data retention periods, storage methods, and collected data types. 
+
+The {coo-short} can delegate ownership of single configurable fields in custom resources to users by using Server-Side Apply (SSA), which enhances customization.
+| Built-in configurations with limited customization options. 
+
+| **Data retention and storage**
+| Long-term data retention, supporting historical analysis and capacity planning
+| Shorter data retention times, focusing on short-term monitoring and real-time detection.
+
+|===
diff --git a/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc b/observability/cluster_observability_operator/cluster-observability-operator-overview.adoc
@@ -9,21 +9,25 @@ toc::[]
 :FeatureName: The Cluster Observability Operator
 include::snippets/technology-preview.adoc[leveloffset=+2]
 
-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-first} is an optional component of the {product-title} designed for creating and managing highly customizable monitoring stacks. It enables cluster administrators to automate configuration and management of monitoring needs extensively, offering a more tailored and detailed view of each namespace compared to the default {product-title} monitoring system.
 
 The {coo-short} deploys the following monitoring components:
 
-* Prometheus
-* Thanos Querier (optional)
-* Alertmanager (optional)
+* **Prometheus** - A highly available Prometheus instance capable of sending metrics to an external endpoint by using remote write.
+* **Thanos Querier** (optional) - Enables querying of Prometheus instances from a central location.
+* **Alertmanager** (optional) - Provides alert configuration capabilities for different services.
+* **UI plugins** (optional) - Enhances the observability capabilities with plugins for monitoring, logging, distributed tracing and troubleshooting.
+* **Korrel8r** (optional) - Provides observability signal correlation, powered by the open source Korrel8r project.
 
-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/coo-versus-default-ocp-monitoring.adoc[leveloffset=+1]
 
-include::modules/monitoring-understanding-the-cluster-observability-operator.adoc[leveloffset=+1]
+include::modules/coo-advantages.adoc[leveloffset=+1]
+
+include::modules/coo-target-users.adoc[leveloffset=+1]
+
+//include::modules/monitoring-understanding-the-cluster-observability-operator.adoc[leveloffset=+1]
 
 [role="_additional-resources"]
 .Additional resources
 
 * link:https://kubernetes.io/docs/reference/using-api/server-side-apply/[Kubernetes documentation for Server-Side Apply (SSA)]
-
