OSDOCS-3797: Apply changes from 4.13

Author: bhardesty

_topic_maps/_topic_map.yml

@@ -2598,10 +2598,6 @@ Topics:
   File: enabling-alert-routing-for-user-defined-projects
 - Name: Managing metrics
   File: managing-metrics
-- Name: Querying metrics
-  File: querying-metrics
-- Name: Managing metrics targets
-  File: managing-metrics-targets
 - Name: Managing alerts
   File: managing-alerts
 - Name: Reviewing monitoring dashboards

_topic_maps/_topic_map_osd.yml

@@ -352,26 +352,32 @@ Topics:
 - Name: Exported fields
   File: cluster-logging-exported-fields
 ---
-Name: Monitoring user-defined projects
+Name: Monitoring
 Dir: monitoring
 Distros: openshift-dedicated
 Topics:
-- Name: Understanding the monitoring stack
-  File: osd-understanding-the-monitoring-stack
+- Name: Monitoring overview
+  File: monitoring-overview
 - Name: Accessing monitoring for user-defined projects
-  File: osd-accessing-monitoring-for-user-defined-projects
+  File: sd-accessing-monitoring-for-user-defined-projects
 - Name: Configuring the monitoring stack
-  File: osd-configuring-the-monitoring-stack
+  File: configuring-the-monitoring-stack
+- Name: Disabling monitoring for user-defined projects
+  File: sd-disabling-monitoring-for-user-defined-projects  
 - Name: Enabling alert routing for user-defined projects
-  File: osd-enabling-alert-routing-for-user-defined-projects
+  File: enabling-alert-routing-for-user-defined-projects
 - Name: Managing metrics
-  File: osd-managing-metrics
+  File: managing-metrics
 - Name: Managing alerts
   File: managing-alerts
 - Name: Reviewing monitoring dashboards
-  File: osd-reviewing-monitoring-dashboards
+  File: reviewing-monitoring-dashboards
+- Name: Accessing third-party monitoring APIs
+  File: accessing-third-party-monitoring-apis
 - Name: Troubleshooting monitoring issues
-  File: osd-troubleshooting-monitoring-issues
+  File: troubleshooting-monitoring-issues
+- Name: Config map reference for the Cluster Monitoring Operator
+  File: config-map-reference-for-the-cluster-monitoring-operator
 ---
 Name: Serverless
 Dir: serverless

_topic_maps/_topic_map_rosa.yml

@@ -468,26 +468,32 @@ Topics:
 - Name: Exported fields
   File: cluster-logging-exported-fields
 ---
-Name: Monitoring user-defined projects
+Name: Monitoring
 Dir: monitoring
 Distros: openshift-rosa
 Topics:
-- Name: Understanding the monitoring stack
-  File: rosa-understanding-the-monitoring-stack
+- Name: Monitoring overview
+  File: monitoring-overview
 - Name: Accessing monitoring for user-defined projects
-  File: rosa-accessing-monitoring-for-user-defined-projects
+  File: sd-accessing-monitoring-for-user-defined-projects
 - Name: Configuring the monitoring stack
-  File: rosa-configuring-the-monitoring-stack
+  File: configuring-the-monitoring-stack
+- Name: Disabling monitoring for user-defined projects
+  File: sd-disabling-monitoring-for-user-defined-projects
 - Name: Enabling alert routing for user-defined projects
-  File: rosa-enabling-alert-routing-for-user-defined-projects
+  File: enabling-alert-routing-for-user-defined-projects
 - Name: Managing metrics
-  File: rosa-managing-metrics
+  File: managing-metrics
 - Name: Managing alerts
   File: managing-alerts
 - Name: Reviewing monitoring dashboards
-  File: rosa-reviewing-monitoring-dashboards
+  File: reviewing-monitoring-dashboards
+- Name: Accessing third-party monitoring APIs
+  File: accessing-third-party-monitoring-apis
 - Name: Troubleshooting monitoring issues
-  File: rosa-troubleshooting-monitoring-issues
+  File: troubleshooting-monitoring-issues
+- Name: Config map reference for the Cluster Monitoring Operator
+  File: config-map-reference-for-the-cluster-monitoring-operator
 ---
 Name: Service Mesh
 Dir: service_mesh

modules/monitoring-about-querying-metrics.adoc

@@ -1,14 +1,19 @@
 // Module included in the following assemblies:
 //
-// * monitoring/querying-metrics.adoc
+// * monitoring/managing-metrics.adoc
 // * virt/support/virt-prometheus-queries.adoc
 
 :_content-type: CONCEPT
 [id="about-querying-metrics_{context}"]
