About Red Hat OpenShift Cluster Observability Operator
Introduction to Cluster Observability Operator.
Abstract
Chapter 1. Cluster Observability Operator overview
The Cluster Observability Operator (COO) is an optional component of the OpenShift Container Platform 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 OpenShift Container Platform monitoring system.
The COO deploys the following monitoring components:
- 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.
- Incident detection (optional) - Groups related alerts into incidents, to help you identify the root causes of alert bursts.
1.1. COO compared to default monitoring stack
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 key differences between COO and the default in-cluster monitoring stack are shown in the following table:
| Feature | COO | 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 OpenShift Container Platform 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 OpenShift Container Platform 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 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. | 
1.2. Key advantages of using COO
Deploying COO helps you address monitoring requirements that are hard to achieve using the default monitoring stack.
1.2.1. Extensibility
- You can add more metrics to a COO-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 supports advanced monitoring scenarios like trend forecasting and anomaly detection.
1.2.2. 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 enables independent configuration of alerts and receivers for different teams.
1.2.3. 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.
1.2.4. Flexibility
- Decoupled from OpenShift Container Platform release cycles.
- Faster release iterations and rapid response to changing requirements.
- Independent management of alerting rules.
1.3. Target users for COO
COO is ideal for users who need high customizability, scalability, and long-term data retention, especially in complex, multi-tenant enterprise environments.
1.3.1. Enterprise-level users and administrators
Enterprise users require in-depth monitoring capabilities for OpenShift Container Platform 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.
1.3.2. Operations teams in multi-tenant environments
With multi-tenancy support, COO allows different teams to configure monitoring views for their projects and applications, making it suitable for teams with flexible monitoring needs.
1.3.3. Development and operations teams
COO provides fine-grained monitoring and customizable observability views for in-depth troubleshooting, anomaly detection, and performance tuning during development and operations.
1.4. Using Server-Side Apply to customize Prometheus resources
Server-Side Apply is a feature that enables collaborative management of Kubernetes resources. The control plane tracks how different users and controllers manage fields within a Kubernetes object. It introduces the concept of field managers and tracks ownership of fields. This centralized control provides conflict detection and resolution, and reduces the risk of unintended overwrites.
Compared to Client-Side Apply, it is more declarative, and tracks field management instead of last applied state.
- Server-Side Apply
- Declarative configuration management by updating a resource’s state without needing to delete and recreate it.
- Field management
- Users can specify which fields of a resource they want to update, without affecting the other fields.
- Managed fields
- 
							Kubernetes stores metadata about who manages each field of an object in the managedFieldsfield within metadata.
- Conflicts
- If multiple managers try to modify the same field, a conflict occurs. The applier can choose to overwrite, relinquish control, or share management.
- Merge strategy
- Server-Side Apply merges fields based on the actor who manages them.
Procedure
- Add a - MonitoringStackresource using the following configuration:- Example - MonitoringStackobject- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- A Prometheus resource named - sample-monitoring-stackis generated in the- coo-demonamespace. Retrieve the managed fields of the generated Prometheus resource by running the following command:- oc -n coo-demo get Prometheus.monitoring.rhobs -oyaml --show-managed-fields - $ oc -n coo-demo get Prometheus.monitoring.rhobs -oyaml --show-managed-fields- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Example output - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
						Check the metadata.managedFieldsvalues, and observe that some fields inmetadataandspecare managed by theMonitoringStackresource.
- Modify a field that is not controlled by the - MonitoringStackresource:- Change - spec.enforcedSampleLimit, which is a field not set by the- MonitoringStackresource. Create the file- prom-spec-edited.yaml:- prom-spec-edited.yaml- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- Apply the YAML by running the following command: - oc apply -f ./prom-spec-edited.yaml --server-side - $ oc apply -f ./prom-spec-edited.yaml --server-side- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow Note- You must use the - --server-sideflag.
- Get the changed Prometheus object and note that there is one more section in - managedFieldswhich has- spec.enforcedSampleLimit:- oc get prometheus -n coo-demo - $ oc get prometheus -n coo-demo- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Example output - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- Modify a field that is managed by the - MonitoringStackresource:- Change - spec.LogLevel, which is a field managed by the- MonitoringStackresource, using the following YAML configuration:- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - 1
- spec.logLevelhas been added
 
- Apply the YAML by running the following command: - oc apply -f ./prom-spec-edited.yaml --server-side - $ oc apply -f ./prom-spec-edited.yaml --server-side- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Example output - Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- 
								Notice that the field spec.logLevelcannot be changed using Server-Side Apply, because it is already managed byobservability-operator.
- Use the - --force-conflictsflag to force the change.- oc apply -f ./prom-spec-edited.yaml --server-side --force-conflicts - $ oc apply -f ./prom-spec-edited.yaml --server-side --force-conflicts- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Example output - prometheus.monitoring.rhobs/sample-monitoring-stack serverside-applied - prometheus.monitoring.rhobs/sample-monitoring-stack serverside-applied- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - With - --force-conflictsflag, the field can be forced to change, but since the same field is also managed by the- MonitoringStackresource, the Observability Operator detects the change, and reverts it back to the value set by the- MonitoringStackresource.Note- Some Prometheus fields generated by the - MonitoringStackresource are influenced by the fields in the- MonitoringStack- specstanza, for example,- logLevel. These can be changed by changing the- MonitoringStack- spec.
- To change the - logLevelin the Prometheus object, apply the following YAML to change the- MonitoringStackresource:- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
- To confirm that the change has taken place, query for the log level by running the following command: - oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'- $ oc -n coo-demo get Prometheus.monitoring.rhobs -o=jsonpath='{.items[0].spec.logLevel}'- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow - Example output - info - info- Copy to Clipboard Copied! - Toggle word wrap Toggle overflow 
 
- If a new version of an Operator generates a field that was previously generated and controlled by an actor, the value set by the actor will be overridden. - For example, you are managing a field - enforcedSampleLimitwhich is not generated by the- MonitoringStackresource. If the Observability Operator is upgraded, and the new version of the Operator generates a value for- enforcedSampleLimit, this will overide the value you have previously set.
- 
							The Prometheusobject generated by theMonitoringStackresource may contain some fields which are not explicitly set by the monitoring stack. These fields appear because they have default values.