openshift · jboxman · Oct 14, 2019 · Oct 1, 2019
diff --git a/.../monitoring-accessing-prometheus-alerting-ui-grafana-using-the-web-console.adoc b/.../monitoring-accessing-prometheus-alerting-ui-grafana-using-the-web-console.adoc
@@ -5,7 +5,7 @@
 [id="monitoring-accessing-prometheus-alerting-ui-grafana-using-the-web-console_{context}"]
 = Accessing Prometheus, Alerting UI, and Grafana using the web console
 
-You can access Prometheus, Alerting UI, and Grafana web UIs using a web browser through the {product-title} web console.
+You can access Prometheus, Alerting, and Grafana web UIs using a web browser through the {product-title} web console.
 
 [NOTE]
 ====

diff --git a/modules/monitoring-accessing-prometheus-alertmanager-grafana-directly.adoc b/modules/monitoring-accessing-prometheus-alertmanager-grafana-directly.adoc
@@ -20,7 +20,6 @@ The Alertmanager UI accessed in this procedure is the old interface for Alertman
 
 . Run:
 +
-[subs=quotes]
 ----
 $ oc -n openshift-monitoring get routes
 NAME                HOST/PORT                                                     ...
@@ -33,7 +32,6 @@ prometheus-k8s      prometheus-k8s-openshift-monitoring.apps._url_.openshift.com
 +
 For example, this is the resulting URL for Alertmanager:
 +
-[subs=quotes]
 ----
 https://alertmanager-main-openshift-monitoring.apps._url_.openshift.com
 ----

diff --git a/modules/monitoring-applying-custom-alertmanager-configuration.adoc b/modules/monitoring-applying-custom-alertmanager-configuration.adoc
@@ -38,19 +38,19 @@ data:
       repeat_interval: 5m
       receiver: watchdog
     - match:
-        service: _your service_ <1>
+        service: <your_service> <1>
       routes:
       - match:
-          _your matching rules_ <2>
-        receiver: _receiver_ <3>
+          <your_matching_rules> <2>
+        receiver: <receiver> <3>
   receivers:
   - name: default
   - name: watchdog
-  - name: _receiver_
-    _receiver configuration_
+  - name: <receiver>
+    <receiver_configuration>
 ----
 <1> `service` specifies the service that fires the alerts.
-<2> `<your matching rules>` specify the target alerts.
+<2> `<your_matching_rules>` specify the target alerts.
 <3> `receiver` specifies the receiver to use for the alert.
 +
 For example, this listing configures PagerDuty for notifications:

diff --git a/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc b/modules/monitoring-assigning-tolerations-to-monitoring-components.adoc
@@ -21,7 +21,7 @@ $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
 
 . Specify `tolerations` for the component:
 +
-[source,yaml,subs=quotes]
+[source,yaml]
 ----
 apiVersion: v1
 kind: ConfigMap
@@ -30,14 +30,14 @@ metadata:
   namespace: openshift-monitoring
 data:
   config.yaml: |
-    *_component_*:
+    <component>:
       tolerations:
-        *_tolerations specification_*
+        <toleration_specification>
 ----
 +
-Substitute `<component>` and `<toleration specification>` accordingly.
+Substitute `<component>` and `<toleration_specification>` accordingly.
 +
-For example, a `kubectl taint nodes node1 key1=value1:NoSchedule` taint prevents the scheduler from placing pods in `foo: bar`. To make the `alertmanagerMain` component ignore that taint and to place `alertmanagerMain` in `foo: bar` normally, use this toleration:
+For example, a `oc adm taint nodes node1 key1=value1:NoSchedule` taint prevents the scheduler from placing pods in the `foo: bar` node. To make the `alertmanagerMain` component ignore that taint and to place `alertmanagerMain` in `foo: bar` normally, use this toleration:
 +
 [source,yaml,subs=quotes]
 ----

diff --git a/modules/monitoring-configuring-a-local-persistent-volume-claim.adoc b/modules/monitoring-configuring-a-local-persistent-volume-claim.adoc
@@ -21,7 +21,7 @@ $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
 
 . Put your PVC configuration for the component under `data/config.yaml`:
 +
-[source,yaml,subs=quotes]
+[source,yaml]
 ----
 apiVersion: v1
 kind: ConfigMap
@@ -30,15 +30,15 @@ metadata:
   namespace: openshift-monitoring
 data:
   config.yaml: |
-    *_component_*:
+    <component>:
       volumeClaimTemplate:
         metadata:
-          name: *_PVC name_*
+          name: <PVC_name_prefix>
         spec:
-          storageClassName: *_storage class_*
+          storageClassName: <storage_class>
           resources:
             requests:
-              storage: *_amount of storage_*
+              storage: <amount_of_storage>
 ----
 +
 See the link:https://kubernetes.io/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims[Kubernetes documentation on PersistentVolumeClaims] for information on how to specify `volumeClaimTemplate`.

