From c98d9355ddc81c0edb7c7b80b7c51ee9f39dc85b Mon Sep 17 00:00:00 2001 From: Eliska Romanova Date: Fri, 27 Feb 2026 15:45:52 +0100 Subject: [PATCH] OBSDOCS-2890: Create short descriptions --- .../configuring-alerts-and-notifications.adoc | 2 +- .../core-platform-monitoring-first-steps.adoc | 3 ++- modules/monitoring-4-20-release-notes.adoc | 2 +- ...ring-about-accessing-monitoring-web-service-apis.adoc | 7 +------ ...reating-alerting-rules-for-user-defined-projects.adoc | 2 +- modules/monitoring-about-managing-alerts.adoc | 2 +- modules/monitoring-about-monitoring-dashboards.adoc | 2 +- .../monitoring-about-performance-and-scalability.adoc | 3 ++- ...ng-limits-and-requests-for-monitoring-components.adoc | 2 ++ modules/monitoring-about-storing-and-recording-data.adoc | 3 ++- ...toring-accessing-alerting-rules-for-your-project.adoc | 2 +- modules/monitoring-accessing-the-alerting-ui.adoc | 2 +- ...dding-a-secret-to-the-alertmanager-configuration.adoc | 2 +- ...rt-reference-for-the-cluster-monitoring-operator.adoc | 2 +- ...additional-labels-to-your-time-series-and-alerts.adoc | 2 +- ...monitoring-choosing-a-metrics-collection-profile.adoc | 2 +- ...ster-monitoring-operator-configuration-reference.adoc | 2 +- modules/monitoring-common-terms.adoc | 2 +- ...-components-for-monitoring-user-defined-projects.adoc | 6 +----- .../monitoring-configurable-monitoring-components.adoc | 2 +- .../monitoring-configuring-alert-notifications-uwm.adoc | 2 ++ ...figuring-alert-routing-for-user-defined-projects.adoc | 2 +- ...-default-platform-alerts-and-user-defined-alerts.adoc | 4 +++- .../monitoring-configuring-external-alertmanagers.adoc | 9 +-------- ...nitoring-configuring-metrics-collection-profiles.adoc | 2 ++ modules/monitoring-configuring-persistent-storage.adoc | 4 +++- modules/monitoring-configuring-remote-write-storage.adoc | 2 +- .../monitoring-configuring-secrets-for-alertmanager.adoc | 4 ++-- ...cement-and-distribution-of-monitoring-components.adoc | 8 +++----- ...t-of-unbound-attributes-in-user-defined-projects.adoc | 4 +++- ...reating-alerting-rules-for-user-defined-projects.adoc | 2 +- ...onitoring-creating-cluster-id-labels-for-metrics.adoc | 4 +--- ...monitoring-creating-cluster-monitoring-configmap.adoc | 2 +- ...project-alerting-rules-for-user-defined-projects.adoc | 6 ++++-- modules/monitoring-creating-new-alerting-rules.adoc | 3 +-- modules/monitoring-creating-scrape-sample-alerts.adoc | 5 +---- modules/monitoring-default-monitoring-components.adoc | 2 ++ modules/monitoring-default-monitoring-targets.adoc | 9 ++------- modules/monitoring-deploying-a-sample-service.adoc | 2 +- ...termining-why-prometheus-is-consuming-disk-space.adoc | 2 ++ ...project-alerting-rules-for-user-defined-projects.adoc | 5 ++--- ...g-disabling-monitoring-for-user-defined-projects.adoc | 2 +- modules/monitoring-disabling-the-local-alertmanager.adoc | 4 ++-- modules/monitoring-editing-silences.adoc | 2 +- ...tmanager-instance-for-user-defined-alert-routing.adoc | 9 +-------- ...enabling-alert-routing-for-user-defined-projects.adoc | 7 +++---- ...nabling-monitoring-for-user-defined-projects-uwm.adoc | 4 +--- ...toring-enabling-query-logging-for-thanos-querier.adoc | 2 +- ...tmanager-instance-for-user-defined-alert-routing.adoc | 2 +- ...ing-example-remote-write-authentication-settings.adoc | 4 ++-- ...itoring-example-remote-write-queue-configuration.adoc | 4 +++- ...excluding-a-user-defined-project-from-monitoring.adoc | 2 +- modules/monitoring-expiring-silences.adoc | 2 +- ...rmation-about-alerts-silences-and-alerting-rules.adoc | 2 +- ...onfigure-alert-routing-for-user-defined-projects.adoc | 2 +- ...sers-permission-to-monitor-user-defined-projects.adoc | 4 ++-- ...g-users-permissions-for-core-platform-monitoring.adoc | 4 ++-- ...igating-why-user-defined-metrics-are-unavailable.adoc | 2 +- ...alerting-rules-for-all-projects-in-a-single-view.adoc | 2 +- ...ging-alerting-rules-for-core-platform-monitoring.adoc | 5 +++-- ...anaging-alerting-rules-for-user-defined-projects.adoc | 2 +- ...monitoring-managing-core-platform-alerting-rules.adoc | 5 +++-- ...u-and-memory-resources-for-monitoring-components.adoc | 7 ++++--- modules/monitoring-managing-silences.adoc | 4 ++-- modules/monitoring-managing-uwm-alerting-rules.adoc | 2 +- ...onitoring-modifying-core-platform-alerting-rules.adoc | 3 +-- ...ention-time-and-size-for-prometheus-metrics-data.adoc | 3 ++- ...the-retention-time-for-thanos-ruler-metrics-data.adoc | 2 +- modules/monitoring-monitoring-stack-in-ha-clusters.adoc | 4 +++- ...-moving-monitoring-components-to-different-nodes.adoc | 2 +- ...emoving-alerting-rules-for-user-defined-projects.adoc | 2 +- modules/monitoring-resizing-a-persistent-volume.adoc | 4 ++-- ...stentvolumefillingup-alert-firing-for-prometheus.adoc | 3 +-- ...ention-time-and-size-for-prometheus-metrics-data.adoc | 6 +++--- ...monitoring-reviewing-monitoring-dashboards-admin.adoc | 2 +- ...toring-reviewing-monitoring-dashboards-developer.adoc | 2 +- ...ing-searching-alerts-silences-and-alerting-rules.adoc | 4 +++- ...toring-sending-notifications-to-external-systems.adoc | 6 ++++-- ...monitoring-setting-query-log-file-for-prometheus.adoc | 2 +- ...ation-intervals-limits-for-user-defined-projects.adoc | 4 ++-- ...-up-metrics-collection-for-user-defined-projects.adoc | 5 ++++- modules/monitoring-silencing-alerts.adoc | 2 +- ...monitoring-specifying-how-a-service-is-monitored.adoc | 6 +++--- ...ng-limits-and-requests-for-monitoring-components.adoc | 2 +- ...nitoring-support-policy-for-monitoring-operators.adoc | 2 ++ ...g-supported-remote-write-authentication-settings.adoc | 4 +++- .../monitoring-targets-for-user-defined-projects.adoc | 2 ++ ...or-optimizing-alerting-for-user-defined-projects.adoc | 2 +- ...zing-alerting-rules-for-core-platform-monitoring.adoc | 2 +- .../monitoring-understanding-the-monitoring-stack.adoc | 2 ++ ...ing-node-selectors-to-move-monitoring-components.adoc | 5 +---- .../monitoring-viewing-a-list-of-available-metrics.adoc | 2 +- 92 files changed, 152 insertions(+), 153 deletions(-) diff --git a/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc b/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc index 996a7a132dd4..76a9f8d03541 100644 --- a/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc +++ b/configuring-core-platform-monitoring/configuring-alerts-and-notifications.adoc @@ -7,7 +7,7 @@ include::_attributes/common-attributes.adoc[] toc::[] [role="_abstract"] -You can configure a local or external Alertmanager instance to route alerts from Prometheus to endpoint receivers. You can also attach custom labels to all time series and alerts to add useful metadata information. +Configure a local or external Alertmanager instance to route alerts from Prometheus to endpoint receivers to receive timely notifications about the state of your cluster. You can also attach custom labels to all time series and alerts to add useful metadata information. //Configuring external Alertmanager instances include::modules/monitoring-configuring-external-alertmanagers.adoc[leveloffset=+1,tags=**;CPM;!UWM] diff --git a/getting-started/core-platform-monitoring-first-steps.adoc b/getting-started/core-platform-monitoring-first-steps.adoc index 05e93e072980..664d8a2a3b02 100644 --- a/getting-started/core-platform-monitoring-first-steps.adoc +++ b/getting-started/core-platform-monitoring-first-steps.adoc @@ -7,10 +7,11 @@ include::_attributes/common-attributes.adoc[] toc::[] [role="_abstract"] +{ocp} provides cluster monitoring capabilities out of the box. As a cluster administrator, you can further configure monitoring components to suit the needs of different users in various scenarios. + After {ocp} is installed, core platform monitoring components start collecting metrics, which you can query and view. The default in-cluster monitoring stack includes the core platform Prometheus instance that collects metrics from your cluster and the core Alertmanager instance that routes alerts, among other components. -Depending on who will use the monitoring stack and for what purposes, as a cluster administrator, you can further configure these monitoring components to suit the needs of different users in various scenarios. [id="configuring-core-platform-monitoring-postinstallation-steps_{context}"] == Configuring core platform monitoring: Postinstallation steps diff --git a/modules/monitoring-4-20-release-notes.adoc b/modules/monitoring-4-20-release-notes.adoc index 0b75ef6bf90c..7f1d23bff896 100644 --- a/modules/monitoring-4-20-release-notes.adoc +++ b/modules/monitoring-4-20-release-notes.adoc @@ -7,7 +7,7 @@ = {ocp} {product-version} monitoring release notes [role="_abstract"] -Changes for {ocp} {product-version} monitoring stack, including new features and enhancements, Technology Previews, deprecated and removed features, known issues, and fixed issues. +Review changes for {ocp} {product-version} monitoring stack, including new features and enhancements, Technology Previews, deprecated and removed features, known issues, and fixed issues. The changes are included in the following errata advisory: diff --git a/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc b/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc index f4d2fd456780..321b2a3eb798 100644 --- a/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc +++ b/modules/monitoring-about-accessing-monitoring-web-service-apis.adoc @@ -7,12 +7,7 @@ = 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 -* Alertmanager -* Thanos Ruler -* Thanos Querier +Directly access web service API endpoints from the command line for Prometheus, Alertmanager, Thanos Ruler, and Thanos Querier to query metrics, manage alerts, and integrate with automation tools. [IMPORTANT] ==== 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 d03c2033ae10..bdd1df491294 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 @@ -7,7 +7,7 @@ = 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. +Create alerting rules for user-defined projects to monitor your custom applications and services with project-specific alerts. Those alerting rules 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 3ad760cb6eb4..678a95943490 100644 --- a/modules/monitoring-about-managing-alerts.adoc +++ b/modules/monitoring-about-managing-alerts.adoc @@ -7,7 +7,7 @@ = Managing alerts [role="_abstract"] -In the {ocp}, the Alerting UI enables you to manage alerts, silences, and alerting rules. +Learn about managing alerts, silences, and alerting rules through the Alerting UI to maintain cluster health and respond effectively to issues. * *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. * *Alerts*. An alert is fired when the conditions defined in an alerting rule are true. Alerts provide a notification that a set of circumstances are apparent within an {ocp} cluster. diff --git a/modules/monitoring-about-monitoring-dashboards.adoc b/modules/monitoring-about-monitoring-dashboards.adoc index eed6ce2ff9c6..f50e87903d39 100644 --- a/modules/monitoring-about-monitoring-dashboards.adoc +++ b/modules/monitoring-about-monitoring-dashboards.adoc @@ -7,7 +7,7 @@ = 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. +{ocp} provides a set of monitoring dashboards that help you track cluster health, identify performance issues, and troubleshoot problems across core components and user workloads. include::snippets/unified-perspective-web-console.adoc[] diff --git a/modules/monitoring-about-performance-and-scalability.adoc b/modules/monitoring-about-performance-and-scalability.adoc index a29576d7e8f7..f9b82111f048 100644 --- a/modules/monitoring-about-performance-and-scalability.adoc +++ b/modules/monitoring-about-performance-and-scalability.adoc @@ -7,7 +7,8 @@ = About performance and scalability [role="_abstract"] -You can optimize the performance and scale of your clusters. +Optimize the performance and scale of your clusters to handle larger workloads, reduce resource consumption, and improve cluster efficiency. + You can configure the monitoring stack by performing any of the following actions: * Control the placement and distribution of monitoring components: 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 5ff32afa5402..f4865691bdd2 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 @@ -7,6 +7,8 @@ = About specifying limits and requests for monitoring components [role="_abstract"] +Specify resource limits and requests for core platform monitoring and user workload monitoring components to ensure proper resource allocation and prevent resource exhaustion. + 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-about-storing-and-recording-data.adoc b/modules/monitoring-about-storing-and-recording-data.adoc index c8f2b026aac2..436a3cc971ef 100644 --- a/modules/monitoring-about-storing-and-recording-data.adoc +++ b/modules/monitoring-about-storing-and-recording-data.adoc @@ -7,7 +7,8 @@ = About storing and recording data [role="_abstract"] -You can store and record data to help you protect the data and use them for troubleshooting. +Store and record data to protect and use them for troubleshooting. + You can configure the monitoring stack by performing any of the following actions: * Configure persistent storage: diff --git a/modules/monitoring-accessing-alerting-rules-for-your-project.adoc b/modules/monitoring-accessing-alerting-rules-for-your-project.adoc index d86bb6a4081f..36fea42bd257 100644 --- a/modules/monitoring-accessing-alerting-rules-for-your-project.adoc +++ b/modules/monitoring-accessing-alerting-rules-for-your-project.adoc @@ -7,7 +7,7 @@ = 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. +Access alerting rules for user-defined projects to review current alert configurations and troubleshoot alerting issues. To list alerting rules for a user-defined project, you must be assigned the `monitoring-rules-view` cluster role for the project. .Prerequisites diff --git a/modules/monitoring-accessing-the-alerting-ui.adoc b/modules/monitoring-accessing-the-alerting-ui.adoc index 932cb500a36d..c9803c7ccbf6 100644 --- a/modules/monitoring-accessing-the-alerting-ui.adoc +++ b/modules/monitoring-accessing-the-alerting-ui.adoc @@ -8,7 +8,7 @@ = Accessing the Alerting UI [role="_abstract"] -The Alerting UI is accessible in the {ocp} web console. +Access the Alerting UI to manage alerts, silences, and alerting rules through the web console. .Procedure 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 d8766c81db1c..86a73f409969 100644 --- a/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc +++ b/modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc @@ -20,7 +20,7 @@ // end::UWM[] [role="_abstract"] -You can add secrets to the Alertmanager configuration by editing the `{configmap-name}` config map in the `{namespace-name}` project. +Add secrets to Alertmanager configuration to enable secure authentication with external alert receivers 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-alert-reference-for-the-cluster-monitoring-operator.adoc b/modules/monitoring-alert-reference-for-the-cluster-monitoring-operator.adoc index 1f23db6262cf..bea01f7b6292 100644 --- a/modules/monitoring-alert-reference-for-the-cluster-monitoring-operator.adoc +++ b/modules/monitoring-alert-reference-for-the-cluster-monitoring-operator.adoc @@ -3,7 +3,7 @@ = Alert reference for the {cmo-full} [role="_abstract"] -Learn about alerting rules that are managed by the {cmo-first} and are included in your cluster by default. +Review alerting rules that are managed by the {cmo-first} and are included in your cluster by default. Understanding these rules helps you identify when cluster components might fail and determine actions for faster troubleshooting and incident response. [IMPORTANT] ==== 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 e5e39d0addcd..b385610641e7 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 @@ -20,7 +20,7 @@ // 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. +Attach custom labels to all time series and alerts leaving Prometheus by using Prometheus external labels, to organize and identify metrics by environment, region, or other categories. .Prerequisites diff --git a/modules/monitoring-choosing-a-metrics-collection-profile.adoc b/modules/monitoring-choosing-a-metrics-collection-profile.adoc index d02427d4e669..fdf63c31c391 100644 --- a/modules/monitoring-choosing-a-metrics-collection-profile.adoc +++ b/modules/monitoring-choosing-a-metrics-collection-profile.adoc @@ -7,7 +7,7 @@ = 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. +Choose a metrics collection profile for core {ocp} monitoring components to balance monitoring coverage with resource consumption by editing the `cluster-monitoring-config` config map in the `openshift-monitoring` project. .Prerequisites diff --git a/modules/monitoring-cluster-monitoring-operator-configuration-reference.adoc b/modules/monitoring-cluster-monitoring-operator-configuration-reference.adoc index 0aa4bb96a45e..5d05333fee29 100644 --- a/modules/monitoring-cluster-monitoring-operator-configuration-reference.adoc +++ b/modules/monitoring-cluster-monitoring-operator-configuration-reference.adoc @@ -3,7 +3,7 @@ = {cmo-full} configuration reference [role="_abstract"] -To customize how {ocp} monitors both the platform and user-defined projects, edit the relevant `ConfigMap` objects that define the cluster and user workload monitoring configurations: +To customize how {ocp} monitors both the platform and user-defined projects, edit the relevant `ConfigMap` objects that define the cluster and user workload monitoring configurations. ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] * To configure default monitoring components, edit the `ConfigMap` object named `cluster-monitoring-config` in the `openshift-monitoring` namespace. diff --git a/modules/monitoring-common-terms.adoc b/modules/monitoring-common-terms.adoc index 9bc385e94301..d2a8773c5421 100644 --- a/modules/monitoring-common-terms.adoc +++ b/modules/monitoring-common-terms.adoc @@ -7,7 +7,7 @@ = Glossary of common terms for {ocp} monitoring [role="_abstract"] -This glossary defines common terms that are used in {ocp} architecture. +Review definitions of common terms when learning the monitoring stack concepts or searching for unfamiliar terminology in documentation. Alertmanager:: Alertmanager handles alerts received from Prometheus. Alertmanager is also responsible for sending the alerts to external notification systems. diff --git a/modules/monitoring-components-for-monitoring-user-defined-projects.adoc b/modules/monitoring-components-for-monitoring-user-defined-projects.adoc index 09db8753a86e..e004b77d6a4d 100644 --- a/modules/monitoring-components-for-monitoring-user-defined-projects.adoc +++ b/modules/monitoring-components-for-monitoring-user-defined-projects.adoc @@ -7,11 +7,7 @@ = Components for monitoring user-defined projects [role="_abstract"] -{ocp} -ifndef::openshift-dedicated,openshift-rosa[] -{product-version} -endif::openshift-dedicated,openshift-rosa[] -includes an optional enhancement to the monitoring stack that helps you monitor services and pods in user-defined projects. This feature includes the following components: +{ocp} includes an optional enhancement to the monitoring stack that helps you monitor services and pods in user-defined projects. This feature includes the following components: .Components for monitoring user-defined projects [options="header"] diff --git a/modules/monitoring-configurable-monitoring-components.adoc b/modules/monitoring-configurable-monitoring-components.adoc index 5bda28647f56..d2d31f9df3c0 100644 --- a/modules/monitoring-configurable-monitoring-components.adoc +++ b/modules/monitoring-configurable-monitoring-components.adoc @@ -23,7 +23,7 @@ // end::UWM[] [role="_abstract"] -The following table shows the monitoring components you can configure and the keys used to specify the components in the `{configmap-name}` config map. +Review configurable monitoring components and their corresponding config map keys used to specify the components in the `{configmap-name}` config map. // tag::UWM[] ifdef::openshift-dedicated,openshift-rosa[] diff --git a/modules/monitoring-configuring-alert-notifications-uwm.adoc b/modules/monitoring-configuring-alert-notifications-uwm.adoc index dd4118eabad0..04d0e47f44d9 100644 --- a/modules/monitoring-configuring-alert-notifications-uwm.adoc +++ b/modules/monitoring-configuring-alert-notifications-uwm.adoc @@ -7,6 +7,8 @@ = Configuring alert notifications [role="_abstract"] +Configure alert notifications for user-defined projects to ensure developers and teams receive timely notifications when their applications or services experience issues. + ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] In {ocp}, an administrator can enable alert routing for user-defined projects with one of the following methods: 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 db15c20dc1dc..d515a2226835 100644 --- a/modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc +++ b/modules/monitoring-configuring-alert-routing-for-user-defined-projects.adoc @@ -7,7 +7,7 @@ = 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. +If you are a non-administrator user with the `alert-routing-edit` cluster role, create or edit alert routing for user-defined projects to ensure alerts from your applications reach the appropriate notification systems and team members. .Prerequisites 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 fea650d85b23..abfa459618a1 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 @@ -7,7 +7,9 @@ = 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: +Configure different alert receivers for platform and user-defined alerts to route notifications to the appropriate teams and reduce notification fatigue. + +This configuration ensures the following results: * 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. diff --git a/modules/monitoring-configuring-external-alertmanagers.adoc b/modules/monitoring-configuring-external-alertmanagers.adoc index 4cdb3998ff7d..f1a8694315e1 100644 --- a/modules/monitoring-configuring-external-alertmanagers.adoc +++ b/modules/monitoring-configuring-external-alertmanagers.adoc @@ -22,14 +22,7 @@ // end::UWM[] [role="_abstract"] -The {ocp} monitoring stack includes a local Alertmanager instance that routes alerts from Prometheus. - -// tag::CPM[] -You can add external Alertmanager instances to route alerts for core {ocp} projects. -// end::CPM[] -// tag::UWM[] -You can add external Alertmanager instances to route alerts for user-defined projects. -// end::UWM[] +The {ocp} monitoring stack includes a local Alertmanager instance that routes alerts from Prometheus. Add external Alertmanager instances to integrate with existing alerting infrastructure or centralize alert management across multiple clusters. If you add the same external Alertmanager configuration for multiple clusters and disable the local instance for each cluster, you can then manage alert routing for multiple clusters by using a single external Alertmanager instance. diff --git a/modules/monitoring-configuring-metrics-collection-profiles.adoc b/modules/monitoring-configuring-metrics-collection-profiles.adoc index 1c61a2232d3b..3a4adf2f6acd 100644 --- a/modules/monitoring-configuring-metrics-collection-profiles.adoc +++ b/modules/monitoring-configuring-metrics-collection-profiles.adoc @@ -7,6 +7,8 @@ = About metrics collection profiles [role="_abstract"] +Optimize resource consumption with metrics collection profiles by choosing between comprehensive monitoring and essential-only metrics collection based on your cluster size and monitoring needs. + 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 d19123b3ca7b..69ae7cf326bb 100644 --- a/modules/monitoring-configuring-persistent-storage.adoc +++ b/modules/monitoring-configuring-persistent-storage.adoc @@ -7,12 +7,14 @@ = Configuring persistent storage [role="_abstract"] +Learn about persistent storage configuration for monitoring components to properly plan and deploy production-ready monitoring infrastructure. + 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. * Avoid getting duplicate notifications and losing silences for alerts when the Alertmanager pods are restarted. -For production environments, it is highly recommended to configure persistent storage. +For production environments, it is highly recommended to configure persistent storage. // tag::CPM[] [IMPORTANT] diff --git a/modules/monitoring-configuring-remote-write-storage.adoc b/modules/monitoring-configuring-remote-write-storage.adoc index 8aa636b80424..696a04c1b719 100644 --- a/modules/monitoring-configuring-remote-write-storage.adoc +++ b/modules/monitoring-configuring-remote-write-storage.adoc @@ -19,7 +19,7 @@ // 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. +Extend metrics retention and centralize monitoring data by sending metrics to external systems, supporting compliance requirements and long-term analytics. 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 ebe603e93993..294cd2fcbf5e 100644 --- a/modules/monitoring-configuring-secrets-for-alertmanager.adoc +++ b/modules/monitoring-configuring-secrets-for-alertmanager.adoc @@ -7,9 +7,9 @@ = Configuring secrets for Alertmanager [role="_abstract"] -The {ocp} monitoring stack includes Alertmanager, which routes alerts from Prometheus to endpoint receivers. +Securely send alerts to authenticated endpoints by configuring Alertmanager secrets, protecting sensitive credentials while maintaining reliable alert delivery to external systems. -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. +The 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, configure Alertmanager to use a secret that contains authentication credentials for the receiver. For example, you can configure Alertmanager to use a secret to authenticate with an endpoint receiver that requires a certificate issued by a private Certificate Authority (CA). You can also configure Alertmanager to use a secret to authenticate with a receiver that requires a password file for Basic HTTP authentication. diff --git a/modules/monitoring-controlling-placement-and-distribution-of-monitoring-components.adoc b/modules/monitoring-controlling-placement-and-distribution-of-monitoring-components.adoc index 36c1c1599830..fff7f404f18f 100644 --- a/modules/monitoring-controlling-placement-and-distribution-of-monitoring-components.adoc +++ b/modules/monitoring-controlling-placement-and-distribution-of-monitoring-components.adoc @@ -8,11 +8,9 @@ = Controlling the placement and distribution of monitoring components [role="_abstract"] -You can move the monitoring stack components to specific nodes: +Control the placement and distribution of monitoring components across cluster nodes to optimize system resource use, improve performance, and separate workloads based on specific requirements or policies. + +You can move the monitoring stack components to specific nodes with the following methods: * Use the `nodeSelector` constraint with labeled nodes to move any of the monitoring stack components to specific nodes. * Assign tolerations to enable moving components to tainted nodes. - -By doing so, you control the placement and distribution of the monitoring components across a cluster. - -By controlling placement and distribution of monitoring components, you can optimize system resource use, improve performance, and separate workloads based on specific requirements or policies. 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 57a9a41c12f0..6af9bc9b812a 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 @@ -7,7 +7,9 @@ = 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. +Prevent monitoring performance degradation and excessive resource consumption by controlling the impact of unbound metrics attributes. + +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. 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 a6c3fd038558..759e136d3ad0 100644 --- a/modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc +++ b/modules/monitoring-creating-alerting-rules-for-user-defined-projects.adoc @@ -7,7 +7,7 @@ = 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. +Create alerting rules for user-defined projects to monitor your custom applications and receive notifications when specific conditions or thresholds are met to improve incident response times. [NOTE] ==== diff --git a/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc b/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc index 399ad9dc4338..a6f20e655bfd 100644 --- a/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc +++ b/modules/monitoring-creating-cluster-id-labels-for-metrics.adoc @@ -19,9 +19,7 @@ // 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. +Create cluster ID labels for metrics to uniquely identify and track metrics across clusters and workloads by adding the `write_relabel` settings for remote write storage in the `{configmap-name}` config map in the `{namespace-name}` namespace. ifndef::openshift-dedicated,openshift-rosa[] // tag::UWM[] diff --git a/modules/monitoring-creating-cluster-monitoring-configmap.adoc b/modules/monitoring-creating-cluster-monitoring-configmap.adoc index 6b04c4ab3d92..392ab1c83b5f 100644 --- a/modules/monitoring-creating-cluster-monitoring-configmap.adoc +++ b/modules/monitoring-creating-cluster-monitoring-configmap.adoc @@ -7,7 +7,7 @@ = 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. +Customize the default monitoring stack to match your infrastructure and performance requirements by creating and updating the `cluster-monitoring-config` config map in the `openshift-monitoring` project. .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 2a22535a56ae..f64473ed48b9 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 @@ -7,9 +7,11 @@ = 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. +Reduce alerting rule duplication by creating alerting rules that apply across multiple user-defined projects instead of maintaining separate rules in each project. -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. +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 applicable to all projects. + +Filter which projects are included or excluded from the alerting rule by using PromQL queries in the `PrometheusRule` object. .Prerequisites diff --git a/modules/monitoring-creating-new-alerting-rules.adoc b/modules/monitoring-creating-new-alerting-rules.adoc index 5726eda26ee9..1dc8f9e15067 100644 --- a/modules/monitoring-creating-new-alerting-rules.adoc +++ b/modules/monitoring-creating-new-alerting-rules.adoc @@ -7,8 +7,7 @@ = 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. +As a cluster administrator, create custom alerting rules based on platform metrics to monitor specific conditions important to your environment, ensuring you receive notifications about issues that default alerts do not cover. [NOTE] ==== diff --git a/modules/monitoring-creating-scrape-sample-alerts.adoc b/modules/monitoring-creating-scrape-sample-alerts.adoc index 0bd60fbb8cfa..aee058303ad7 100644 --- a/modules/monitoring-creating-scrape-sample-alerts.adoc +++ b/modules/monitoring-creating-scrape-sample-alerts.adoc @@ -7,10 +7,7 @@ = Creating scrape sample alerts [role="_abstract"] -You can create alerts that notify you in the following situations: - -* The target cannot be scraped or is not available for the specified `for` duration -* A scrape sample threshold is reached or is exceeded for the specified `for` duration +Create alerts that notify you when monitoring targets cannot be scraped or become unavailable, or when scrape sample thresholds are reached or exceeded. .Prerequisites diff --git a/modules/monitoring-default-monitoring-components.adoc b/modules/monitoring-default-monitoring-components.adoc index b313489fffaa..d75e15f24d98 100644 --- a/modules/monitoring-default-monitoring-components.adoc +++ b/modules/monitoring-default-monitoring-components.adoc @@ -7,6 +7,8 @@ = Default monitoring components [role="_abstract"] +Learn about the monitoring architecture and each component's role in the monitoring stack. + 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 b2f1ed271c5c..6754a58d1631 100644 --- a/modules/monitoring-default-monitoring-targets.adoc +++ b/modules/monitoring-default-monitoring-targets.adoc @@ -7,15 +7,10 @@ = 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. +Review which components are monitored by default to understand your cluster's monitoring coverage. +In addition to the components of the stack itself, the default monitoring stack monitors additional platform components. The following are examples of monitoring targets: -endif::openshift-dedicated,openshift-rosa[] - -ifdef::openshift-dedicated,openshift-rosa[] -The following are examples of targets monitored by Red{nbsp}Hat Site Reliability Engineers (SRE) in your {ocp} cluster: -endif::openshift-dedicated,openshift-rosa[] * CoreDNS * etcd diff --git a/modules/monitoring-deploying-a-sample-service.adoc b/modules/monitoring-deploying-a-sample-service.adoc index 60a6d59f1db8..6b4df9762590 100644 --- a/modules/monitoring-deploying-a-sample-service.adoc +++ b/modules/monitoring-deploying-a-sample-service.adoc @@ -7,7 +7,7 @@ = Deploying a sample service [role="_abstract"] -To test monitoring of a service in a user-defined project, you can deploy a sample service. +Deploy a sample service to verify user workload monitoring works correctly for your services and learn how to expose custom metrics. .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 10ea56eca4ef..8b309685b582 100644 --- a/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc +++ b/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc @@ -8,6 +8,8 @@ = Determining why Prometheus is consuming a lot of disk space [role="_abstract"] +Diagnose and resolve high Prometheus disk usage by identifying problematic metrics with unbound attributes that create excessive time series data. + 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. 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 f55d083f7e6b..1fa03a34ea25 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 @@ -7,10 +7,9 @@ = 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: +Disable cross-project alerting rules for user-defined projects to prevent user workload monitoring from overloading the monitoring stack and to protect against buggy alerting rules affecting cluster performance without having to troubleshoot individual rules. -* To prevent user-defined monitoring from overloading the cluster monitoring stack. -* To prevent buggy alerting rules from being applied to the cluster without having to identify the rule that causes the issue. +The creation of 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. .Prerequisites diff --git a/modules/monitoring-disabling-monitoring-for-user-defined-projects.adoc b/modules/monitoring-disabling-monitoring-for-user-defined-projects.adoc index 1a55f5c0a597..60146df50c65 100644 --- a/modules/monitoring-disabling-monitoring-for-user-defined-projects.adoc +++ b/modules/monitoring-disabling-monitoring-for-user-defined-projects.adoc @@ -7,7 +7,7 @@ = 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. +After enabling monitoring for user-defined projects, you can disable it again by setting `enableUserWorkload: false` in the `cluster-monitoring-config` config map if you no longer require monitoring of your applications. [NOTE] ==== diff --git a/modules/monitoring-disabling-the-local-alertmanager.adoc b/modules/monitoring-disabling-the-local-alertmanager.adoc index 4b696a0ebc74..dce00b6f5477 100644 --- a/modules/monitoring-disabling-the-local-alertmanager.adoc +++ b/modules/monitoring-disabling-the-local-alertmanager.adoc @@ -7,9 +7,9 @@ = 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, for example when you use external Alertmanager instance or when alerts are not required, disable it by configuring the `cluster-monitoring-config` config map in the `openshift-monitoring` project. -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. +A local Alertmanager that routes alerts from Prometheus instances is enabled by default in the `openshift-monitoring` project. .Prerequisites diff --git a/modules/monitoring-editing-silences.adoc b/modules/monitoring-editing-silences.adoc index ff16eb8af9af..2645965748b7 100644 --- a/modules/monitoring-editing-silences.adoc +++ b/modules/monitoring-editing-silences.adoc @@ -7,7 +7,7 @@ = Editing silences [role="_abstract"] -You can edit a silence, which expires the existing silence and creates a new one with the changed configuration. +Edit a silence to customize it for your requirements. Editing the silence 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 4109f40b2c91..f9f1ca724e8b 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 @@ -7,14 +7,7 @@ = 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::[] -ifdef::openshift-rosa,openshift-dedicated[] -In {ocp}, you may want to deploy a dedicated Alertmanager instance for user-defined projects, which provides user-defined alerts separate from default platform alerts. -endif::[] - -In these cases, you can optionally enable a separate instance of Alertmanager to send alerts for user-defined projects only. +In some clusters, you might want to enable 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. .Prerequisites 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 94dbb484657b..63c56f71777e 100644 --- a/modules/monitoring-enabling-alert-routing-for-user-defined-projects.adoc +++ b/modules/monitoring-enabling-alert-routing-for-user-defined-projects.adoc @@ -7,7 +7,8 @@ = Enabling alert routing for user-defined projects [role="_abstract"] -In {ocp}, an administrator can enable alert routing for user-defined projects. +An administrator can enable alert routing for user-defined projects to allow developers and other users to configure alert routing for their custom alerts in user-defined projects. + This process consists of the following steps: ifndef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] @@ -18,6 +19,4 @@ endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] ifdef::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] * Enable alert routing for user-defined projects to use a separate Alertmanager instance. endif::openshift-dedicated,openshift-rosa,openshift-rosa-hcp[] -* Grant users permission to configure alert routing for user-defined projects. - -After you complete these steps, developers and other users can configure custom alerts and alert routing for their user-defined projects. \ No newline at end of file +* Grant users permission to configure alert routing for user-defined projects. \ No newline at end of file diff --git a/modules/monitoring-enabling-monitoring-for-user-defined-projects-uwm.adoc b/modules/monitoring-enabling-monitoring-for-user-defined-projects-uwm.adoc index 9ea4d794e342..4f910215f900 100644 --- a/modules/monitoring-enabling-monitoring-for-user-defined-projects-uwm.adoc +++ b/modules/monitoring-enabling-monitoring-for-user-defined-projects-uwm.adoc @@ -7,8 +7,6 @@ = Enabling monitoring for user-defined projects [role="_abstract"] -In {ocp}, you can enable monitoring for user-defined projects in addition to the default platform monitoring. You can monitor your own projects in {ocp} without the need for an additional monitoring solution. - -Using this feature centralizes monitoring for core platform components and user-defined projects. +Enable monitoring for user-defined projects in addition to the default platform monitoring. Monitor your own projects without the need for an additional monitoring solution. Using this feature centralizes monitoring for core platform components and user-defined projects. include::snippets/monitoring-custom-prometheus-note.adoc[] diff --git a/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc b/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc index 093b3c649093..1bbe4ee7ac8e 100644 --- a/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc +++ b/modules/monitoring-enabling-query-logging-for-thanos-querier.adoc @@ -7,7 +7,7 @@ = 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. +Enable query logging for Thanos Querier to troubleshoot default platform monitoring performance issues. [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 c753449aeefd..f90f66373075 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 @@ -7,7 +7,7 @@ = Enabling the platform Alertmanager instance for user-defined alert routing [role="_abstract"] -Cluster administrators can allow users to create user-defined alert routing configurations that use the main platform instance of Alertmanager. +Cluster administrators can allow users to create user-defined alert routing configurations that use the main platform instance of Alertmanager to centralize alert management. .Prerequisites diff --git a/modules/monitoring-example-remote-write-authentication-settings.adoc b/modules/monitoring-example-remote-write-authentication-settings.adoc index 6b314fa907d3..b859749403f8 100644 --- a/modules/monitoring-example-remote-write-authentication-settings.adoc +++ b/modules/monitoring-example-remote-write-authentication-settings.adoc @@ -19,9 +19,9 @@ // end::UWM[] [role="_abstract"] -The following samples show different authentication settings you can use to connect to a remote write endpoint. +Learn about different authentication settings you can use to securely 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 +Each sample 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 // end::CPM[] diff --git a/modules/monitoring-example-remote-write-queue-configuration.adoc b/modules/monitoring-example-remote-write-queue-configuration.adoc index c8b08018a6ce..3bbc98638c36 100644 --- a/modules/monitoring-example-remote-write-queue-configuration.adoc +++ b/modules/monitoring-example-remote-write-queue-configuration.adoc @@ -19,7 +19,9 @@ // 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 +Optimize metrics delivery performance and reliability by tuning remote write queue parameters with the `queueConfig` object. + +The following example shows the queue parameters with their default values for // tag::CPM[] default platform monitoring // end::CPM[] 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 2164266e4e86..32d3f357dd35 100644 --- a/modules/monitoring-excluding-a-user-defined-project-from-monitoring.adoc +++ b/modules/monitoring-excluding-a-user-defined-project-from-monitoring.adoc @@ -8,7 +8,7 @@ = Excluding a user-defined project from monitoring [role="_abstract"] -Individual user-defined projects can be excluded from user workload monitoring. To do so, you can add the `openshift.io/user-monitoring` label to the project's namespace with a value of `false`. +Exclude individual user-defined projects from monitoring by adding the `openshift.io/user-monitoring=false` label to the project's namespace. For example, you can use this to exclude test environments, reduce monitoring overhead, or meet compliance requirements. .Procedure diff --git a/modules/monitoring-expiring-silences.adoc b/modules/monitoring-expiring-silences.adoc index 1df8b19ad5f9..51560e378555 100644 --- a/modules/monitoring-expiring-silences.adoc +++ b/modules/monitoring-expiring-silences.adoc @@ -7,7 +7,7 @@ = Expiring silences [role="_abstract"] -You can expire a single silence or multiple silences. Expiring a silence deactivates it permanently. +Expire a single silence or multiple silences to restore alert notifications. Expiring a silence deactivates it permanently. [NOTE] ==== 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 81f4bed2d23b..9cf8c53dd082 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 @@ -7,7 +7,7 @@ = 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. +Use the web console interface to get detailed information about alerts, silences, and alerting rules to manage your alerting configuration effectively and troubleshoot monitoring issues. .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 c5f177177d0d..04fd0398ae14 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 @@ -7,7 +7,7 @@ = Granting users permission to configure alert routing for user-defined projects [role="_abstract"] -Administrators can grant users permission to configure alert routing for user-defined projects. +Administrators can grant users permission to configure alert routing for user-defined projects. This enables developers and other users to configure notifications for their custom alerts in user-defined projects. .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 202be02423af..884cdc284c8a 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 @@ -7,9 +7,9 @@ = 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. +As a cluster administrator, you can monitor all core platform and user-defined projects. To delegate user workload monitoring capabilities to other users, assign different permission levels. -You can also grant developers and other users different permissions: +You can grant permissions for different monitoring activities: * Monitoring user-defined projects * Configuring the components that monitor user-defined projects 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 ca304d3a9b6a..5127907dc7c6 100644 --- a/modules/monitoring-granting-users-permissions-for-core-platform-monitoring.adoc +++ b/modules/monitoring-granting-users-permissions-for-core-platform-monitoring.adoc @@ -7,9 +7,9 @@ = Granting users permissions for core platform monitoring [role="_abstract"] -As a cluster administrator, you can monitor all core {ocp} and user-defined projects. +As a cluster administrator, you can monitor all core platform and user-defined projects. To delegate core platform monitoring capabilities to other users, assign different permission levels. -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: +You can grant the permissions by assigning one of the following monitoring roles or cluster roles: |=== |Name |Description |Project 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 24cd7fde00fd..001e2b7eb2d2 100644 --- a/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc +++ b/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc @@ -8,7 +8,7 @@ = 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. +Troubleshoot missing user-defined project metrics by diagnosing common `ServiceMonitor` configuration issues when you have created a `ServiceMonitor` resource but cannot see 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 889e7df4a931..451679f14a22 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 @@ -13,7 +13,7 @@ endif::openshift-dedicated,openshift-rosa[] ifdef::openshift-dedicated,openshift-rosa[] As a `dedicated-admin`, endif::openshift-dedicated,openshift-rosa[] -you can list alerting rules for core {ocp} and user-defined projects together in a single view. +list alerting rules for core platform and user-defined projects in a single view to get complete visibility into all cluster alerting rules. .Prerequisites diff --git a/modules/monitoring-managing-alerting-rules-for-core-platform-monitoring.adoc b/modules/monitoring-managing-alerting-rules-for-core-platform-monitoring.adoc index 6892f8a91e1c..da88ae045dca 100644 --- a/modules/monitoring-managing-alerting-rules-for-core-platform-monitoring.adoc +++ b/modules/monitoring-managing-alerting-rules-for-core-platform-monitoring.adoc @@ -7,8 +7,9 @@ = 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: +As a cluster administrator, customize default alerting rules for platform metrics to meet your specific monitoring needs and organizational requirements. + +The monitoring stack includes a large set of default platform alerting rules. You can customize this set of rules in two ways: * Modify the settings for existing platform alerting rules by adjusting thresholds or by adding and modifying labels. For example, you can change the `severity` label for an alert from `warning` to `critical` to help you route and triage issues flagged by an alert. 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 963153255ecb..6d8ddb8c8c37 100644 --- a/modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc +++ b/modules/monitoring-managing-alerting-rules-for-user-defined-projects.adoc @@ -8,7 +8,7 @@ = Managing alerting rules for user-defined projects [role="_abstract"] -In {ocp}, you can view, edit, and remove alerting rules in user-defined projects. +Create, view, edit, and remove alerting rules in user-defined projects to create custom alerting that meets your application-specific conditions. ifdef::openshift-rosa,openshift-dedicated[] [IMPORTANT] diff --git a/modules/monitoring-managing-core-platform-alerting-rules.adoc b/modules/monitoring-managing-core-platform-alerting-rules.adoc index f2d2c2c0e54e..6fe46e9935fe 100644 --- a/modules/monitoring-managing-core-platform-alerting-rules.adoc +++ b/modules/monitoring-managing-core-platform-alerting-rules.adoc @@ -7,8 +7,9 @@ = 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: +As a cluster administrator, customize default alerting rules for platform metrics to meet your specific monitoring needs and organizational requirements. + +The monitoring stack includes a large set of default platform alerting rules. You can customize this set of rules in two ways: * Modify the settings for existing platform alerting rules by adjusting thresholds or by adding and modifying labels. For example, you can change the `severity` label for an alert from `warning` to `critical` to help you route and triage issues flagged by an alert. diff --git a/modules/monitoring-managing-cpu-and-memory-resources-for-monitoring-components.adoc b/modules/monitoring-managing-cpu-and-memory-resources-for-monitoring-components.adoc index 72dbce1a41e1..d47671d1d210 100644 --- a/modules/monitoring-managing-cpu-and-memory-resources-for-monitoring-components.adoc +++ b/modules/monitoring-managing-cpu-and-memory-resources-for-monitoring-components.adoc @@ -8,12 +8,13 @@ = Managing CPU and memory resources for monitoring components [role="_abstract"] -You can ensure that the containers that run monitoring components have enough CPU and memory resources by specifying values for resource limits and requests for those components. +Ensure that the containers that run monitoring components have enough CPU and memory resources by specifying values for resource limits and requests for those components. // tag::CPM[] -You can configure these limits and requests for core platform monitoring components in the `openshift-monitoring` namespace. +Configure these limits and requests for core platform monitoring components in the `openshift-monitoring` namespace. // end::CPM[] // tag::UWM[] -You can configure these limits and requests for monitoring components that monitor user-defined projects in the `openshift-user-workload-monitoring` namespace. +Configure these limits and requests for monitoring components that monitor user-defined projects in the `openshift-user-workload-monitoring` namespace. // end::UWM[] + diff --git a/modules/monitoring-managing-silences.adoc b/modules/monitoring-managing-silences.adoc index 5143d90e5698..b282251c03ab 100644 --- a/modules/monitoring-managing-silences.adoc +++ b/modules/monitoring-managing-silences.adoc @@ -7,8 +7,8 @@ = 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. +Create a silence for an alert in the {ocp} web console. +After you create a silence, you do not receive notifications about an alert when the alert fires. Creating silences is useful in scenarios where you have received an initial alert notification, and you do not want to receive further notifications during the time in which you resolve the underlying issue causing the alert to fire. diff --git a/modules/monitoring-managing-uwm-alerting-rules.adoc b/modules/monitoring-managing-uwm-alerting-rules.adoc index 5ff870c8c8fd..dea577a85846 100644 --- a/modules/monitoring-managing-uwm-alerting-rules.adoc +++ b/modules/monitoring-managing-uwm-alerting-rules.adoc @@ -8,4 +8,4 @@ = Managing alerting rules for user-defined projects [role="_abstract"] -In {ocp}, you can create, view, edit, and remove alerting rules for user-defined projects. Those alerting rules will trigger alerts based on the values of the chosen metrics. +Create, view, edit, and remove alerting rules for user-defined projects to create custom alerting that meets your application-specific conditions. Those alerting rules trigger alerts based on the values of the chosen metrics. diff --git a/modules/monitoring-modifying-core-platform-alerting-rules.adoc b/modules/monitoring-modifying-core-platform-alerting-rules.adoc index 5d2a3ef1855f..d318bb1aea6e 100644 --- a/modules/monitoring-modifying-core-platform-alerting-rules.adoc +++ b/modules/monitoring-modifying-core-platform-alerting-rules.adoc @@ -7,8 +7,7 @@ = 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. +As a cluster administrator, modify core platform alerts before Alertmanager routes them to a receiver to customize alerting behavior for your environment. For example, you can change the severity label of an alert, add a custom label, or exclude an alert from being sent to Alertmanager. .Prerequisites 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 d1818ecfb69a..2197062ca335 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 @@ -20,6 +20,8 @@ // end::UWM[] [role="_abstract"] +Modify the retention time for the Prometheus instance to change when the data is deleted. You can also set the maximum amount of disk space the retained metrics data uses. This ensures you maintain necessary metrics while preventing excessive disk space usage. + By default, Prometheus retains metrics data for // tag::CPM[] 15 days for core platform monitoring. @@ -30,7 +32,6 @@ endif::openshift-dedicated,openshift-rosa[] // tag::UWM[] 24 hours for monitoring for user-defined projects. // end::UWM[] -You can modify the retention time for the Prometheus instance to change when the data is deleted. You can also set the maximum amount of disk space the retained metrics data uses. [NOTE] ==== 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 72e0d364bd33..22b67eec2618 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 @@ -7,7 +7,7 @@ = 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 editing the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` project. +By default, Thanos Ruler retains metrics data for 24 hours for user-defined projects. Modify the retention time to change how long this data is retained by editing the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` project. [NOTE] ==== diff --git a/modules/monitoring-monitoring-stack-in-ha-clusters.adoc b/modules/monitoring-monitoring-stack-in-ha-clusters.adoc index 643272b72f8f..9e91d54e78b5 100644 --- a/modules/monitoring-monitoring-stack-in-ha-clusters.adoc +++ b/modules/monitoring-monitoring-stack-in-ha-clusters.adoc @@ -7,7 +7,9 @@ = 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: +By default, multi-node clusters run key monitoring components in high-availability (HA) mode to prevent data loss and service interruption. + +The following components run in HA mode: * Prometheus * Alertmanager diff --git a/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc b/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc index 07943254f4b2..b91d62fcd0cd 100644 --- a/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc +++ b/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc @@ -18,7 +18,7 @@ [role="_abstract"] ifndef::openshift-dedicated,openshift-rosa[] -To specify the nodes in your cluster on which monitoring stack components will run, configure the `nodeSelector` constraint for the components in the `{configmap-name}` config map to match labels assigned to the nodes. +Move monitoring stack components to specific nodes to optimize performance or meet hardware requirements, by configuring `nodeSelector` constraints in the `{configmap-name}` config map to match labels assigned to the nodes. [NOTE] ==== 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 0b44319129de..79b3455560cc 100644 --- a/modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc +++ b/modules/monitoring-removing-alerting-rules-for-user-defined-projects.adoc @@ -7,7 +7,7 @@ = Removing alerting rules for user-defined projects [role="_abstract"] -You can remove alerting rules for user-defined projects. +Remove alerting rules for user-defined projects to delete outdated alerts, reduce notification noise, or update your monitoring configuration. .Prerequisites diff --git a/modules/monitoring-resizing-a-persistent-volume.adoc b/modules/monitoring-resizing-a-persistent-volume.adoc index 38a6a68faa83..1b39d25e99dd 100644 --- a/modules/monitoring-resizing-a-persistent-volume.adoc +++ b/modules/monitoring-resizing-a-persistent-volume.adoc @@ -21,10 +21,10 @@ [role="_abstract"] // tag::CPM[] -You can resize a persistent volume (PV) for monitoring components, such as Prometheus or Alertmanager. +Resize a persistent volume (PV) for monitoring components, such as Prometheus or Alertmanager to meet your capacity requirements. // end::CPM[] // tag::UWM[] -You can resize a persistent volume (PV) for the instances of Prometheus, Thanos Ruler, and Alertmanager. +You can resize a persistent volume (PV) for the instances of Prometheus, Thanos Ruler, and Alertmanager to meet your capacity requirements. // end::UWM[] You need to manually expand a persistent volume claim (PVC), and then update the config map in which the component is configured. 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 675833ec6e79..723caa20c623 100644 --- a/modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc +++ b/modules/monitoring-resolving-the-kubepersistentvolumefillingup-alert-firing-for-prometheus.adoc @@ -8,9 +8,8 @@ = 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. +Resolve the `KubePersistentVolumeFillingUp` alert being triggered for Prometheus. The critical alert fires when persistent volumes claimed by `prometheus-k8s-*` pods in the `openshift-monitoring` project have less than 3% total space remaining. This can cause Prometheus to function abnormally. [NOTE] ==== 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 9a3a679a07a1..0a97612213fd 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 @@ -7,6 +7,8 @@ = Retention time and size for Prometheus metrics [role="_abstract"] +Modify the retention time for Prometheus to change when the data is deleted. You can also set the maximum amount of disk space the retained metrics data uses. If the data reaches this size limit, Prometheus deletes the oldest data first until the disk space used is again below the limit. + By default, Prometheus retains metrics data for the following durations: * *Core platform monitoring*: 15 days @@ -15,9 +17,7 @@ ifdef::openshift-dedicated,openshift-rosa[] endif::openshift-dedicated,openshift-rosa[] * *Monitoring for user-defined projects*: 24 hours -You can modify the retention time for the Prometheus instance to change how soon the data is deleted. You can also set the maximum amount of disk space the retained metrics data uses. If the data reaches this size limit, Prometheus deletes the oldest data first until the disk space used is again below the limit. - -Note the following behaviors of these data retention settings: +Note the following behaviors of data retention settings: * The size-based retention policy applies to all data block directories in the `/prometheus` directory, including persistent blocks, write-ahead log (WAL) data, and m-mapped chunks. * Data in the `/wal` and `/head_chunks` directories counts toward the retention size limit, but Prometheus never purges data from these directories based on size- or time-based retention policies. diff --git a/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc b/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc index e0e75ab1d06b..76afbdfddd5b 100644 --- a/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc +++ b/modules/monitoring-reviewing-monitoring-dashboards-admin.adoc @@ -7,7 +7,7 @@ = Reviewing monitoring dashboards as a cluster administrator [role="_abstract"] -As an administrator, you can view dashboards relating to core {ocp} cluster components. +As an administrator, review monitoring dashboards to gain insights into cluster operations by visualizing key infrastructure metrics and component status. 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 095bb240375d..e49f08072d0b 100644 --- a/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc +++ b/modules/monitoring-reviewing-monitoring-dashboards-developer.adoc @@ -7,7 +7,7 @@ = Reviewing monitoring dashboards as a developer [role="_abstract"] -As a developer, you can view dashboards relating to projects you have permissions for. +As a developer, review project dashboards to gain insights into your applications by visualizing key metrics and resource data for 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 355b0f7928ec..2633e521a411 100644 --- a/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc +++ b/modules/monitoring-searching-alerts-silences-and-alerting-rules.adoc @@ -7,7 +7,9 @@ = 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. The following lists provide a description of each of the available filtering options. +Filter alerts, silences, and alerting rules in the Alerting UI to quickly find relevant items and focus on specific monitoring criteria that matter to your role. + +The following lists provide a description of each of the available filtering options. [id="understanding-alert-filters_{context}"] == Understanding alert filters diff --git a/modules/monitoring-sending-notifications-to-external-systems.adoc b/modules/monitoring-sending-notifications-to-external-systems.adoc index 5b1c92091a1e..943856489e75 100644 --- a/modules/monitoring-sending-notifications-to-external-systems.adoc +++ b/modules/monitoring-sending-notifications-to-external-systems.adoc @@ -8,7 +8,9 @@ = 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: +Configure alert routing to notification systems to ensure critical issues reach the appropriate teams promptly, enabling faster incident response and reducing system downtime. + +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 alert routing to the following receiver types: * PagerDuty * Webhook @@ -16,7 +18,7 @@ In {ocp} {product-version}, firing alerts can be viewed in the Alerting UI. Aler * Slack * Microsoft Teams -Routing alerts to receivers enables you to send timely notifications to the appropriate teams when failures occur. For example, critical alerts require immediate attention and are typically paged to an individual or a critical response team. Alerts that provide non-critical warning notifications might instead be routed to a ticketing system for non-immediate review. +Critical alerts require immediate attention and are typically paged to an individual or a critical response team, while non-critical warnings might instead be routed to a ticketing system for non-immediate review. *_Checking that alerting is operational by using the watchdog alert_* diff --git a/modules/monitoring-setting-query-log-file-for-prometheus.adoc b/modules/monitoring-setting-query-log-file-for-prometheus.adoc index 8936aef19366..cf71243e551e 100644 --- a/modules/monitoring-setting-query-log-file-for-prometheus.adoc +++ b/modules/monitoring-setting-query-log-file-for-prometheus.adoc @@ -22,7 +22,7 @@ // end::UWM[] [role="_abstract"] -You can configure Prometheus to write all queries that have been run by the engine to a log file. +Configure Prometheus to write all queries that have been run by the engine to a log file for detailed analysis. [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 abba9309eaa5..1332b083c889 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 @@ -7,14 +7,14 @@ = Setting scrape intervals, evaluation intervals, and enforced limits for user-defined projects [role="_abstract"] +Configure intervals between consecutive scrapes, intervals between Prometheus rule evaluations, and enforced limits for user-defined projects to control resource usage and optimize monitoring performance. + 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 * Limit the number of scraped labels * Limit the length of label names and label values -You can also set an interval between consecutive scrapes and between Prometheus rule evaluations. - [WARNING] ==== If you set sample or label limits, no further sample data is ingested for that target scrape after the limit is reached. 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 315d677b48c5..f6995d38d3e6 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 @@ -7,6 +7,9 @@ = 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. +Set up metrics collection for user-defined projects to monitor application performance and health by creating a `ServiceMonitor` resource that scrapes metrics from your service endpoints. + +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 ea64bb4485f2..19ebdd8373d4 100644 --- a/modules/monitoring-silencing-alerts.adoc +++ b/modules/monitoring-silencing-alerts.adoc @@ -7,7 +7,7 @@ = Silencing alerts [role="_abstract"] -You can silence a specific alert or silence alerts that match a specification that you define. +Silence a specific alert or silence alerts that match a specification that you define to prevent notification fatigue during maintenance or known issues. .Prerequisites diff --git a/modules/monitoring-specifying-how-a-service-is-monitored.adoc b/modules/monitoring-specifying-how-a-service-is-monitored.adoc index df9fd0c34489..0e39f61b0d1c 100644 --- a/modules/monitoring-specifying-how-a-service-is-monitored.adoc +++ b/modules/monitoring-specifying-how-a-service-is-monitored.adoc @@ -7,11 +7,11 @@ = 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. +To monitor your custom application performance and health, configure the monitoring stack to scrape metrics from the `/metrics` endpoint. You can do this by using a `ServiceMonitor` custom resource definition (CRD) that specifies how a service should be monitored, or a `PodMonitor` CRD for pods. -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. +The `ServiceMonitor` CRD requires a `Service` object, while the `PodMonitor` CRD 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. +The following example procedure shows you how to create a `ServiceMonitor` resource for a service in a user-defined project. .Prerequisites 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 f2f2f505052e..7d96e3330982 100644 --- a/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc +++ b/modules/monitoring-specifying-limits-and-requests-for-monitoring-components.adoc @@ -23,7 +23,7 @@ // 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. +Prevent resource exhaustion and ensure stable monitoring operations by setting appropriate CPU and memory limits for each monitoring component in the `{configmap-name}` config map in the `{namespace-name}` namespace. .Prerequisites diff --git a/modules/monitoring-support-policy-for-monitoring-operators.adoc b/modules/monitoring-support-policy-for-monitoring-operators.adoc index 60e9fd2be190..5e42f8bc7ce5 100644 --- a/modules/monitoring-support-policy-for-monitoring-operators.adoc +++ b/modules/monitoring-support-policy-for-monitoring-operators.adoc @@ -7,6 +7,8 @@ = Support policy for monitoring Operators [role="_abstract"] +Learn when monitoring Operator modifications affect Red{nbsp}Hat support eligibility and cluster reliability. This policy guidance helps you balance debugging flexibility with maintained support coverage. + Monitoring Operators ensure that the 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. The cluster administrator assumes full control of the individual component configurations and upgrades. diff --git a/modules/monitoring-supported-remote-write-authentication-settings.adoc b/modules/monitoring-supported-remote-write-authentication-settings.adoc index 534f7a255eb7..11da9b271393 100644 --- a/modules/monitoring-supported-remote-write-authentication-settings.adoc +++ b/modules/monitoring-supported-remote-write-authentication-settings.adoc @@ -7,7 +7,9 @@ = 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: +Use different methods to securely authenticate with a remote write endpoint. + +The following authentication methods are supported: * AWS Signature Version 4 * Basic authentication diff --git a/modules/monitoring-targets-for-user-defined-projects.adoc b/modules/monitoring-targets-for-user-defined-projects.adoc index 8fd883284641..28fbf711b4bc 100644 --- a/modules/monitoring-targets-for-user-defined-projects.adoc +++ b/modules/monitoring-targets-for-user-defined-projects.adoc @@ -7,6 +7,8 @@ = Monitoring targets for user-defined projects [role="_abstract"] +Review available monitoring targets for user-defined projects to understand what metrics and workloads you can track beyond the default cluster monitoring. + 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-for-user-defined-projects.adoc b/modules/monitoring-tips-for-optimizing-alerting-for-user-defined-projects.adoc index 89b3bfe0670d..8c624ac5340e 100644 --- a/modules/monitoring-tips-for-optimizing-alerting-for-user-defined-projects.adoc +++ b/modules/monitoring-tips-for-optimizing-alerting-for-user-defined-projects.adoc @@ -7,7 +7,7 @@ = Tips for 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: +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-tips-for-optimizing-alerting-rules-for-core-platform-monitoring.adoc b/modules/monitoring-tips-for-optimizing-alerting-rules-for-core-platform-monitoring.adoc index 83d8481084a6..e9ad3b6f30fd 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 @@ -7,7 +7,7 @@ = 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. +If you customize core platform alerting rules to meet your organization's specific needs, consider the following guidelines to ensure that the custom rules are efficient and effective. * *Minimize the number of new rules*. Create only rules that are essential to your specific requirements. diff --git a/modules/monitoring-understanding-the-monitoring-stack.adoc b/modules/monitoring-understanding-the-monitoring-stack.adoc index 142083e6dfc7..af9027dd2fce 100644 --- a/modules/monitoring-understanding-the-monitoring-stack.adoc +++ b/modules/monitoring-understanding-the-monitoring-stack.adoc @@ -8,6 +8,8 @@ = Understanding the monitoring stack [role="_abstract"] +Understand how the monitoring stack architecture separates platform and user workload monitoring to effectively troubleshoot issues and configure monitoring settings. + 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 81f6c2b78bd8..833677127d85 100644 --- a/modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc +++ b/modules/monitoring-using-node-selectors-to-move-monitoring-components.adoc @@ -7,10 +7,7 @@ = 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. - -By controlling placement and distribution of monitoring components, you can optimize system resource use, improve performance, and separate workloads based on specific requirements or policies. +Use `nodeSelector` constraints with labeled nodes to move monitoring components to specific nodes and therefore control their placement and distribution across a cluster. This optimizes system resource use, improves performance, and separates workloads based on specific requirements or policies. == How node selectors work with other constraints diff --git a/modules/monitoring-viewing-a-list-of-available-metrics.adoc b/modules/monitoring-viewing-a-list-of-available-metrics.adoc index b066f4eaf133..cad891f22d05 100644 --- a/modules/monitoring-viewing-a-list-of-available-metrics.adoc +++ b/modules/monitoring-viewing-a-list-of-available-metrics.adoc @@ -7,7 +7,7 @@ = 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. +As a cluster administrator or as a user with view permissions for all projects, view a list of metrics to understand what metrics are available in a cluster, and output the list in JSON format for easier processing of the metrics data. .Prerequisites * You are a cluster administrator, or you have access to the cluster as a user with the `cluster-monitoring-view` cluster role.