diff --git a/modules/monitoring-4-20-release-notes.adoc b/modules/monitoring-4-20-release-notes.adoc index 240f75d33f84..106bd2b897a7 100644 --- a/modules/monitoring-4-20-release-notes.adoc +++ b/modules/monitoring-4-20-release-notes.adoc @@ -6,6 +6,7 @@ [id="monitoring-4-20-release-notes_{context}"] = {ocp} {product-version} monitoring release notes +[role="_abstract"] The changes for {ocp} {product-version} monitoring are included in the following errata advisory: * link:[RHSA-year:00000] diff --git a/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc b/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc index fbbe9675df27..f4d2fd456780 100644 --- a/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc +++ b/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc @@ -6,6 +6,7 @@ [id="about-accessing-monitoring-web-service-apis_{context}"] = About accessing monitoring web service APIs +[role="_abstract"] You can directly access web service API endpoints from the command line for the following monitoring stack components: * Prometheus diff --git a/modules/monitoring-about-creating-alerting-rules-for-user-defined-projects.adoc b/modules/monitoring-about-creating-alerting-rules-for-user-defined-projects.adoc index 92fcf41c274d..d03c2033ae10 100644 --- a/modules/monitoring-about-creating-alerting-rules-for-user-defined-projects.adoc +++ b/modules/monitoring-about-creating-alerting-rules-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="about-creating-alerting-rules-for-user-defined-projects_{context}"] = Creating alerting rules for user-defined projects +[role="_abstract"] In {ocp}, you can create alerting rules for user-defined projects. Those alerting rules will trigger alerts based on the values of the chosen metrics. If you create alerting rules for a user-defined project, consider the following key behaviors and important limitations when you define the new rules: diff --git a/modules/monitoring-about-managing-alerts.adoc b/modules/monitoring-about-managing-alerts.adoc index a6290eaf3852..3ad760cb6eb4 100644 --- a/modules/monitoring-about-managing-alerts.adoc +++ b/modules/monitoring-about-managing-alerts.adoc @@ -6,6 +6,7 @@ [id="about-managing-alerts_{context}"] = Managing alerts +[role="_abstract"] In the {ocp}, the Alerting UI enables you to manage alerts, silences, and alerting rules. * *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. diff --git a/modules/monitoring-about-monitoring-dashboards.adoc b/modules/monitoring-about-monitoring-dashboards.adoc index 86d035f19894..af083360df6e 100644 --- a/modules/monitoring-about-monitoring-dashboards.adoc +++ b/modules/monitoring-about-monitoring-dashboards.adoc @@ -6,6 +6,7 @@ [id="about-monitoring-dashboards_{context}"] = About monitoring dashboards +[role="_abstract"] {ocp} provides a set of monitoring dashboards that help you understand the state of cluster components and user-defined workloads. include::snippets/unified-perspective-web-console.adoc[] diff --git a/modules/monitoring-about-specifying-limits-and-requests-for-monitoring-components.adoc b/modules/monitoring-about-specifying-limits-and-requests-for-monitoring-components.adoc index f661fdc6b3da..5ff32afa5402 100644 --- a/modules/monitoring-about-specifying-limits-and-requests-for-monitoring-components.adoc +++ b/modules/monitoring-about-specifying-limits-and-requests-for-monitoring-components.adoc @@ -6,6 +6,7 @@ [id="about-specifying-limits-and-requests-for-monitoring-components_{context}"] = About specifying limits and requests for monitoring components +[role="_abstract"] ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] You can configure resource limits and requests for the following core platform monitoring components: diff --git a/modules/monitoring-accessing-alerting-rules-for-your-project.adoc b/modules/monitoring-accessing-alerting-rules-for-your-project.adoc index b1b3c62a99f0..d86bb6a4081f 100644 --- a/modules/monitoring-accessing-alerting-rules-for-your-project.adoc +++ b/modules/monitoring-accessing-alerting-rules-for-your-project.adoc @@ -6,6 +6,7 @@ [id="accessing-alerting-rules-for-your-project_{context}"] = Accessing alerting rules for user-defined projects +[role="_abstract"] To list alerting rules for a user-defined project, you must have been assigned the `monitoring-rules-view` cluster role for the project. .Prerequisites diff --git a/modules/monitoring-accessing-metrics-outside-cluster.adoc b/modules/monitoring-accessing-metrics-outside-cluster.adoc index 75823aeb4aa3..cc48a059741a 100644 --- a/modules/monitoring-accessing-metrics-outside-cluster.adoc +++ b/modules/monitoring-accessing-metrics-outside-cluster.adoc @@ -6,6 +6,7 @@ [id="accessing-metrics-from-outside-cluster_{context}"] = Accessing metrics from outside the cluster for custom applications +[role="_abstract"] You can query Prometheus metrics from outside the cluster when monitoring your own services with user-defined projects. Access this data from outside the cluster by using the `thanos-querier` route. This access only supports using a bearer token for authentication. diff --git a/modules/monitoring-accessing-the-alerting-ui.adoc b/modules/monitoring-accessing-the-alerting-ui.adoc index fb962c0a155e..7800e4d721de 100644 --- a/modules/monitoring-accessing-the-alerting-ui.adoc +++ b/modules/monitoring-accessing-the-alerting-ui.adoc @@ -4,10 +4,10 @@ // * logging/logging_alerts/log-storage-alerts.adoc :_mod-docs-content-type: PROCEDURE - [id="monitoring-accessing-the-alerting-ui_{context}"] = Accessing the Alerting UI +[role="_abstract"] The Alerting UI is accessible in the {ocp} web console. * In the {ocp} web console, go to *Observe* -> *Alerting*. The three main pages in the Alerting UI in this perspective are the *Alerts*, *Silences*, and *Alerting rules* pages. diff --git a/modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc b/modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc index 939b80561e5c..e788ac3c3679 100644 --- a/modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc +++ b/modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc @@ -6,6 +6,7 @@ [id="accessing-a-monitoring-web-service-api_{context}"] = Accessing a monitoring web service API +[role="_abstract"] The following example shows how to query the service API receivers for the Alertmanager service used in core platform monitoring. You can use a similar method to access the `prometheus-k8s` service for core platform Prometheus and the `thanos-ruler` service for Thanos Ruler. diff --git a/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc b/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc index e9c89d680ee0..961f941d1e5d 100644 --- a/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc +++ b/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc @@ -19,6 +19,7 @@ :component: alertmanager // end::UWM[] +[role="_abstract"] You can add secrets to the Alertmanager configuration by editing the `{configmap-name}` config map in the `{namespace-name}` project. After you add a secret to the config map, the secret is mounted as a volume at `/etc/alertmanager/secrets/` within the `alertmanager` container for the Alertmanager pods. diff --git a/modules/monitoring-adding-cluster-id-labels-to-metrics.adoc b/modules/monitoring-adding-cluster-id-labels-to-metrics.adoc index 5b67d504551e..552572f02ace 100644 --- a/modules/monitoring-adding-cluster-id-labels-to-metrics.adoc +++ b/modules/monitoring-adding-cluster-id-labels-to-metrics.adoc @@ -6,6 +6,7 @@ [id="adding-cluster-id-labels-to-metrics_{context}"] = Adding cluster ID labels to metrics +[role="_abstract"] If you manage multiple {ocp} clusters and use the remote write feature to send metrics data from these clusters to an external storage location, you can add cluster ID labels to identify the metrics data coming from different clusters. You can then query these labels to identify the source cluster for a metric and distinguish that data from similar metrics data sent by other clusters. This way, if you manage many clusters for multiple customers and send metrics data to a single centralized storage system, you can use cluster ID labels to query metrics for a particular cluster or customer. diff --git a/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc b/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc index 10fcf9e2484f..eb679cd8b1c7 100644 --- a/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc +++ b/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc @@ -18,6 +18,7 @@ :component: thanosRuler // end::UWM[] +[role="_abstract"] // tag::CPM[] You can assign tolerations to any of the monitoring stack components to enable moving them to tainted nodes. // end::CPM[] diff --git a/modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc b/modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc index a8696b6ffb8e..eecb745e6088 100644 --- a/modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc +++ b/modules/monitoring-attaching-additional-labels-to-your-time-series-and-alerts.adoc @@ -19,6 +19,7 @@ :component: prometheus // end::UWM[] +[role="_abstract"] You can attach custom labels to all time series and alerts leaving Prometheus by using the external labels feature of Prometheus. .Prerequisites diff --git a/modules/monitoring-choosing-a-metrics-collection-profile.adoc b/modules/monitoring-choosing-a-metrics-collection-profile.adoc index ea5445008285..73ebe637d965 100644 --- a/modules/monitoring-choosing-a-metrics-collection-profile.adoc +++ b/modules/monitoring-choosing-a-metrics-collection-profile.adoc @@ -6,6 +6,7 @@ [id="choosing-a-metrics-collection-profile_{context}"] = Choosing a metrics collection profile +[role="_abstract"] To choose a metrics collection profile for core {ocp} monitoring components, edit the `cluster-monitoring-config` `ConfigMap` object. .Prerequisites diff --git a/modules/monitoring-common-terms.adoc b/modules/monitoring-common-terms.adoc index 53629a8f6ede..9bc385e94301 100644 --- a/modules/monitoring-common-terms.adoc +++ b/modules/monitoring-common-terms.adoc @@ -6,6 +6,7 @@ [id="monitoring-common-terms_{context}"] = Glossary of common terms for {ocp} monitoring +[role="_abstract"] This glossary defines common terms that are used in {ocp} architecture. Alertmanager:: diff --git a/modules/monitoring-components-for-monitoring-user-defined-projects.adoc b/modules/monitoring-components-for-monitoring-user-defined-projects.adoc index b6cf7fe4849d..09db8753a86e 100644 --- a/modules/monitoring-components-for-monitoring-user-defined-projects.adoc +++ b/modules/monitoring-components-for-monitoring-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="components-for-monitoring-user-defined-projects_{context}"] = Components for monitoring user-defined projects +[role="_abstract"] {ocp} ifndef::openshift-dedicated,openshift-rosa[] {product-version} diff --git a/modules/monitoring-configurable-monitoring-components.adoc b/modules/monitoring-configurable-monitoring-components.adoc index 05c44693cbe5..95abbcf9d66b 100644 --- a/modules/monitoring-configurable-monitoring-components.adoc +++ b/modules/monitoring-configurable-monitoring-components.adoc @@ -22,6 +22,7 @@ :thanos: thanosRuler // end::UWM[] +[role="_abstract"] This table shows the monitoring components you can configure and the keys used to specify the components in the `{configmap-name}` config map. // tag::UWM[] diff --git a/modules/monitoring-configuring-a-persistent-volume-claim.adoc b/modules/monitoring-configuring-a-persistent-volume-claim.adoc index de2413543a85..25fba19a3235 100644 --- a/modules/monitoring-configuring-a-persistent-volume-claim.adoc +++ b/modules/monitoring-configuring-a-persistent-volume-claim.adoc @@ -19,6 +19,7 @@ :component: thanosRuler // end::UWM[] +[role="_abstract"] To use a persistent volume (PV) for monitoring components, you must configure a persistent volume claim (PVC). .Prerequisites diff --git a/modules/monitoring-configuring-alert-routing-console.adoc b/modules/monitoring-configuring-alert-routing-console.adoc index dd3c7d5e1a96..9e2a279588ff 100644 --- a/modules/monitoring-configuring-alert-routing-console.adoc +++ b/modules/monitoring-configuring-alert-routing-console.adoc @@ -7,6 +7,7 @@ [id="configuring-alert-routing-console_{context}"] = Configuring alert routing with the {ocp} web console +[role="_abstract"] You can configure alert routing through the {ocp} web console to ensure that you learn about important issues with your cluster. [NOTE] diff --git a/modules/monitoring-configuring-alert-routing-default-platform-alerts.adoc b/modules/monitoring-configuring-alert-routing-default-platform-alerts.adoc index 49714c0d7641..e4692a30a34d 100644 --- a/modules/monitoring-configuring-alert-routing-default-platform-alerts.adoc +++ b/modules/monitoring-configuring-alert-routing-default-platform-alerts.adoc @@ -6,6 +6,7 @@ [id="configuring-alert-routing-default-platform-alerts_{context}"] = Configuring alert routing for default platform alerts +[role="_abstract"] You can configure Alertmanager to send notifications to receive important alerts coming from your cluster. Customize where and how Alertmanager sends notifications about default platform alerts by editing the default configuration in the `alertmanager-main` secret in the `openshift-monitoring` namespace. [NOTE] diff --git a/modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc b/modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc index af8dffb2d88c..db15c20dc1dc 100644 --- a/modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc +++ b/modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="configuring-alert-routing-for-user-defined-projects_{context}"] = Configuring alert routing for user-defined projects +[role="_abstract"] If you are a non-administrator user who has been given the `alert-routing-edit` cluster role, you can create or edit alert routing for user-defined projects. .Prerequisites diff --git a/modules/monitoring-configuring-alert-routing-user-defined-alerts-secret.adoc b/modules/monitoring-configuring-alert-routing-user-defined-alerts-secret.adoc index 987557d8ac93..22ff6cfd523c 100644 --- a/modules/monitoring-configuring-alert-routing-user-defined-alerts-secret.adoc +++ b/modules/monitoring-configuring-alert-routing-user-defined-alerts-secret.adoc @@ -6,6 +6,7 @@ [id="configuring-alert-routing-user-defined-alerts-secret_{context}"] = Configuring alert routing for user-defined projects with the Alertmanager secret +[role="_abstract"] If you have enabled a separate instance of Alertmanager that is dedicated to user-defined alert routing, you can customize where and how the instance sends notifications by editing the `alertmanager-user-workload` secret in the `openshift-user-workload-monitoring` namespace. [NOTE] diff --git a/modules/monitoring-configuring-audit-logs-for-metrics-server.adoc b/modules/monitoring-configuring-audit-logs-for-metrics-server.adoc index 06f441c9f7b3..fdab433bfd61 100644 --- a/modules/monitoring-configuring-audit-logs-for-metrics-server.adoc +++ b/modules/monitoring-configuring-audit-logs-for-metrics-server.adoc @@ -6,6 +6,7 @@ [id="configuring-audit-logs-for-metrics-server_{context}"] = Configuring audit logs for Metrics Server +[role="_abstract"] You can configure audit logs for Metrics Server to help you troubleshoot issues with the server. Audit logs record the sequence of actions in a cluster. It can record user, application, or control plane activities. diff --git a/modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc b/modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc index 041803b5d7f6..fea650d85b23 100644 --- a/modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc +++ b/modules/monitoring-configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts.adoc @@ -6,6 +6,7 @@ [id="configuring-different-alert-receivers-for-default-platform-alerts-and-user-defined-alerts_{context}"] = Configuring different alert receivers for default platform alerts and user-defined alerts +[role="_abstract"] You can configure different alert receivers for default platform alerts and user-defined alerts to ensure the following results: * All default platform alerts are sent to a receiver owned by the team in charge of these alerts. diff --git a/modules/monitoring-configuring-external-alertmanagers.adoc b/modules/monitoring-configuring-external-alertmanagers.adoc index d8d891145ffe..9992c7c2924b 100644 --- a/modules/monitoring-configuring-external-alertmanagers.adoc +++ b/modules/monitoring-configuring-external-alertmanagers.adoc @@ -21,6 +21,7 @@ :component-name: Thanos Ruler // end::UWM[] +[role="_abstract"] The {ocp} monitoring stack includes a local Alertmanager instance that routes alerts from Prometheus. // tag::CPM[] diff --git a/modules/monitoring-configuring-metrics-collection-profiles.adoc b/modules/monitoring-configuring-metrics-collection-profiles.adoc index 220fa5958275..1c61a2232d3b 100644 --- a/modules/monitoring-configuring-metrics-collection-profiles.adoc +++ b/modules/monitoring-configuring-metrics-collection-profiles.adoc @@ -6,6 +6,7 @@ [id="configuring-metrics-collection-profiles_{context}"] = About metrics collection profiles +[role="_abstract"] By default, Prometheus collects metrics exposed by all default metrics targets in {ocp} components. However, you might want Prometheus to collect fewer metrics from a cluster in certain scenarios: diff --git a/modules/monitoring-configuring-persistent-storage.adoc b/modules/monitoring-configuring-persistent-storage.adoc index 3f1fb2b27c9c..3072abf6cd94 100644 --- a/modules/monitoring-configuring-persistent-storage.adoc +++ b/modules/monitoring-configuring-persistent-storage.adoc @@ -6,6 +6,7 @@ [id="configuring-persistent-storage_{context}"] = Configuring persistent storage +[role="_abstract"] Run cluster monitoring with persistent storage to gain the following benefits: * Protect your metrics and alerting data from data loss by storing them in a persistent volume (PV). As a result, they can survive pods being restarted or recreated. diff --git a/modules/monitoring-configuring-pod-topology-spread-constraints.adoc b/modules/monitoring-configuring-pod-topology-spread-constraints.adoc index 44aaceec59a2..cd29b34528d0 100644 --- a/modules/monitoring-configuring-pod-topology-spread-constraints.adoc +++ b/modules/monitoring-configuring-pod-topology-spread-constraints.adoc @@ -23,6 +23,7 @@ :label: thanos-ruler // end::UWM[] +[role="_abstract"] You can configure pod topology spread constraints for // tag::CPM[] all the pods deployed by the {cmo-full} diff --git a/modules/monitoring-configuring-remote-write-storage.adoc b/modules/monitoring-configuring-remote-write-storage.adoc index 6a62cf1fc3fe..1e2f61b755ae 100644 --- a/modules/monitoring-configuring-remote-write-storage.adoc +++ b/modules/monitoring-configuring-remote-write-storage.adoc @@ -18,6 +18,7 @@ :component: prometheus // end::UWM[] +[role="_abstract"] You can configure remote write storage to enable Prometheus to send ingested metrics to remote systems for long-term storage. Doing so has no impact on how or for how long Prometheus stores metrics. .Prerequisites diff --git a/modules/monitoring-configuring-secrets-for-alertmanager.adoc b/modules/monitoring-configuring-secrets-for-alertmanager.adoc index 1a1e03322300..bad6e0ce6153 100644 --- a/modules/monitoring-configuring-secrets-for-alertmanager.adoc +++ b/modules/monitoring-configuring-secrets-for-alertmanager.adoc @@ -6,6 +6,7 @@ [id="monitoring-configuring-secrets-for-alertmanager_{context}"] = Configuring secrets for Alertmanager +[role="_abstract"] The {ocp} monitoring stack includes Alertmanager, which routes alerts from Prometheus to endpoint receivers. If you need to authenticate with a receiver so that Alertmanager can send alerts to it, you can configure Alertmanager to use a secret that contains authentication credentials for the receiver. diff --git a/modules/monitoring-controlling-the-impact-of-unbound-attributes-in-user-defined-projects.adoc b/modules/monitoring-controlling-the-impact-of-unbound-attributes-in-user-defined-projects.adoc index ede5fb096fd6..912ed2d62721 100644 --- a/modules/monitoring-controlling-the-impact-of-unbound-attributes-in-user-defined-projects.adoc +++ b/modules/monitoring-controlling-the-impact-of-unbound-attributes-in-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="controlling-the-impact-of-unbound-attributes-in-user-defined-projects_{context}"] = Controlling the impact of unbound metrics attributes in user-defined projects +[role="_abstract"] Developers can create labels to define attributes for metrics in the form of key-value pairs. The number of potential key-value pairs corresponds to the number of possible values for an attribute. An attribute that has an unlimited number of potential values is called an unbound attribute. For example, a `customer_id` attribute is unbound because it has an infinite number of possible values. Every assigned key-value pair has a unique time series. The use of many unbound attributes in labels can result in an exponential increase in the number of time series created. This can impact Prometheus performance and can consume a lot of disk space. diff --git a/modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc b/modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc index 653f474a8214..6b585f50b787 100644 --- a/modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc +++ b/modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="creating-alerting-rules-for-user-defined-projects_{context}"] = Creating alerting rules for user-defined projects +[role="_abstract"] You can create alerting rules for user-defined projects. Those alerting rules will trigger alerts based on the values of the chosen metrics. [NOTE] diff --git a/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc b/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc index 361651ebb09b..abc4ab88fe96 100644 --- a/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc +++ b/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc @@ -18,6 +18,7 @@ :component: prometheus // end::UWM[] +[role="_abstract"] You can create cluster ID labels for metrics by adding the `write_relabel` settings for remote write storage in the `{configmap-name}` config map in the `{namespace-name}` namespace. By adding a cluster ID label, you can uniquely identify metrics and track them consistently across clusters and workloads. ifndef::openshift-dedicated,openshift-rosa[] diff --git a/modules/monitoring-creating-cluster-monitoring-configmap.adoc b/modules/monitoring-creating-cluster-monitoring-configmap.adoc index b45c699f9870..6b04c4ab3d92 100644 --- a/modules/monitoring-creating-cluster-monitoring-configmap.adoc +++ b/modules/monitoring-creating-cluster-monitoring-configmap.adoc @@ -6,6 +6,7 @@ [id="creating-cluster-monitoring-configmap_{context}"] = Creating a cluster monitoring config map +[role="_abstract"] You can configure the core {ocp} monitoring components by creating and updating the `cluster-monitoring-config` config map in the `openshift-monitoring` project. The {cmo-first} then configures the core components of the monitoring stack. .Prerequisites diff --git a/modules/monitoring-creating-cross-project-alerting-rules-for-user-defined-projects.adoc b/modules/monitoring-creating-cross-project-alerting-rules-for-user-defined-projects.adoc index f377d04355ed..bbadbbf10578 100644 --- a/modules/monitoring-creating-cross-project-alerting-rules-for-user-defined-projects.adoc +++ b/modules/monitoring-creating-cross-project-alerting-rules-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="creating-cross-project-alerting-rules-for-user-defined-projects_{context}"] = Creating cross-project alerting rules for user-defined projects +[role="_abstract"] You can create alerting rules that are not bound to their project of origin by configuring a project in the `user-workload-monitoring-config` config map. The `PrometheusRule` objects created in these projects are then applicable to all projects. Therefore, you can have generic alerting rules that apply to multiple user-defined projects instead of having individual `PrometheusRule` objects in each user project. You can filter which projects are included or excluded from the alerting rule by using PromQL queries in the `PrometheusRule` object. diff --git a/modules/monitoring-creating-new-alerting-rules.adoc b/modules/monitoring-creating-new-alerting-rules.adoc index 79099a12dc74..e06ffa612b87 100644 --- a/modules/monitoring-creating-new-alerting-rules.adoc +++ b/modules/monitoring-creating-new-alerting-rules.adoc @@ -6,6 +6,7 @@ [id="creating-new-alerting-rules_{context}"] = Creating new alerting rules +[role="_abstract"] As a cluster administrator, you can create new alerting rules based on platform metrics. These alerting rules trigger alerts based on the values of chosen metrics. diff --git a/modules/monitoring-creating-scrape-sample-alerts.adoc b/modules/monitoring-creating-scrape-sample-alerts.adoc index 3863df97760e..cc2570c141c4 100644 --- a/modules/monitoring-creating-scrape-sample-alerts.adoc +++ b/modules/monitoring-creating-scrape-sample-alerts.adoc @@ -6,6 +6,7 @@ [id="creating-scrape-sample-alerts_{context}"] = Creating scrape sample alerts +[role="_abstract"] You can create alerts that notify you when: * The target cannot be scraped or is not available for the specified `for` duration diff --git a/modules/monitoring-default-monitoring-components.adoc b/modules/monitoring-default-monitoring-components.adoc index 02e268d4fa6b..761c2cc2b8a4 100644 --- a/modules/monitoring-default-monitoring-components.adoc +++ b/modules/monitoring-default-monitoring-components.adoc @@ -6,6 +6,7 @@ [id="default-monitoring-components_{context}"] = Default monitoring components +[role="_abstract"] By default, the {ocp} {product-version} monitoring stack includes the following components: .Default monitoring stack components diff --git a/modules/monitoring-default-monitoring-targets.adoc b/modules/monitoring-default-monitoring-targets.adoc index 6850b078a0e0..b2f1ed271c5c 100644 --- a/modules/monitoring-default-monitoring-targets.adoc +++ b/modules/monitoring-default-monitoring-targets.adoc @@ -6,6 +6,7 @@ [id="default-monitoring-targets_{context}"] = Default monitoring targets +[role="_abstract"] ifndef::openshift-dedicated,openshift-rosa[] In addition to the components of the stack itself, the default monitoring stack monitors additional platform components. diff --git a/modules/monitoring-deploying-a-sample-service.adoc b/modules/monitoring-deploying-a-sample-service.adoc index b0995ab3415a..c0137a6e498c 100644 --- a/modules/monitoring-deploying-a-sample-service.adoc +++ b/modules/monitoring-deploying-a-sample-service.adoc @@ -6,6 +6,7 @@ [id="deploying-a-sample-service_{context}"] = Deploying a sample service +[role="_abstract"] To test monitoring of a service in a user-defined project, you can deploy a sample service. .Prerequisites diff --git a/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc b/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc index 2d11c1a297f7..7a56c9b39785 100644 --- a/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc +++ b/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc @@ -7,6 +7,7 @@ [id="determining-why-prometheus-is-consuming-disk-space_{context}"] = Determining why Prometheus is consuming a lot of disk space +[role="_abstract"] Developers can create labels to define attributes for metrics in the form of key-value pairs. The number of potential key-value pairs corresponds to the number of possible values for an attribute. An attribute that has an unlimited number of potential values is called an unbound attribute. For example, a `customer_id` attribute is unbound because it has an infinite number of possible values. Every assigned key-value pair has a unique time series. The use of many unbound attributes in labels can result in an exponential increase in the number of time series created. This can impact Prometheus performance and can consume a lot of disk space. diff --git a/modules/monitoring-disabling-cross-project-alerting-rules-for-user-defined-projects.adoc b/modules/monitoring-disabling-cross-project-alerting-rules-for-user-defined-projects.adoc index cb1363eaebf4..f55d083f7e6b 100644 --- a/modules/monitoring-disabling-cross-project-alerting-rules-for-user-defined-projects.adoc +++ b/modules/monitoring-disabling-cross-project-alerting-rules-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="disabling-cross-project-alerting-rules-for-user-defined-projects_{context}"] = Disabling cross-project alerting rules for user-defined projects +[role="_abstract"] Creating cross-project alerting rules for user-defined projects is enabled by default. Cluster administrators can disable the capability in the `cluster-monitoring-config` config map for the following reasons: * To prevent user-defined monitoring from overloading the cluster monitoring stack. diff --git a/modules/monitoring-disabling-monitoring-for-user-defined-projects.adoc b/modules/monitoring-disabling-monitoring-for-user-defined-projects.adoc index f99536fd0661..5a62a1448f1a 100644 --- a/modules/monitoring-disabling-monitoring-for-user-defined-projects.adoc +++ b/modules/monitoring-disabling-monitoring-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="disabling-monitoring-for-user-defined-projects_{context}"] = Disabling monitoring for user-defined projects +[role="_abstract"] After enabling monitoring for user-defined projects, you can disable it again by setting `enableUserWorkload: false` in the cluster monitoring `ConfigMap` object. [NOTE] diff --git a/modules/monitoring-disabling-the-local-alertmanager.adoc b/modules/monitoring-disabling-the-local-alertmanager.adoc index 7a574392c524..4b696a0ebc74 100644 --- a/modules/monitoring-disabling-the-local-alertmanager.adoc +++ b/modules/monitoring-disabling-the-local-alertmanager.adoc @@ -6,6 +6,7 @@ [id="monitoring-disabling-the-local-alertmanager_{context}"] = Disabling the local Alertmanager +[role="_abstract"] A local Alertmanager that routes alerts from Prometheus instances is enabled by default in the `openshift-monitoring` project of the {ocp} monitoring stack. If you do not need the local Alertmanager, you can disable it by configuring the `cluster-monitoring-config` config map in the `openshift-monitoring` project. diff --git a/modules/monitoring-editing-silences.adoc b/modules/monitoring-editing-silences.adoc index 776cee400015..ff16eb8af9af 100644 --- a/modules/monitoring-editing-silences.adoc +++ b/modules/monitoring-editing-silences.adoc @@ -3,10 +3,10 @@ // * observability/monitoring/managing-alerts.adoc :_mod-docs-content-type: PROCEDURE - [id="editing-silences_{context}"] = Editing silences +[role="_abstract"] You can edit a silence, which expires the existing silence and creates a new one with the changed configuration. .Prerequisites diff --git a/modules/monitoring-enabling-a-separate-alertmanager-instance-for-user-defined-alert-routing.adoc b/modules/monitoring-enabling-a-separate-alertmanager-instance-for-user-defined-alert-routing.adoc index 37fe5da00290..1e3a4c218a5f 100644 --- a/modules/monitoring-enabling-a-separate-alertmanager-instance-for-user-defined-alert-routing.adoc +++ b/modules/monitoring-enabling-a-separate-alertmanager-instance-for-user-defined-alert-routing.adoc @@ -6,6 +6,7 @@ [id="enabling-a-separate-alertmanager-instance-for-user-defined-alert-routing_{context}"] = Enabling a separate Alertmanager instance for user-defined alert routing +[role="_abstract"] ifndef::openshift-rosa,openshift-dedicated[] In some clusters, you might want to deploy a dedicated Alertmanager instance for user-defined projects, which can help reduce the load on the default platform Alertmanager instance and can better separate user-defined alerts from default platform alerts. endif::[] diff --git a/modules/monitoring-enabling-alert-routing-for-user-defined-projects.adoc b/modules/monitoring-enabling-alert-routing-for-user-defined-projects.adoc index 6d1da2fd0a8f..94dbb484657b 100644 --- a/modules/monitoring-enabling-alert-routing-for-user-defined-projects.adoc +++ b/modules/monitoring-enabling-alert-routing-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="enabling-alert-routing-for-user-defined-projects_{context}"] = Enabling alert routing for user-defined projects +[role="_abstract"] In {ocp}, an administrator can enable alert routing for user-defined projects. This process consists of the following steps: diff --git a/modules/monitoring-enabling-monitoring-for-user-defined-projects.adoc b/modules/monitoring-enabling-monitoring-for-user-defined-projects.adoc index 90fc5c27c046..6562ac6f88a1 100644 --- a/modules/monitoring-enabling-monitoring-for-user-defined-projects.adoc +++ b/modules/monitoring-enabling-monitoring-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="enabling-monitoring-for-user-defined-projects_{context}"] = Enabling monitoring for user-defined projects +[role="_abstract"] Cluster administrators can enable monitoring for user-defined projects by setting the `enableUserWorkload: true` field in the cluster monitoring `ConfigMap` object. [IMPORTANT] diff --git a/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc b/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc index 1de449ff1312..17c3e59c47af 100644 --- a/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc +++ b/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc @@ -6,6 +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 {cmo-first} to log all queries run by Thanos Querier. [IMPORTANT] diff --git a/modules/monitoring-enabling-the-platform-alertmanager-instance-for-user-defined-alert-routing.adoc b/modules/monitoring-enabling-the-platform-alertmanager-instance-for-user-defined-alert-routing.adoc index ac432a38eada..15f5f6377e4c 100644 --- a/modules/monitoring-enabling-the-platform-alertmanager-instance-for-user-defined-alert-routing.adoc +++ b/modules/monitoring-enabling-the-platform-alertmanager-instance-for-user-defined-alert-routing.adoc @@ -6,6 +6,7 @@ [id="enabling-the-platform-alertmanager-instance-for-user-defined-alert-routing_{context}"] = Enabling the platform Alertmanager instance for user-defined alert routing +[role="_abstract"] You can allow users to create user-defined alert routing configurations that use the main platform instance of Alertmanager. .Prerequisites diff --git a/modules/monitoring-example-remote-write-authentication-settings.adoc b/modules/monitoring-example-remote-write-authentication-settings.adoc index 0bed4c07fef9..4307662d6de8 100644 --- a/modules/monitoring-example-remote-write-authentication-settings.adoc +++ b/modules/monitoring-example-remote-write-authentication-settings.adoc @@ -18,6 +18,7 @@ :component: prometheus // end::UWM[] +[role="_abstract"] The following samples show different authentication settings you can use to connect to a remote write endpoint. Each sample also shows how to configure a corresponding `Secret` object that contains authentication credentials and other relevant settings. Each sample configures authentication for use with // tag::CPM[] default platform monitoring diff --git a/modules/monitoring-example-remote-write-queue-configuration.adoc b/modules/monitoring-example-remote-write-queue-configuration.adoc index d616eaf6ab6f..0514e5de79af 100644 --- a/modules/monitoring-example-remote-write-queue-configuration.adoc +++ b/modules/monitoring-example-remote-write-queue-configuration.adoc @@ -18,6 +18,7 @@ :component: prometheus // end::UWM[] +[role="_abstract"] You can use the `queueConfig` object for remote write to tune the remote write queue parameters. The following example shows the queue parameters with their default values for // tag::CPM[] default platform monitoring diff --git a/modules/monitoring-example-service-endpoint-authentication-settings.adoc b/modules/monitoring-example-service-endpoint-authentication-settings.adoc index 606bd7653e8e..125eab3bb351 100644 --- a/modules/monitoring-example-service-endpoint-authentication-settings.adoc +++ b/modules/monitoring-example-service-endpoint-authentication-settings.adoc @@ -6,6 +6,7 @@ [id="example-service-endpoint-authentication-settings_{context}"] = Example service endpoint authentication settings +[role="_abstract"] You can configure authentication to safely scrape metrics from service endpoints in a user-defined project by using `ServiceMonitor` and `PodMonitor` custom resource definitions (CRDs). The following samples show different authentication settings for a `ServiceMonitor` resource. diff --git a/modules/monitoring-excluding-a-user-defined-project-from-monitoring.adoc b/modules/monitoring-excluding-a-user-defined-project-from-monitoring.adoc index 7a8e821cec3e..23ca851746dd 100644 --- a/modules/monitoring-excluding-a-user-defined-project-from-monitoring.adoc +++ b/modules/monitoring-excluding-a-user-defined-project-from-monitoring.adoc @@ -7,6 +7,7 @@ [id="excluding-a-user-defined-project-from-monitoring_{context}"] = Excluding a user-defined project from monitoring +[role="_abstract"] Individual user-defined projects can be excluded from user workload monitoring. To do so, add the `openshift.io/user-monitoring` label to the project's namespace with a value of `false`. .Procedure diff --git a/modules/monitoring-expiring-silences.adoc b/modules/monitoring-expiring-silences.adoc index 67f6dad4e7c5..1df8b19ad5f9 100644 --- a/modules/monitoring-expiring-silences.adoc +++ b/modules/monitoring-expiring-silences.adoc @@ -3,10 +3,10 @@ // * observability/monitoring/managing-alerts.adoc :_mod-docs-content-type: PROCEDURE - [id="expiring-silences_{context}"] = Expiring silences +[role="_abstract"] You can expire a single silence or multiple silences. Expiring a silence deactivates it permanently. [NOTE] diff --git a/modules/monitoring-getting-detailed-information-about-a-target.adoc b/modules/monitoring-getting-detailed-information-about-a-target.adoc index 7506686ee0b7..0f36dd295aee 100644 --- a/modules/monitoring-getting-detailed-information-about-a-target.adoc +++ b/modules/monitoring-getting-detailed-information-about-a-target.adoc @@ -6,6 +6,7 @@ [id="getting-detailed-information-about-a-target_{context}"] = Getting detailed information about a metrics target +[role="_abstract"] You can use the {ocp} web console to view, search, and filter the endpoints that are currently targeted for scraping, which helps you to identify and troubleshoot problems. For example, you can view the current status of targeted endpoints to see when {ocp} monitoring is not able to scrape metrics from a targeted component. ifndef::openshift-dedicated,openshift-rosa[] diff --git a/modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc b/modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc index 3c31367d0e83..3c1bae7b3fe1 100644 --- a/modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc +++ b/modules/monitoring-getting-information-about-alerts-silences-and-alerting-rules.adoc @@ -3,10 +3,10 @@ // * observability/monitoring/managing-alerts.adoc :_mod-docs-content-type: PROCEDURE - [id="getting-information-about-alerts-silences-and-alerting-rules_{context}"] = Getting information about alerts, silences, and alerting rules +[role="_abstract"] The Alerting UI provides detailed information about alerts and their governing alerting rules and silences. .Prerequisites diff --git a/modules/monitoring-granting-user-permissions-using-the-cli.adoc b/modules/monitoring-granting-user-permissions-using-the-cli.adoc index 252daab6796f..a17458df0db5 100644 --- a/modules/monitoring-granting-user-permissions-using-the-cli.adoc +++ b/modules/monitoring-granting-user-permissions-using-the-cli.adoc @@ -6,6 +6,7 @@ [id="granting-user-permissions-using-the-cli_{context}"] = Granting user permissions by using the CLI +[role="_abstract"] You can grant users permissions // tag::CPM[] for the `openshift-monitoring` project or diff --git a/modules/monitoring-granting-user-permissions-using-the-web-console.adoc b/modules/monitoring-granting-user-permissions-using-the-web-console.adoc index d235df7e5ba7..10e0c9356489 100644 --- a/modules/monitoring-granting-user-permissions-using-the-web-console.adoc +++ b/modules/monitoring-granting-user-permissions-using-the-web-console.adoc @@ -6,6 +6,7 @@ [id="granting-user-permissions-using-the-web-console_{context}"] = Granting user permissions by using the web console +[role="_abstract"] You can grant users permissions for the `openshift-monitoring` project or their own projects, by using the {ocp} web console. .Prerequisites diff --git a/modules/monitoring-granting-users-permission-to-configure-alert-routing-for-user-defined-projects.adoc b/modules/monitoring-granting-users-permission-to-configure-alert-routing-for-user-defined-projects.adoc index 4c38f6e90db1..48a1ed3f790e 100644 --- a/modules/monitoring-granting-users-permission-to-configure-alert-routing-for-user-defined-projects.adoc +++ b/modules/monitoring-granting-users-permission-to-configure-alert-routing-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="granting-users-permission-to-configure-alert-routing-for-user-defined-projects_{context}"] = Granting users permission to configure alert routing for user-defined projects +[role="_abstract"] You can grant users permission to configure alert routing for user-defined projects. .Prerequisites diff --git a/modules/monitoring-granting-users-permission-to-configure-monitoring-for-user-defined-projects.adoc b/modules/monitoring-granting-users-permission-to-configure-monitoring-for-user-defined-projects.adoc index 24961360f052..99baa348a252 100644 --- a/modules/monitoring-granting-users-permission-to-configure-monitoring-for-user-defined-projects.adoc +++ b/modules/monitoring-granting-users-permission-to-configure-monitoring-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="granting-users-permission-to-configure-monitoring-for-user-defined-projects_{context}"] = Granting users permission to configure monitoring for user-defined projects +[role="_abstract"] As a cluster administrator, you can assign the `user-workload-monitoring-config-edit` role to a user. This grants permission to configure and manage monitoring for user-defined projects without giving them permission to configure and manage core {ocp} monitoring components. .Prerequisites diff --git a/modules/monitoring-granting-users-permission-to-monitor-user-defined-projects.adoc b/modules/monitoring-granting-users-permission-to-monitor-user-defined-projects.adoc index ed822c51e44f..202be02423af 100644 --- a/modules/monitoring-granting-users-permission-to-monitor-user-defined-projects.adoc +++ b/modules/monitoring-granting-users-permission-to-monitor-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="granting-users-permission-to-monitor-user-defined-projects_{context}"] = Granting users permissions for monitoring for user-defined projects +[role="_abstract"] As a cluster administrator, you can monitor all core {ocp} and user-defined projects. You can also grant developers and other users different permissions: diff --git a/modules/monitoring-granting-users-permissions-for-core-platform-monitoring.adoc b/modules/monitoring-granting-users-permissions-for-core-platform-monitoring.adoc index 5bf60429b863..ca304d3a9b6a 100644 --- a/modules/monitoring-granting-users-permissions-for-core-platform-monitoring.adoc +++ b/modules/monitoring-granting-users-permissions-for-core-platform-monitoring.adoc @@ -6,6 +6,7 @@ [id="granting-users-permissions-for-core-platform-monitoring_{context}"] = Granting users permissions for core platform monitoring +[role="_abstract"] As a cluster administrator, you can monitor all core {ocp} and user-defined projects. You can also grant developers and other users different permissions for core platform monitoring. You can grant the permissions by assigning one of the following monitoring roles or cluster roles: diff --git a/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc b/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc index 80096b4db4d5..541fe7edfda4 100644 --- a/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc +++ b/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc @@ -7,6 +7,7 @@ [id="investigating-why-user-defined-metrics-are-unavailable_{context}"] = Investigating why user-defined project metrics are unavailable +[role="_abstract"] `ServiceMonitor` resources enable you to determine how to use the metrics exposed by a service in user-defined projects. Follow the steps outlined in this procedure if you have created a `ServiceMonitor` resource but cannot see any corresponding metrics in the Metrics UI. .Prerequisites diff --git a/modules/monitoring-listing-alerting-rules-for-all-projects-in-a-single-view.adoc b/modules/monitoring-listing-alerting-rules-for-all-projects-in-a-single-view.adoc index 4671e5fa96ed..889e7df4a931 100644 --- a/modules/monitoring-listing-alerting-rules-for-all-projects-in-a-single-view.adoc +++ b/modules/monitoring-listing-alerting-rules-for-all-projects-in-a-single-view.adoc @@ -6,6 +6,7 @@ [id="listing-alerting-rules-for-all-projects-in-a-single-view_{context}"] = Listing alerting rules for all projects in a single view +[role="_abstract"] ifndef::openshift-dedicated,openshift-rosa[] As a cluster administrator, endif::openshift-dedicated,openshift-rosa[] diff --git a/modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc b/modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc index abe879f6cc62..ad2c9afaf9e7 100644 --- a/modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc +++ b/modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc @@ -7,6 +7,7 @@ [id="managing-alerting-rules-for-user-defined-projects_{context}"] = Managing alerting rules for user-defined projects +[role="_abstract"] In {ocp}, you can view, edit, and remove alerting rules in user-defined projects. ifdef::openshift-rosa,openshift-dedicated[] diff --git a/modules/monitoring-managing-core-platform-alerting-rules.adoc b/modules/monitoring-managing-core-platform-alerting-rules.adoc index c64098c7257b..d004b71175dc 100644 --- a/modules/monitoring-managing-core-platform-alerting-rules.adoc +++ b/modules/monitoring-managing-core-platform-alerting-rules.adoc @@ -6,6 +6,7 @@ [id="managing-core-platform-alerting-rules_{context}"] = Managing alerting rules for core platform monitoring +[role="_abstract"] The {ocp} monitoring includes a large set of default alerting rules for platform metrics. As a cluster administrator, you can customize this set of rules in two ways: diff --git a/modules/monitoring-managing-silences.adoc b/modules/monitoring-managing-silences.adoc index 3a72ff5093a1..5143d90e5698 100644 --- a/modules/monitoring-managing-silences.adoc +++ b/modules/monitoring-managing-silences.adoc @@ -6,6 +6,7 @@ [id="managing-silences_{context}"] = Managing silences +[role="_abstract"] You can create a silence for an alert in the {ocp} web console. After you create a silence, you will not receive notifications about an alert when the alert fires. diff --git a/modules/monitoring-modifying-core-platform-alerting-rules.adoc b/modules/monitoring-modifying-core-platform-alerting-rules.adoc index 64d1fec1a738..5307201adffa 100644 --- a/modules/monitoring-modifying-core-platform-alerting-rules.adoc +++ b/modules/monitoring-modifying-core-platform-alerting-rules.adoc @@ -6,6 +6,7 @@ [id="modifying-core-platform-alerting-rules_{context}"] = Modifying core platform alerting rules +[role="_abstract"] As a cluster administrator, you can modify core platform alerts before Alertmanager routes them to a receiver. For example, you can change the severity label of an alert, add a custom label, or exclude an alert from being sent to Alertmanager. diff --git a/modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc b/modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc index 870933552e92..23a1039cbb60 100644 --- a/modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc +++ b/modules/monitoring-modifying-retention-time-and-size-for-prometheus-metrics-data.adoc @@ -19,6 +19,7 @@ :component: prometheus // end::UWM[] +[role="_abstract"] By default, Prometheus retains metrics data for // tag::CPM[] 15 days for core platform monitoring. diff --git a/modules/monitoring-modifying-the-retention-time-for-thanos-ruler-metrics-data.adoc b/modules/monitoring-modifying-the-retention-time-for-thanos-ruler-metrics-data.adoc index 31b63ded1dc5..475734d06173 100644 --- a/modules/monitoring-modifying-the-retention-time-for-thanos-ruler-metrics-data.adoc +++ b/modules/monitoring-modifying-the-retention-time-for-thanos-ruler-metrics-data.adoc @@ -6,6 +6,7 @@ [id="modifying-the-retention-time-for-thanos-ruler-metrics-data_{context}"] = Modifying the retention time for Thanos Ruler metrics data +[role="_abstract"] By default, for user-defined projects, Thanos Ruler automatically retains metrics data for 24 hours. You can modify the retention time to change how long this data is retained by specifying a time value in the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` namespace. .Prerequisites diff --git a/modules/monitoring-monitoring-stack-in-ha-clusters.adoc b/modules/monitoring-monitoring-stack-in-ha-clusters.adoc index a0246553c4e0..643272b72f8f 100644 --- a/modules/monitoring-monitoring-stack-in-ha-clusters.adoc +++ b/modules/monitoring-monitoring-stack-in-ha-clusters.adoc @@ -6,6 +6,7 @@ [id="monitoring-stack-in-ha-clusters_{context}"] = The monitoring stack in high-availability clusters +[role="_abstract"] By default, in multi-node clusters, the following components run in high-availability (HA) mode to prevent data loss and service interruption: * Prometheus diff --git a/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc b/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc index 328357dfb891..70a4bca47fe8 100644 --- a/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc +++ b/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc @@ -16,6 +16,7 @@ :namespace-name: openshift-user-workload-monitoring // end::UWM[] +[role="_abstract"] // tag::CPM[] To specify the nodes in your cluster on which monitoring stack components will run, configure the `nodeSelector` constraint for the components in the `cluster-monitoring-config` config map to match labels assigned to the nodes. diff --git a/modules/monitoring-optimizing-alerting-for-user-defined-projects.adoc b/modules/monitoring-optimizing-alerting-for-user-defined-projects.adoc index cd2065ba065f..dca247a458b8 100644 --- a/modules/monitoring-optimizing-alerting-for-user-defined-projects.adoc +++ b/modules/monitoring-optimizing-alerting-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="optimizing-alerting-for-user-defined-projects_{context}"] = Optimizing alerting for user-defined projects +[role="_abstract"] You can optimize alerting for your own projects by considering the following recommendations when creating alerting rules: * *Minimize the number of alerting rules that you create for your project*. Create alerting rules that notify you of conditions that impact you. It is more difficult to notice relevant alerts if you generate many alerts for conditions that do not impact you. diff --git a/modules/monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus.adoc b/modules/monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus.adoc index a6aed2f65c7b..f675e940af8c 100644 --- a/modules/monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus.adoc +++ b/modules/monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus.adoc @@ -6,6 +6,7 @@ [id="monitoring-querying-metrics-by-using-the-federation-endpoint-for-prometheus_{context}"] = Querying metrics by using the federation endpoint for Prometheus +[role="_abstract"] You can use the federation endpoint for Prometheus to scrape platform and user-defined metrics from a network location outside the cluster. To do so, access the Prometheus `/federate` endpoint for the cluster via an {ocp} route. diff --git a/modules/monitoring-querying-metrics-for-all-projects-with-mon-dashboard.adoc b/modules/monitoring-querying-metrics-for-all-projects-with-mon-dashboard.adoc index b7870e19fe42..c780bd4aa7a8 100644 --- a/modules/monitoring-querying-metrics-for-all-projects-with-mon-dashboard.adoc +++ b/modules/monitoring-querying-metrics-for-all-projects-with-mon-dashboard.adoc @@ -7,6 +7,7 @@ [id="querying-metrics-for-all-projects-with-mon-dashboard_{context}"] = Querying metrics for all projects with the {ocp} web console +[role="_abstract"] // The following section will be included in the administrator section, hence there is no need to include "administrator" in the title You can use the {ocp} metrics query browser to run Prometheus Query Language (PromQL) queries to examine metrics visualized on a plot. This functionality provides information about the state of a cluster and any user-defined workloads that you are monitoring. diff --git a/modules/monitoring-querying-metrics-for-user-defined-projects-with-mon-dashboard.adoc b/modules/monitoring-querying-metrics-for-user-defined-projects-with-mon-dashboard.adoc index 6ffb46ec35ec..91a4b39f163a 100644 --- a/modules/monitoring-querying-metrics-for-user-defined-projects-with-mon-dashboard.adoc +++ b/modules/monitoring-querying-metrics-for-user-defined-projects-with-mon-dashboard.adoc @@ -7,6 +7,7 @@ [id="querying-metrics-for-user-defined-projects-with-mon-dashboard_{context}"] = Querying metrics for user-defined projects with the {ocp} web console +[role="_abstract"] You can use the {ocp} metrics query browser to run Prometheus Query Language (PromQL) queries to examine metrics visualized on a plot. This functionality provides information about any user-defined workloads that you are monitoring. As a developer, you must specify a project name when querying metrics. You must have the required privileges to view metrics for the selected project. diff --git a/modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc b/modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc index 8120ec4c684c..0b44319129de 100644 --- a/modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc +++ b/modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="removing-alerting-rules-for-user-defined-projects_{context}"] = Removing alerting rules for user-defined projects +[role="_abstract"] You can remove alerting rules for user-defined projects. .Prerequisites diff --git a/modules/monitoring-resizing-a-persistent-volume.adoc b/modules/monitoring-resizing-a-persistent-volume.adoc index ddd1beefd639..54d1514c94f3 100644 --- a/modules/monitoring-resizing-a-persistent-volume.adoc +++ b/modules/monitoring-resizing-a-persistent-volume.adoc @@ -19,6 +19,7 @@ :component: thanosRuler // end::UWM[] +[role="_abstract"] // tag::CPM[] You can resize a persistent volume (PV) for monitoring components, such as Prometheus or Alertmanager. // end::CPM[] diff --git a/modules/monitoring-resolving-the-alertmanagerreceiversnotconfigured-alert.adoc b/modules/monitoring-resolving-the-alertmanagerreceiversnotconfigured-alert.adoc index 00b9e8e13289..1ee05ad29e04 100644 --- a/modules/monitoring-resolving-the-alertmanagerreceiversnotconfigured-alert.adoc +++ b/modules/monitoring-resolving-the-alertmanagerreceiversnotconfigured-alert.adoc @@ -6,6 +6,7 @@ [id="resolving-the-alertmanagerreceiversnotconfigured-alert_{context}"] = Resolving the AlertmanagerReceiversNotConfigured alert +[role="_abstract"] Every cluster that is deployed has the `AlertmanagerReceiversNotConfigured` alert firing by default. To resolve the issue, you must configure alert receivers. * For default platform monitoring, follow the steps in "Configuring alert notifications" in _Configuring core platform monitoring_. diff --git a/modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc b/modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc index 1f8749d124e6..c016263e7691 100644 --- a/modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc +++ b/modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc @@ -7,6 +7,7 @@ [id="resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus_{context}"] = Resolving the KubePersistentVolumeFillingUp alert firing for Prometheus +[role="_abstract"] As a cluster administrator, you can resolve the `KubePersistentVolumeFillingUp` alert being triggered for Prometheus. The critical alert fires when a persistent volume (PV) claimed by a `prometheus-k8s-*` pod in the `openshift-monitoring` project has less than 3% total space remaining. This can cause Prometheus to function abnormally. diff --git a/modules/monitoring-resources-reference-for-the-cluster-monitoring-operator.adoc b/modules/monitoring-resources-reference-for-the-cluster-monitoring-operator.adoc index d983d3f0774f..13f0d999104c 100644 --- a/modules/monitoring-resources-reference-for-the-cluster-monitoring-operator.adoc +++ b/modules/monitoring-resources-reference-for-the-cluster-monitoring-operator.adoc @@ -7,6 +7,7 @@ [id="resources-reference-for-the-cluster-monitoring-operator_{context}"] = Resources reference for the Cluster Monitoring Operator +[role="_abstract"] This document describes the following resources deployed and managed by the Cluster Monitoring Operator (CMO): * link:#cmo-routes-resources_{context}[Routes] diff --git a/modules/monitoring-retention-time-and-size-for-prometheus-metrics-data.adoc b/modules/monitoring-retention-time-and-size-for-prometheus-metrics-data.adoc index 386193442c38..37fab326b1fd 100644 --- a/modules/monitoring-retention-time-and-size-for-prometheus-metrics-data.adoc +++ b/modules/monitoring-retention-time-and-size-for-prometheus-metrics-data.adoc @@ -6,6 +6,7 @@ [id="retention-time-and-size-for-prometheus-metrics-data_{context}"] = Retention time and size for Prometheus metrics +[role="_abstract"] By default, Prometheus retains metrics data for the following durations: * *Core platform monitoring*: 15 days diff --git a/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc b/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc index b0b84901e1ae..e0e75ab1d06b 100644 --- a/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc +++ b/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc @@ -6,6 +6,7 @@ [id="reviewing-monitoring-dashboards-admin_{context}"] = Reviewing monitoring dashboards as a cluster administrator +[role="_abstract"] As an administrator, you can view dashboards relating to core {ocp} cluster components. include::snippets/unified-perspective-web-console.adoc[] diff --git a/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc b/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc index 7e8adfd3ed8e..b47922507984 100644 --- a/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc +++ b/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc @@ -6,6 +6,7 @@ [id="reviewing-monitoring-dashboards-developer_{context}"] = Reviewing monitoring dashboards as a developer +[role="_abstract"] As a developer, you can view dashboards relating to projects you have permissions for. include::snippets/unified-perspective-web-console.adoc[] diff --git a/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc b/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc index 022fbcf5e4b9..ae90509ea0dc 100644 --- a/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc +++ b/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc @@ -6,6 +6,7 @@ [id="searching-alerts-silences-and-alerting-rules_{context}"] = Searching and filtering alerts, silences, and alerting rules +[role="_abstract"] You can filter the alerts, silences, and alerting rules that are displayed in the Alerting UI. This section provides a description of each of the available filtering options. [id="understanding-alert-filters_{context}"] diff --git a/modules/monitoring-sending-notifications-to-external-systems.adoc b/modules/monitoring-sending-notifications-to-external-systems.adoc index 7b6efe1797f6..9d5d13a314c2 100644 --- a/modules/monitoring-sending-notifications-to-external-systems.adoc +++ b/modules/monitoring-sending-notifications-to-external-systems.adoc @@ -7,6 +7,7 @@ [id="sending-notifications-to-external-systems_{context}"] = Sending notifications to external systems +[role="_abstract"] In {ocp} {product-version}, firing alerts can be viewed in the Alerting UI. Alerts are not configured by default to be sent to any notification systems. You can configure {ocp} to send alerts to the following receiver types: * PagerDuty diff --git a/modules/monitoring-setting-log-levels-for-monitoring-components.adoc b/modules/monitoring-setting-log-levels-for-monitoring-components.adoc index 1c1d414682e7..e0dc0749d427 100644 --- a/modules/monitoring-setting-log-levels-for-monitoring-components.adoc +++ b/modules/monitoring-setting-log-levels-for-monitoring-components.adoc @@ -25,6 +25,7 @@ :component-name: Thanos Ruler // end::UWM[] +[role="_abstract"] // tag::CPM[] You can configure the log level for Alertmanager, Prometheus Operator, Prometheus, and {component-name} and log verbosity for Metrics Server. // end::CPM[] diff --git a/modules/monitoring-setting-query-log-file-for-prometheus.adoc b/modules/monitoring-setting-query-log-file-for-prometheus.adoc index 5fb213a82091..47304bcf6f0a 100644 --- a/modules/monitoring-setting-query-log-file-for-prometheus.adoc +++ b/modules/monitoring-setting-query-log-file-for-prometheus.adoc @@ -21,6 +21,7 @@ :pod: prometheus-user-workload-0 // end::UWM[] +[role="_abstract"] You can configure Prometheus to write all queries that have been run by the engine to a log file. [IMPORTANT] diff --git a/modules/monitoring-setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects.adoc b/modules/monitoring-setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects.adoc index 92a7dba9af29..8462e967cb5f 100644 --- a/modules/monitoring-setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects.adoc +++ b/modules/monitoring-setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="setting-scrape-and-evaluation-intervals-limits-for-user-defined-projects_{context}"] = Setting scrape intervals, evaluation intervals, and enforced limits for user-defined projects +[role="_abstract"] You can set the following scrape and label limits for user-defined projects: * Limit the number of samples that can be accepted per target scrape diff --git a/modules/monitoring-setting-the-body-size-limit-for-metrics-scraping.adoc b/modules/monitoring-setting-the-body-size-limit-for-metrics-scraping.adoc index d7f6d724f1f2..5e0bfe7f8f8a 100644 --- a/modules/monitoring-setting-the-body-size-limit-for-metrics-scraping.adoc +++ b/modules/monitoring-setting-the-body-size-limit-for-metrics-scraping.adoc @@ -6,6 +6,7 @@ [id="setting-the-body-size-limit-for-metrics-scraping_{context}"] = Setting the body size limit for metrics scraping +[role="_abstract"] By default, no limit exists for the uncompressed body size for data returned from scraped metrics targets. You can set a body size limit to help avoid situations in which Prometheus consumes excessive amounts of memory when scraped targets return a response that contains a large amount of data. In addition, by setting a body size limit, you can reduce the impact that a malicious target might have on Prometheus and on the cluster as a whole. diff --git a/modules/monitoring-setting-up-metrics-collection-for-user-defined-projects.adoc b/modules/monitoring-setting-up-metrics-collection-for-user-defined-projects.adoc index bae30e8ec0ea..315d677b48c5 100644 --- a/modules/monitoring-setting-up-metrics-collection-for-user-defined-projects.adoc +++ b/modules/monitoring-setting-up-metrics-collection-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="setting-up-metrics-collection-for-user-defined-projects_{context}"] = Setting up metrics collection for user-defined projects +[role="_abstract"] You can create a `ServiceMonitor` resource to scrape metrics from a service endpoint in a user-defined project. This assumes that your application uses a Prometheus client library to expose metrics to the `/metrics` canonical name. You can deploy a sample service in a user-defined project and then create a `ServiceMonitor` resource that defines how that service should be monitored. diff --git a/modules/monitoring-silencing-alerts.adoc b/modules/monitoring-silencing-alerts.adoc index 73dfef3784b3..3d5cf6a38654 100644 --- a/modules/monitoring-silencing-alerts.adoc +++ b/modules/monitoring-silencing-alerts.adoc @@ -3,10 +3,10 @@ // * observability/monitoring/managing-alerts.adoc :_mod-docs-content-type: PROCEDURE - [id="silencing-alerts_{context}"] = Silencing alerts +[role="_abstract"] You can silence a specific alert or silence alerts that match a specification that you define. .Prerequisites diff --git a/modules/monitoring-specifying-how-a-service-is-monitored.adoc b/modules/monitoring-specifying-how-a-service-is-monitored.adoc index 66b9bba0a9a0..7812ef0fbf72 100644 --- a/modules/monitoring-specifying-how-a-service-is-monitored.adoc +++ b/modules/monitoring-specifying-how-a-service-is-monitored.adoc @@ -6,6 +6,7 @@ [id="specifying-how-a-service-is-monitored_{context}"] = Specifying how a service is monitored +[role="_abstract"] To use the metrics exposed by your service, you must configure {ocp} monitoring to scrape metrics from the `/metrics` endpoint. You can do this using a `ServiceMonitor` custom resource definition (CRD) that specifies how a service should be monitored, or a `PodMonitor` CRD that specifies how a pod should be monitored. The former requires a `Service` object, while the latter does not, allowing Prometheus to directly scrape metrics from the metrics endpoint exposed by a pod. This procedure shows you how to create a `ServiceMonitor` resource for a service in a user-defined project. diff --git a/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc b/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc index 91c0adc83880..6714818c6765 100644 --- a/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc +++ b/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc @@ -22,6 +22,7 @@ :thanos: thanosRuler // end::UWM[] +[role="_abstract"] To configure CPU and memory resources, specify values for resource limits and requests in the `{configmap-name}` `ConfigMap` object in the `{namespace-name}` namespace. .Prerequisites diff --git a/modules/monitoring-support-considerations.adoc b/modules/monitoring-support-considerations.adoc index 95da6011574f..630ba833b3c9 100644 --- a/modules/monitoring-support-considerations.adoc +++ b/modules/monitoring-support-considerations.adoc @@ -6,6 +6,7 @@ [id="support-considerations_{context}"] = Support considerations for monitoring +[role="_abstract"] [NOTE] ==== Backward compatibility for metrics, recording rules, or alerting rules is not guaranteed. diff --git a/modules/monitoring-support-policy-for-monitoring-operators.adoc b/modules/monitoring-support-policy-for-monitoring-operators.adoc index 454565f7db20..0bd74c188165 100644 --- a/modules/monitoring-support-policy-for-monitoring-operators.adoc +++ b/modules/monitoring-support-policy-for-monitoring-operators.adoc @@ -6,6 +6,7 @@ [id="support-policy-for-monitoring-operators_{context}"] = Support policy for monitoring Operators +[role="_abstract"] Monitoring Operators ensure that {ocp} monitoring resources function as designed and tested. If Cluster Version Operator (CVO) control of an Operator is overridden, the Operator does not respond to configuration changes, reconcile the intended state of cluster objects, or receive updates. While overriding CVO control for an Operator can be helpful during debugging, this is unsupported and the cluster administrator assumes full control of the individual component configurations and upgrades. diff --git a/modules/monitoring-support-version-matrix-for-monitoring-components.adoc b/modules/monitoring-support-version-matrix-for-monitoring-components.adoc index 4ef0f5203763..5af1ccbe1d2e 100644 --- a/modules/monitoring-support-version-matrix-for-monitoring-components.adoc +++ b/modules/monitoring-support-version-matrix-for-monitoring-components.adoc @@ -6,6 +6,7 @@ [id="support-version-matrix-for-monitoring-components_{context}"] = Support version matrix for monitoring components +[role="_abstract"] The following matrix contains information about versions of monitoring components for {ocp} 4.12 and later releases: .{ocp} and component versions diff --git a/modules/monitoring-supported-remote-write-authentication-settings.adoc b/modules/monitoring-supported-remote-write-authentication-settings.adoc index eebd033f94c8..534f7a255eb7 100644 --- a/modules/monitoring-supported-remote-write-authentication-settings.adoc +++ b/modules/monitoring-supported-remote-write-authentication-settings.adoc @@ -6,6 +6,7 @@ [id="supported-remote-write-authentication-settings_{context}"] = Supported remote write authentication settings +[role="_abstract"] You can use different methods to authenticate with a remote write endpoint. The following authentication methods are supported: * AWS Signature Version 4 diff --git a/modules/monitoring-table-of-remote-write-metrics.adoc b/modules/monitoring-table-of-remote-write-metrics.adoc index 67a730635e5d..8f7ef89795ce 100644 --- a/modules/monitoring-table-of-remote-write-metrics.adoc +++ b/modules/monitoring-table-of-remote-write-metrics.adoc @@ -6,6 +6,7 @@ [id="table-of-remote-write-metrics_{context}"] = Table of remote write metrics +[role="_abstract"] The following table contains remote write and remote write-adjacent metrics with further descriptions. The metrics help solve issues during remote write configuration. [options="header"] diff --git a/modules/monitoring-targets-for-user-defined-projects.adoc b/modules/monitoring-targets-for-user-defined-projects.adoc index daec279585c2..8fd883284641 100644 --- a/modules/monitoring-targets-for-user-defined-projects.adoc +++ b/modules/monitoring-targets-for-user-defined-projects.adoc @@ -6,6 +6,7 @@ [id="monitoring-targets-for-user-defined-projects_{context}"] = Monitoring targets for user-defined projects +[role="_abstract"] ifndef::openshift-dedicated,openshift-rosa[] When monitoring is enabled for user-defined projects, you can monitor: endif::openshift-dedicated,openshift-rosa[] diff --git a/modules/monitoring-tips-for-optimizing-alerting-rules-for-core-platform-monitoring.adoc b/modules/monitoring-tips-for-optimizing-alerting-rules-for-core-platform-monitoring.adoc index 27cc361d171a..83d8481084a6 100644 --- a/modules/monitoring-tips-for-optimizing-alerting-rules-for-core-platform-monitoring.adoc +++ b/modules/monitoring-tips-for-optimizing-alerting-rules-for-core-platform-monitoring.adoc @@ -6,6 +6,7 @@ [id="tips-for-optimizing-alerting-rules-for-core-platform-monitoring_{context}"] = Tips for optimizing alerting rules for core platform monitoring +[role="_abstract"] If you customize core platform alerting rules to meet your organization's specific needs, follow these guidelines to help ensure that the customized rules are efficient and effective. * *Minimize the number of new rules*. diff --git a/modules/monitoring-understanding-the-monitoring-stack.adoc b/modules/monitoring-understanding-the-monitoring-stack.adoc index fef8374852e2..142083e6dfc7 100644 --- a/modules/monitoring-understanding-the-monitoring-stack.adoc +++ b/modules/monitoring-understanding-the-monitoring-stack.adoc @@ -7,6 +7,7 @@ [id="understanding-the-monitoring-stack_{context}"] = Understanding the monitoring stack +[role="_abstract"] The monitoring stack includes the following components: Default platform monitoring components:: diff --git a/modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc b/modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc index ecbadb1b46c7..a8d883c2c6c9 100644 --- a/modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc +++ b/modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc @@ -6,6 +6,7 @@ [id="using-node-selectors-to-move-monitoring-components_{context}"] = Using node selectors to move monitoring components +[role="_abstract"] By using the `nodeSelector` constraint with labeled nodes, you can move any of the monitoring stack components to specific nodes. By doing so, you can control the placement and distribution of the monitoring components across a cluster. diff --git a/modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc b/modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc index 0e3b427b77fe..a7116607ef96 100644 --- a/modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc +++ b/modules/monitoring-using-pod-topology-spread-constraints-for-monitoring.adoc @@ -6,6 +6,7 @@ [id="using-pod-topology-spread-constraints-for-monitoring_{context}"] = About pod topology spread constraints for monitoring +[role="_abstract"] You can use pod topology spread constraints to control how the monitoring pods are spread across a network topology when {ocp} pods are deployed in multiple availability zones. Pod topology spread constraints are suitable for controlling pod scheduling within hierarchical topologies in which nodes are spread across different infrastructure levels, such as regions and zones within those regions. diff --git a/modules/monitoring-viewing-a-list-of-available-metrics.adoc b/modules/monitoring-viewing-a-list-of-available-metrics.adoc index 01d1f5ed3743..6f16d0339313 100644 --- a/modules/monitoring-viewing-a-list-of-available-metrics.adoc +++ b/modules/monitoring-viewing-a-list-of-available-metrics.adoc @@ -6,6 +6,7 @@ [id="viewing-a-list-of-available-metrics_{context}"] = Viewing a list of available metrics +[role="_abstract"] As a cluster administrator or as a user with view permissions for all projects, you can view a list of metrics available in a cluster and output the list in JSON format. .Prerequisites