-= About querying metrics
+= Querying metrics
 
 The {product-title} monitoring dashboard enables you to run Prometheus Query Language (PromQL) queries to examine metrics visualized on a plot. This functionality provides information about the state of a cluster and any user-defined workloads that you are monitoring.
 
-As a *cluster administrator*, you can query metrics for all core {product-title} and user-defined projects.
+ifndef::openshift-dedicated,openshift-rosa[]
+As a cluster administrator, you can query metrics for all core {product-title} and user-defined projects.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+As a `dedicated-admin`, you can query one or more namespaces at a time for metrics about user-defined projects.
+endif::openshift-dedicated,openshift-rosa[]
 
-As a *developer*, you must specify a project name when querying metrics. You must have the required privileges to view metrics for the selected project.
+As a developer, you must specify a project name when querying metrics. You must have the required privileges to view metrics for the selected project.

modules/monitoring-accessing-alerting-rules-for-your-project.adoc

@@ -16,7 +16,7 @@ To list alerting rules for a user-defined project, you must have been assigned t
 
 .Procedure
 
-. You can list alerting rules in `<project>`:
+. To list alerting rules in `<project>`:
 +
 [source,terminal]
 ----

modules/monitoring-accessing-the-alerting-ui.adoc

@@ -16,5 +16,5 @@ The Alerting UI is accessible through the Administrator perspective and the Deve
 
 [NOTE]
 ====
-In the Developer perspective, you can select from core {product-title} and user-defined projects that you have access to in the *Project:* list. However, alerts, silences, and alerting rules relating to core {product-title} projects are not displayed if you do not have `cluster-admin` privileges.
+In the *Developer* perspective, you can select from core {product-title} and user-defined projects that you have access to in the *Project:* list. However, alerts, silences, and alerting rules relating to core {product-title} projects are not displayed if you are not logged in as a cluster administrator.
 ====

modules/monitoring-accessing-the-metrics-targets-page.adoc

@@ -6,14 +6,18 @@
 [id="monitoring-adding-a-secret-to-the-alertmanager-configuration_{context}"]
 = Adding a secret to the Alertmanager configuration
 
+ifndef::openshift-dedicated,openshift-rosa[]
 You can add secrets to the Alertmanager configuration for core platform monitoring components by editing the `cluster-monitoring-config` config map in the `openshift-monitoring` project.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
 You can add secrets to the Alertmanager configuration for user-defined projects by editing the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` project.
+endif::openshift-dedicated,openshift-rosa[]
 
 After you add a secret to the config map, the secret is mounted as a volume at `/etc/alertmanager/secrets/<secret_name>` within the `alertmanager` container for the Alertmanager pods.
 
 .Prerequisites
 
-* You have installed the OpenShift CLI (`oc`).
+ifndef::openshift-dedicated,openshift-rosa[]
 * *If you are configuring core {product-title} monitoring components in the `openshift-monitoring` project*:
 ** You have access to the cluster as a user with the `cluster-admin` role.
 ** You have created the `cluster-monitoring-config` config map.
@@ -22,19 +26,27 @@ After you add a secret to the config map, the secret is mounted as a volume at `
 ** A cluster administrator has enabled monitoring for user-defined projects.
 ** You have access to the cluster as a user with the `cluster-admin` role, or as a user with the `user-workload-monitoring-config-edit` role in the `openshift-user-workload-monitoring` project.
 ** You have created the secret to be configured in Alertmanager in the `openshift-user-workload-monitoring` project.
+endif::openshift-dedicated,openshift-rosa[]
+ifdef::openshift-dedicated,openshift-rosa[]
+* You have access to the cluster as a user with the `dedicated-admin` role.
+* The `user-workload-monitoring-config` `ConfigMap` object exists. This object is created by default when the cluster is created.
+* You have created the secret to be configured in Alertmanager in the `openshift-user-workload-monitoring` project.
+endif::openshift-dedicated,openshift-rosa[]
+* You have installed the OpenShift CLI (`oc`).
 
 .Procedure
 
-. To add a secret configuration to Alertmanager for core platform monitoring, edit the `cluster-monitoring-config` config map in the `openshift-monitoring` project:
+. Edit the `ConfigMap` object.
+ifndef::openshift-dedicated,openshift-rosa[]
+** *To add a secret configuration to Alertmanager for core platform monitoring*:
+.. Edit the `cluster-monitoring-config` config map in the `openshift-monitoring` project:
 +
 [source,terminal]
 ----
 $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
 ----
 
