mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
OBSDOCS-819: Add and implement attributes for the Cluster Monitoring Operator
This commit is contained in:
Eliska Romanova
committed by
openshift-cherrypick-robot
openshift-cherrypick-robot
parent
1ef785467d
commit
ee2afa9ea3
@@ -147,6 +147,10 @@ endif::[]
|
||||
//observability
|
||||
:ObservabilityLongName: Red Hat OpenShift Observability
|
||||
:ObservabilityShortName: Observability
|
||||
// Cluster Monitoring Operator
|
||||
:cmo-first: Cluster Monitoring Operator (CMO)
|
||||
:cmo-full: Cluster Monitoring Operator
|
||||
:cmo-short: CMO
|
||||
//power monitoring
|
||||
:PM-title-c: Power monitoring for Red Hat OpenShift
|
||||
:PM-title: power monitoring for Red Hat OpenShift
|
||||
|
||||
@@ -3,12 +3,12 @@
|
||||
// * operators/operator-reference.adoc
|
||||
|
||||
[id="cluster-monitoring-operator_{context}"]
|
||||
= Cluster Monitoring Operator
|
||||
= {cmo-full}
|
||||
|
||||
[discrete]
|
||||
== Purpose
|
||||
|
||||
The Cluster Monitoring Operator manages and updates the Prometheus-based cluster monitoring stack deployed on top of {product-title}.
|
||||
The {cmo-first} manages and updates the Prometheus-based cluster monitoring stack deployed on top of {product-title}.
|
||||
|
||||
[discrete]
|
||||
== Project
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
= Moving the monitoring solution
|
||||
|
||||
The monitoring stack includes multiple components, including Prometheus, Thanos Querier, and Alertmanager.
|
||||
The Cluster Monitoring Operator manages this stack. To redeploy the monitoring stack to infrastructure nodes, you can create and apply a custom config map.
|
||||
The {cmo-full} manages this stack. To redeploy the monitoring stack to infrastructure nodes, you can create and apply a custom config map.
|
||||
|
||||
.Procedure
|
||||
|
||||
|
||||
@@ -14,8 +14,8 @@ Alertmanager handles alerts received from Prometheus. Alertmanager is also respo
|
||||
Alerting rules::
|
||||
Alerting rules contain a set of conditions that outline a particular state within a cluster. Alerts are triggered when those conditions are true. An alerting rule can be assigned a severity that defines how the alerts are routed.
|
||||
|
||||
Cluster Monitoring Operator::
|
||||
The Cluster Monitoring Operator (CMO) is a central component of the monitoring stack. It deploys and manages Prometheus instances such as, the Thanos Querier, the Telemeter Client, and metrics targets to ensure that they are up to date. The CMO is deployed by the Cluster Version Operator (CVO).
|
||||
{cmo-full}::
|
||||
The {cmo-first} is a central component of the monitoring stack. It deploys and manages Prometheus instances such as, the Thanos Querier, the Telemeter Client, and metrics targets to ensure that they are up to date. The {cmo-short} is deployed by the Cluster Version Operator (CVO).
|
||||
|
||||
Cluster Version Operator::
|
||||
The Cluster Version Operator (CVO) manages the lifecycle of cluster Operators, many of which are installed in {product-title} by default.
|
||||
|
||||
@@ -11,7 +11,7 @@ You can configure different alert receivers for default platform alerts and user
|
||||
* All default platform alerts are sent to a receiver owned by the team in charge of these alerts.
|
||||
* All user-defined alerts are sent to another receiver so that the team can focus only on platform alerts.
|
||||
|
||||
You can achieve this by using the `openshift_io_alert_source="platform"` label that is added by the Cluster Monitoring Operator to all platform alerts:
|
||||
You can achieve this by using the `openshift_io_alert_source="platform"` label that is added by the {cmo-full} to all platform alerts:
|
||||
|
||||
* Use the `openshift_io_alert_source="platform"` matcher to match default platform alerts.
|
||||
* Use the `openshift_io_alert_source!="platform"` or `'openshift_io_alert_source=""'` matcher to match user-defined alerts.
|
||||
|
||||
@@ -8,7 +8,7 @@
|
||||
|
||||
You can configure pod topology spread constraints for
|
||||
ifndef::openshift-dedicated,openshift-rosa[]
|
||||
all the pods deployed by the Cluster Monitoring Operator
|
||||
all the pods deployed by the {cmo-full}
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
ifdef::openshift-dedicated,openshift-rosa[]
|
||||
all the pods for user-defined monitoring
|
||||
|
||||
@@ -7,10 +7,10 @@
|
||||
= Configuring the monitoring stack
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa[]
|
||||
In {product-title} {product-version}, you can configure the monitoring stack using the `cluster-monitoring-config` or `user-workload-monitoring-config` `ConfigMap` objects. Config maps configure the Cluster Monitoring Operator (CMO), which in turn configures the components of the stack.
|
||||
In {product-title} {product-version}, you can configure the monitoring stack using the `cluster-monitoring-config` or `user-workload-monitoring-config` `ConfigMap` objects. Config maps configure the {cmo-first}, which in turn configures the components of the stack.
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
ifdef::openshift-dedicated,openshift-rosa[]
|
||||
In {product-title}, you can configure the stack that monitors workloads for user-defined projects by using the `user-workload-monitoring-config` `ConfigMap` object. Config maps configure the Cluster Monitoring Operator (CMO), which in turn configures the components of the stack.
|
||||
In {product-title}, you can configure the stack that monitors workloads for user-defined projects by using the `user-workload-monitoring-config` `ConfigMap` object. Config maps configure the {cmo-first}, which in turn configures the components of the stack.
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
|
||||
.Prerequisites
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
[id="creating-cluster-monitoring-configmap_{context}"]
|
||||
= Creating a cluster monitoring config map
|
||||
|
||||
You can configure the core {product-title} monitoring components by creating the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project. The Cluster Monitoring Operator (CMO) then configures the core components of the monitoring stack.
|
||||
You can configure the core {product-title} monitoring components by creating the `cluster-monitoring-config` `ConfigMap` object in the `openshift-monitoring` project. The {cmo-first} then configures the core components of the monitoring stack.
|
||||
|
||||
.Prerequisites
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
[id="creating-user-defined-workload-monitoring-configmap_{context}"]
|
||||
= Creating a user-defined workload monitoring config map
|
||||
|
||||
You can configure the user workload monitoring components with the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project. The Cluster Monitoring Operator (CMO) then configures the components that monitor user-defined projects.
|
||||
You can configure the user workload monitoring components with the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project. The {cmo-first} then configures the components that monitor user-defined projects.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -14,8 +14,8 @@ By default, the {product-title} {product-version} monitoring stack includes thes
|
||||
|
||||
|Component|Description
|
||||
|
||||
|Cluster Monitoring Operator
|
||||
|The Cluster Monitoring Operator (CMO) 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 is deployed by the Cluster Version Operator (CVO).
|
||||
|{cmo-full}
|
||||
|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.
|
||||
@@ -34,7 +34,7 @@ By default, the {product-title} {product-version} monitoring stack includes thes
|
||||
|
||||
|monitoring-plugin
|
||||
|The monitoring-plugin dynamic plugin component deploys the monitoring pages in the *Observe* section of the {product-title} web console.
|
||||
You can use Cluster Monitoring Operator (CMO) config map settings to manage monitoring-plugin resources for the web console pages.
|
||||
You can use {cmo-full} config map settings to manage monitoring-plugin resources for the web console pages.
|
||||
|
||||
|openshift-state-metrics agent
|
||||
|The openshift-state-metrics exporter (OSM in the preceding diagram) expands upon kube-state-metrics by adding metrics for {product-title}-specific resources.
|
||||
|
||||
@@ -6,8 +6,7 @@
|
||||
[id="enabling-query-logging-for-thanos-querier_{context}"]
|
||||
= Enabling query logging for Thanos Querier
|
||||
|
||||
[role="_abstract"]
|
||||
For default platform monitoring in the `openshift-monitoring` project, you can enable the Cluster Monitoring Operator to log all queries run by Thanos Querier.
|
||||
For default platform monitoring in the `openshift-monitoring` project, you can enable the {cmo-first} to log all queries run by Thanos Querier.
|
||||
|
||||
[IMPORTANT]
|
||||
====
|
||||
|
||||
@@ -5,9 +5,9 @@
|
||||
[id="maintenance-and-support_{context}"]
|
||||
= Maintenance and support for monitoring
|
||||
|
||||
Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the Cluster Monitoring Operator using the options described in the "Config map reference for the Cluster Monitoring Operator". *Do not use other configurations, as they are unsupported.*
|
||||
Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the {cmo-first} using the options described in the "Config map reference for the {cmo-short}". *Do not use other configurations, as they are unsupported.*
|
||||
|
||||
Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the "Config map reference for the Cluster Monitoring Operator", your changes will disappear because the Cluster Monitoring Operator automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
|
||||
Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the "Config map reference for the {cmo-full}", your changes will disappear because the {cmo-short} automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
|
||||
|
||||
ifdef::openshift-dedicated,openshift-rosa[]
|
||||
[IMPORTANT]
|
||||
|
||||
@@ -100,7 +100,7 @@ $ oc -n openshift-monitoring exec deploy/prometheus-adapter -c prometheus-adapte
|
||||
+
|
||||
[NOTE]
|
||||
====
|
||||
If you enter an unrecognized `profile` value for the Prometheus Adapter in the `ConfigMap` object, no changes are made to the Prometheus Adapter, and an error is logged by the Cluster Monitoring Operator.
|
||||
If you enter an unrecognized `profile` value for the Prometheus Adapter in the `ConfigMap` object, no changes are made to the Prometheus Adapter, and an error is logged by the {cmo-full}.
|
||||
====
|
||||
|
||||
. Review the audit log for the Prometheus Adapter:
|
||||
|
||||
@@ -15,7 +15,7 @@ Each {coo-short} stack also includes an optional Thanos Querier component, which
|
||||
|
||||
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-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).
|
||||
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 {cmo-first}.
|
||||
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-short}-deployed monitoring stack, which is not possible with core platform monitoring without losing support.
|
||||
|
||||
@@ -48,7 +48,7 @@ Red{nbsp}Hat performed various tests for different scale sizes.
|
||||
|
||||
Approximately 20 percent of the expected size was added as overhead to ensure that the storage requirements do not exceed the calculated value.
|
||||
|
||||
The above calculation is for the default {product-title} Cluster Monitoring Operator.
|
||||
The above calculation is for the default {product-title} {cmo-full}.
|
||||
|
||||
[NOTE]
|
||||
====
|
||||
|
||||
@@ -12,7 +12,7 @@ New in this release::
|
||||
|
||||
Description::
|
||||
|
||||
The Cluster Monitoring Operator is included by default on all OpenShift clusters and provides monitoring (metrics, dashboards, and alerting) for the platform components and optionally user projects as well.
|
||||
The {cmo-first} is included by default on all OpenShift clusters and provides monitoring (metrics, dashboards, and alerting) for the platform components and optionally user projects as well.
|
||||
+
|
||||
Configuration of the monitoring operator allows for customization, including:
|
||||
+
|
||||
|
||||
@@ -17,8 +17,8 @@ The {coo-short} deploys the following monitoring components:
|
||||
* Thanos Querier (optional)
|
||||
* Alertmanager (optional)
|
||||
|
||||
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.
|
||||
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/monitoring-understanding-the-cluster-observability-operator.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
@@ -12,7 +12,7 @@ include::snippets/technology-preview.adoc[leveloffset=+2]
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
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 {cmo-first}.
|
||||
|
||||
These release notes track the development of the {coo-full} in {product-title}.
|
||||
|
||||
|
||||
@@ -28,9 +28,9 @@ endif::openshift-dedicated,openshift-rosa[]
|
||||
|
||||
[id="monitoring-overview-index"]
|
||||
== Monitoring
|
||||
Monitor the in-cluster health and performance of your applications running on {product-title} with metrics and customized alerts for CPU and memory usage, network connectivity, and other resource usage. Monitoring stack components are deployed and managed by the Cluster Monitoring Operator.
|
||||
Monitor the in-cluster health and performance of your applications running on {product-title} with metrics and customized alerts for CPU and memory usage, network connectivity, and other resource usage. Monitoring stack components are deployed and managed by the {cmo-full}.
|
||||
|
||||
Monitoring stack components are deployed by default in every {product-title} installation and are managed by the Cluster Monitoring Operator (CMO). These components include Prometheus, Alertmanager, Thanos Querier, and others. The CMO also deploys the Telemeter Client, which sends a subset of data from platform Prometheus instances to Red Hat to facilitate Remote Health Monitoring for clusters.
|
||||
Monitoring stack components are deployed by default in every {product-title} installation and are managed by the {cmo-first}. These components include Prometheus, Alertmanager, Thanos Querier, and others. The {cmo-short} also deploys the Telemeter Client, which sends a subset of data from platform Prometheus instances to Red Hat to facilitate Remote Health Monitoring for clusters.
|
||||
|
||||
For more information, see xref:../observability/monitoring/monitoring-overview.adoc#monitoring-overview[Monitoring overview] and xref:../support/remote_health_monitoring/about-remote-health-monitoring.adoc#about-remote-health-monitoring[About remote health monitoring].
|
||||
|
||||
|
||||
@@ -22,27 +22,27 @@ and demonstrates several common configuration scenarios.
|
||||
[IMPORTANT]
|
||||
====
|
||||
Not all configuration parameters for the monitoring stack are exposed.
|
||||
Only the parameters and fields listed in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the Cluster Monitoring Operator] are supported for configuration.
|
||||
Only the parameters and fields listed in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}] are supported for configuration.
|
||||
====
|
||||
|
||||
ifndef::openshift-dedicated,openshift-rosa[]
|
||||
== Prerequisites
|
||||
|
||||
* The monitoring stack imposes additional resource requirements. Consult the computing resources recommendations in xref:../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#scaling-cluster-monitoring-operator[Scaling the Cluster Monitoring Operator] and verify that you have sufficient resources.
|
||||
* The monitoring stack imposes additional resource requirements. Consult the computing resources recommendations in xref:../../scalability_and_performance/recommended-performance-scale-practices/recommended-infrastructure-practices.adoc#scaling-cluster-monitoring-operator[Scaling the {cmo-full}] and verify that you have sufficient resources.
|
||||
endif::openshift-dedicated,openshift-rosa[]
|
||||
|
||||
// Maintenance and support for monitoring
|
||||
// include::modules/monitoring-maintenance-and-support.adoc[leveloffset=+1]
|
||||
|
||||
// .Additional resources
|
||||
// xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the Cluster Monitoring Operator]
|
||||
// xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}]
|
||||
|
||||
[id="maintenance-and-support_{context}"]
|
||||
== Maintenance and support for monitoring
|
||||
|
||||
Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the Cluster Monitoring Operator using the options described in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the Cluster Monitoring Operator]. *Do not use other configurations, as they are unsupported.*
|
||||
Not all configuration options for the monitoring stack are exposed. The only supported way of configuring {product-title} monitoring is by configuring the {cmo-first} using the options described in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}]. *Do not use other configurations, as they are unsupported.*
|
||||
|
||||
Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the Cluster Monitoring Operator], your changes will disappear because the Cluster Monitoring Operator automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
|
||||
Configuration paradigms might change across Prometheus releases, and such cases can only be handled gracefully if all configuration possibilities are controlled. If you use configurations other than those described in the xref:../monitoring/config-map-reference-for-the-cluster-monitoring-operator.adoc#cluster-monitoring-operator-configuration-reference[Config map reference for the {cmo-full}], your changes will disappear because the {cmo-short} automatically reconciles any differences and resets any unsupported changes back to the originally defined state by default and by design.
|
||||
|
||||
ifdef::openshift-dedicated,openshift-rosa[]
|
||||
[IMPORTANT]
|
||||
@@ -63,7 +63,7 @@ ifndef::openshift-dedicated,openshift-rosa[]
|
||||
[id="preparing-to-configure-the-monitoring-stack"]
|
||||
== Preparing to configure the monitoring stack
|
||||
|
||||
You can configure the monitoring stack by creating and updating monitoring config maps. These config maps configure the Cluster Monitoring Operator (CMO), which in turn configures the components of the monitoring stack.
|
||||
You can configure the monitoring stack by creating and updating monitoring config maps. These config maps configure the {cmo-first}, which in turn configures the components of the monitoring stack.
|
||||
|
||||
include::modules/monitoring-creating-cluster-monitoring-configmap.adoc[leveloffset=+2]
|
||||
include::modules/monitoring-creating-user-defined-workload-monitoring-configmap.adoc[leveloffset=+2]
|
||||
|
||||
@@ -34,7 +34,7 @@ include::modules/monitoring-getting-information-about-alerts-silences-and-alerti
|
||||
|
||||
[role="_additional-resources"]
|
||||
.Additional resources
|
||||
* See the link:https://github.com/openshift/runbooks/tree/master/alerts/cluster-monitoring-operator[Cluster Monitoring Operator runbooks] to help diagnose and resolve issues that trigger specific {product-title} monitoring alerts.
|
||||
* See the link:https://github.com/openshift/runbooks/tree/master/alerts/cluster-monitoring-operator[{cmo-full} runbooks] to help diagnose and resolve issues that trigger specific {product-title} monitoring alerts.
|
||||
|
||||
// Managing silences
|
||||
include::modules/monitoring-managing-silences.adoc[leveloffset=+1]
|
||||
|
||||
@@ -332,7 +332,7 @@ The release of Network Observability Operator 1.3 deprecates the `spec.Loki.auth
|
||||
|
||||
[id="network-observability-operator-1.3.0-bug-fixes"]
|
||||
=== Bug fixes
|
||||
* Previously, when the Operator was installed from the CLI, the `Role` and `RoleBinding` that are necessary for the Cluster Monitoring Operator to read the metrics were not installed as expected. The issue did not occur when the operator was installed from the web console. Now, either way of installing the Operator installs the required `Role` and `RoleBinding`. (link:https://issues.redhat.com/browse/NETOBSERV-1003[*NETOBSERV-1003*])
|
||||
* Previously, when the Operator was installed from the CLI, the `Role` and `RoleBinding` that are necessary for the {cmo-full} to read the metrics were not installed as expected. The issue did not occur when the operator was installed from the web console. Now, either way of installing the Operator installs the required `Role` and `RoleBinding`. (link:https://issues.redhat.com/browse/NETOBSERV-1003[*NETOBSERV-1003*])
|
||||
|
||||
* Since version 1.2, the Network Observability Operator can raise alerts when a problem occurs with the flows collection. Previously, due to a bug, the related configuration to disable alerts, `spec.processor.metrics.disableAlerts` was not working as expected and sometimes ineffectual. Now, this configuration is fixed so that it is possible to disable the alerts. (link:https://issues.redhat.com/browse/NETOBSERV-976[*NETOBSERV-976*])
|
||||
|
||||
@@ -340,7 +340,7 @@ The release of Network Observability Operator 1.3 deprecates the `spec.Loki.auth
|
||||
|
||||
* Previously, a bug prevented users from setting `spec.consolePlugin.portNaming.enable` to `false`. Now, this setting can be set to `false` to disable port-to-service name translation. (link:https://issues.redhat.com/browse/NETOBSERV-971[*NETOBSERV-971*])
|
||||
|
||||
* Previously, the metrics exposed by the console plugin were not collected by the Cluster Monitoring Operator (Prometheus), due to an incorrect configuration. Now the configuration has been fixed so that the console plugin metrics are correctly collected and accessible from the {product-title} web console. (link:https://issues.redhat.com/browse/NETOBSERV-765[*NETOBSERV-765*])
|
||||
* Previously, the metrics exposed by the console plugin were not collected by the {cmo-full} (Prometheus), due to an incorrect configuration. Now the configuration has been fixed so that the console plugin metrics are correctly collected and accessible from the {product-title} web console. (link:https://issues.redhat.com/browse/NETOBSERV-765[*NETOBSERV-765*])
|
||||
|
||||
* Previously, when `processor.metrics.tls` was set to `AUTO` in the `FlowCollector`, the `flowlogs-pipeline servicemonitor` did not adapt the appropriate TLS scheme, and metrics were not visible in the web console. Now the issue is fixed for AUTO mode. (link:https://issues.redhat.com/browse/NETOBSERV-1070[*NETOBSERV-1070*])
|
||||
|
||||
|
||||
@@ -11,9 +11,9 @@ This topic provides recommended performance and scalability practices for infras
|
||||
include::modules/infrastructure-node-sizing.adoc[leveloffset=+1]
|
||||
|
||||
[id="scaling-cluster-monitoring-operator_{context}"]
|
||||
== Scaling the Cluster Monitoring Operator
|
||||
== Scaling the {cmo-full}
|
||||
|
||||
{product-title} exposes metrics that the Cluster Monitoring Operator collects and stores in the Prometheus-based monitoring stack. As an administrator, you can view dashboards for system resources, containers, and components metrics in the {product-title} web console by navigating to *Observe* -> *Dashboards*.
|
||||
{product-title} exposes metrics that the {cmo-first} collects and stores in the Prometheus-based monitoring stack. As an administrator, you can view dashboards for system resources, containers, and components metrics in the {product-title} web console by navigating to *Observe* -> *Dashboards*.
|
||||
|
||||
include::modules/prometheus-database-storage-requirements.adoc[leveloffset=+1]
|
||||
|
||||
|
||||
Reference in New Issue
Block a user