diff --git a/modules/monitoring-configuring-cluster-for-application-monitoring.adoc b/modules/monitoring-configuring-cluster-for-application-monitoring.adoc
@@ -15,4 +15,4 @@ Before application developers can monitor their applications, the human operator
 
 . In the {product-title} web console, navigate to the *Operators* -> *OperatorHub* page and install the Prometheus Operator in the namespace where your application is.
 
-. Navigate to the *Catalog* -> *Developer Catalog* page and install Prometheus, Alertmanager, Prometheus Rule, and Service Monitor in the same namespace.
+. Navigate to the *Operators* -> *Installed Operators* page and install Prometheus, Alertmanager, Prometheus Rule, and Service Monitor in the same namespace.
diff --git a/modules/monitoring-configuring-monitoring-for-an-application.adoc b/modules/monitoring-configuring-monitoring-for-an-application.adoc
@@ -17,7 +17,7 @@ This procedure shows, on an example, how an application developer can deploy an
 
 . Add configuration for deploying a sample application:
 +
-[source,yaml,subs=quotes]
+[source,yaml]
 ----
 apiVersion: extensions/v1beta1
 kind: Deployment
@@ -42,7 +42,7 @@ spec:
 
 . Add configuration for exposing the sample application as a service:
 +
-[source,yaml,subs=quotes]
+[source,yaml]
 ----
 kind: Service
 apiVersion: v1
@@ -62,7 +62,7 @@ spec:
 
 . Add configuration for creating a service monitor for the sample application. This will add your application as a target for monitoring:
 +
-[source,yaml,subs=quotes]
+[source,yaml]
 ----
 apiVersion: monitoring.coreos.com/v1
 kind: ServiceMonitor

diff --git a/modules/monitoring-configuring-the-cluster-monitoring-stack.adoc b/modules/monitoring-configuring-the-cluster-monitoring-stack.adoc
@@ -21,20 +21,20 @@ $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
 
 . Put your configuration under `data/config.yaml` as key-value pair `<component_name>:{nbsp}<component_configuration>`:
 +
-[source,yaml,subs=quotes]
+[source,yaml]
 ----
 apiVersion: v1
 kind: ConfigMap
 metadata:
-  name: *cluster-monitoring-config*
-  namespace: *openshift-monitoring*
+  name: cluster-monitoring-config
+  namespace: openshift-monitoring
 data:
   config.yaml: |
-    *_component_*:
-      *_configuration for the component_*
+    <component>:
+      <configuration_for_the_component>
 ----
 +
-Substitute `<component>` and `<configuration for the component>` accordingly.
+Substitute `<component>` and `<configuration_for_the_component>` accordingly.
 +
 For example, create this ConfigMap to configure a Persistent Volume Claim (PVC) for Prometheus:
 +

diff --git a/modules/monitoring-contents-of-the-alerting-ui.adoc b/modules/monitoring-contents-of-the-alerting-ui.adoc
@@ -9,7 +9,7 @@ This section shows and explains the contents of the Alerting UI, a web interface
 
 The main three pages of the Alerting UI are the *Alerts*, the *Silences*, and the *YAML* pages.
 
-The *Alerts* page is accessible by clicking *Monitoring* -> *Alerts* in the {product-title} web console.
+The *Alerts* page is accessible by clicking *Monitoring* -> *Alerting* -> *Alerts* in the {product-title} web console.
 
 image::monitoring-alerts-screen.png[]
 
@@ -21,7 +21,7 @@ image::monitoring-alerts-screen.png[]
 . Value of the Severity label of the alert.
 . Actions you can do with the alert.
 
-The *Silences* page is accessible by clicking *Monitoring* -> *Silences* in the {product-title} web console.
+The *Silences* page is accessible by clicking *Monitoring* -> *Alerting* -> *Silences* in the {product-title} web console.
 
 image::monitoring-silences-screen.png[]
 

diff --git a/modules/monitoring-contents-of-the-metrics-ui.adoc b/modules/monitoring-contents-of-the-metrics-ui.adoc
@@ -13,7 +13,7 @@ image::monitoring-metrics-screen.png[]
 
 . Actions.
 * Add query.
-* Expand all query tables.
+* Expand or collapse all query tables.
 * Delete all queries.
 . Hide the plot.
 . The interactive plot.
@@ -24,10 +24,10 @@ image::monitoring-metrics-screen.png[]
 . Expand or collapse the form.
 . The query.
 . Clear query.
-. Disable query.
+. Enable or disable query.
 . Actions for a specific query.
-* Disable query.
-* Hide all series of the query from the plot.
+* Enable or disable query.
+* Show or hide all series of the query from the plot.
 * Delete query.
 . The metrics table for a query.
 . Color assigned to the graph of the metric. Clicking the square shows or hides the metric's graph.

diff --git a/modules/monitoring-creating-cluster-monitoring-configmap.adoc b/modules/monitoring-creating-cluster-monitoring-configmap.adoc
@@ -34,7 +34,7 @@ $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
 
 . Create the `data` section if it does not exist yet:
 +
-[source,yaml,subs=quotes]
+[source,yaml]
 ----
 apiVersion: v1
 kind: ConfigMap

