Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
36 changes: 36 additions & 0 deletions modules/coo-advantages.adoc
Original file line number Diff line number Diff line change
@@ -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.
23 changes: 23 additions & 0 deletions modules/coo-target-users.adoc
Original file line number Diff line number Diff line change
@@ -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.
36 changes: 36 additions & 0 deletions modules/coo-versus-default-ocp-monitoring.adoc
Original file line number Diff line number Diff line change
@@ -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.

|===
Original file line number Diff line number Diff line change
Expand Up @@ -9,23 +9,27 @@ 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]

include::modules/coo-server-side-apply.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)]