-. Add a `secrets:` section under `data/config.yaml/alertmanagerMain`.
-
-. Add the configuration details for the secret in this section:
+.. Add a `secrets:` section under `data/config.yaml/alertmanagerMain` with the following configuration:
 +
 [source,yaml]
 ----
@@ -50,10 +62,8 @@ data:
       - <secret_name_1> <2>
       - <secret_name_2>
 ----
-<1> This section contains the secrets to be mounted into Alertmanager.
-The secrets must be located within the same namespace as the Alertmanager object.
-<2> The name of the `Secret` object that contains authentication credentials for the receiver.
-If you add multiple secrets, place each one on a new line.
+<1> This section contains the secrets to be mounted into Alertmanager. The secrets must be located within the same namespace as the Alertmanager object.
+<2> The name of the `Secret` object that contains authentication credentials for the receiver. If you add multiple secrets, place each one on a new line.
 +
 The following sample config map settings configure Alertmanager to use two `Secret` objects named `test-secret-basic-auth` and `test-secret-api-token`:
 +
@@ -72,7 +82,36 @@ data:
       - test-secret-api-token
 ----
 
-. Optional: To add the secrets for use by Alertmanager in user-defined projects, add the secret names under `data/config.yaml/alertmanager/secrets` in the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` project:
+** *To add a secret configuration to Alertmanager for user-defined project monitoring*:
+endif::openshift-dedicated,openshift-rosa[]
+
+.. Edit the `user-workload-monitoring-config` config map in the `openshift-user-workload-monitoring` project:
++
+[source,terminal]
+----
+$ oc -n openshift-user-workload-monitoring edit configmap user-workload-monitoring-config
+----
+
+.. Add a `secrets:` section under `data/config.yaml/alertmanager/secrets` with the following configuration:
++
+[source,yaml]
+----
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: user-workload-monitoring-config
+  namespace: openshift-user-workload-monitoring
+data:
+  config.yaml: |
+    alertmanager:
+      secrets: <1>
+      - <secret_name_1> <2>
+      - <secret_name_2>
+----
+<1> This section contains the secrets to be mounted into Alertmanager. The secrets must be located within the same namespace as the Alertmanager object.
+<2> The name of the `Secret` object that contains authentication credentials for the receiver. If you add multiple secrets, place each one on a new line.
++
+The following sample config map settings configure Alertmanager to use two `Secret` objects named `test-secret` and `test-secret-api-token`:
 +
 [source,yaml]
 ----
@@ -89,12 +128,13 @@ data:
       - test-secret
       - test-api-receiver-token
 ----
+ifndef::openshift-dedicated,openshift-rosa[]
 +
 [NOTE]
 ====
 Configurations applied to the `user-workload-monitoring-config` `ConfigMap` object are not activated unless a cluster administrator has enabled monitoring for user-defined projects.
 ====
+endif::openshift-dedicated,openshift-rosa[]
 
-. Save the file to apply the changes to the `ConfigMap` object. 
-The new configuration is applied automatically.
+. Save the file to apply the changes to the `ConfigMap` object. The new configuration is applied automatically.
 

modules/monitoring-adding-a-secret-to-the-alertmanager-configuration.adoc

@@ -6,8 +6,7 @@
 [id="adding-cluster-id-labels-to-metrics_{context}"]
 = Adding cluster ID labels to metrics
 
-If you manage multiple {product-title} clusters and use the remote write feature to send metrics data from these clusters to an external storage location, you can add cluster ID labels to identify the metrics data coming from different clusters. 
-You can then query these labels to identify the source cluster for a metric and distinguish that data from similar metrics data sent by other clusters.
+If you manage multiple {product-title} clusters and use the remote write feature to send metrics data from these clusters to an external storage location, you can add cluster ID labels to identify the metrics data coming from different clusters. You can then query these labels to identify the source cluster for a metric and distinguish that data from similar metrics data sent by other clusters.
 
 This way, if you manage many clusters for multiple customers and send metrics data to a single centralized storage system, you can use cluster ID labels to query metrics for a particular cluster or customer.
 

modules/monitoring-adding-cluster-id-labels-to-metrics.adoc

@@ -11,11 +11,12 @@ If you have enabled a separate instance of Alertmanager dedicated to user-define
 .Prerequisites
 
 ifdef::openshift-rosa,openshift-dedicated[]
-* You have access to the cluster as a user with the `cluster-admin` or `dedicated-admin` role.
+* You have access to the cluster as a user with the `dedicated-admin` role.
 endif::[]
 ifndef::openshift-rosa,openshift-dedicated[]
 * You have access to the cluster as a user with the `cluster-admin` role.
 endif::[]
+* You have installed the OpenShift CLI (`oc`).
 
 .Procedure