diff --git a/modules/monitoring-getting-information-about-alerts-and-alerting-rules.adoc b/modules/monitoring-getting-information-about-alerts-and-alerting-rules.adoc
@@ -11,7 +11,7 @@ You can find an alert and see information about it or its governing alerting rul
 
 . Open the {product-title} web console and navigate to the *Monitoring* -> *Alerting* -> *Alerts* page.
 
-. Optional: Filter the alerts by name using the *Filter alerts by name* field.
+. Optional: Filter the alerts by name using the *Filter Alerts by name* field.
 
 . Optional: Filter the alerts by state using one or more of the state buttons *Firing*, *Silenced*, *Pending*, *Not firing*.
 

diff --git a/modules/monitoring-modifying-retention-time-for-prometheus-metrics-data.adoc b/modules/monitoring-modifying-retention-time-for-prometheus-metrics-data.adoc
@@ -21,7 +21,7 @@ $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
 
 . Put your retention time configuration under `data/config.yaml`:
 +
-[source,yaml,subs=quotes]
+[source,yaml]
 ----
 apiVersion: v1
 kind: ConfigMap
@@ -31,10 +31,10 @@ metadata:
 data:
   config.yaml: |
     prometheusK8s:
-      retention: *_time specification_*
+      retention: <time_specification>
 ----
 +
-Substitute `<time specification>` with a number directly followed by `ms` (milliseconds), `s` (seconds), `m` (minutes), `h` (hours), `d` (days), `w` (weeks), or `y` (years).
+Substitute `<time_specification>` with a number directly followed by `ms` (milliseconds), `s` (seconds), `m` (minutes), `h` (hours), `d` (days), `w` (weeks), or `y` (years).
 +
 For example, to configure retention time to be 24 hours, use:
 +

diff --git a/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc b/modules/monitoring-moving-monitoring-components-to-different-nodes.adoc
@@ -21,7 +21,7 @@ $ oc -n openshift-monitoring edit configmap cluster-monitoring-config
 
 . Specify the `nodeSelector` constraint for the component under `data/config.yaml`:
 +
-[source,yaml,subs=quotes]
+[source,yaml]
 ----
 apiVersion: v1
 kind: ConfigMap
@@ -30,14 +30,14 @@ metadata:
   namespace: openshift-monitoring
 data:
   config.yaml: |
-    *_component_*:
+    <component>:
       nodeSelector:
-        *_node key_*: *_node value_*
-        *_node key_*: *_node value_*
-        *_..._*
+        <node_key>: <node_value>
+        <node_key>: <node_value>
+        <...>
 ----
 +
-Substitute `<component>` accordingly and substitute `<node key>: <node value>` with the map of key-value pairs that specifies the destination node. Often, only a single key-value pair is used.
+Substitute `<component>` accordingly and substitute `<node_key>: <node_value>` with the map of key-value pairs that specifies the destination node. Often, only a single key-value pair is used.
 +
 The component can only run on a node that has each of the specified key-value pairs as labels. The node can have additional labels as well.
 +

diff --git a/monitoring/cluster-monitoring/configuring-the-monitoring-stack.adoc b/monitoring/cluster-monitoring/configuring-the-monitoring-stack.adoc
@@ -38,8 +38,7 @@ See xref:../../scalability_and_performance/optimizing-storage.adoc#recommended-c
 * Dedicate sufficient local persistent storage to ensure that the disk does not become full. How much storage you need depends on the number of pods. For information on system requirements for persistent storage, see xref:../../scalability_and_performance/scaling-cluster-monitoring-operator.adoc#prometheus-database-storage-requirements[Prometheus database storage requirements].
 * Make sure you have a Persistent Volume (PV) ready to be claimed by the Persistent Volume Claim (PVC), one PV for each replica. Since Prometheus has two replicas and Alertmanager has three replicas, you need five PVs to support the entire monitoring stack. The Persistent Volumes should be available from the Local Storage Operator. This does not apply if you enable dynamically provisioned storage.
 * Use the block type of storage.
-// FIXME link
-* link:https://osdocs-486\--ocpdocs.netlify.com/openshift-enterprise/latest/storage/persistent-storage/persistent-storage-local.html[Configure local persistent storage.]
+* xref:../../storage/persistent-storage/persistent-storage-local.adoc#persistent-storage-using-local-volume[Configure local persistent storage.]
 
 include::modules/monitoring-configuring-a-local-persistent-volume-claim.adoc[leveloffset=+2]
 include::modules/monitoring-modifying-retention-time-for-prometheus-metrics-data.adoc[leveloffset=+2]
Original file line number	Diff line number	Diff line change
Expand Up		@@ -15,4 +15,4 @@ Before application developers can monitor their applications, the human operator

		. In the {product-title} web console, navigate to the Operators -> OperatorHub page and install the Prometheus Operator in the namespace where your application is.

		. Navigate to the Catalog -> Developer Catalog page and install Prometheus, Alertmanager, Prometheus Rule, and Service Monitor in the same namespace.
		. Navigate to the Operators -> Installed Operators page and install Prometheus, Alertmanager, Prometheus Rule, and Service Monitor in the same namespace.