RHDEVDOCS-3424-remove-prometheus-ui-from-docs

bburt-rh · bburt-rh · commit a215a8fa002d · 2022-04-21T14:43:39.000-04:00
diff --git a/modules/monitoring-accessing-third-party-monitoring-uis.adoc b/modules/monitoring-accessing-third-party-monitoring-uis.adoc
@@ -7,12 +7,12 @@
 = Accessing third-party monitoring UIs
 
 [role="_abstract"]
-{product-title} does not provide or support direct access to third-party web user interfaces (UIs) for the following components in the monitoring stack: Alertmanager, Thanos Ruler, and Thanos Querier. 
-As an alternative to these third-party UIs, navigate to the *Observe* section of the {product-title} web console to access metrics, alerting, metrics targets, and dashboard UIs for platform components.
+{product-title} does not provide or support direct access to third-party web user interfaces (UIs) for the following components in the monitoring stack: Alertmanager, Prometheus, Thanos Ruler, and Thanos Querier. 
+As an alternative to these third-party UIs, navigate to the *Observe* section of the {product-title} web console to access alerting, metrics, dashboards, targets, and other UIs for platform components.
 
 [NOTE]
 ====
-Although you can access the third-party Grafana and Prometheus web UIs from the web console or the CLI, this access is deprecated and is planned to be removed in a future {product-title} release.
+Although you can access the third-party Grafana web UI from the web console or the CLI, this access is deprecated and is planned to be removed in a future {product-title} release.
 ====
 
 
diff --git a/modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc b/modules/monitoring-accessing-third-party-monitoring-web-service-apis.adoc
@@ -9,14 +9,27 @@
 [role="_abstract"]
 You can directly access third-party web service APIs from the command line for monitoring stack components such as Prometheus, Alertmanager, Thanos Ruler, and Thanos Querier. 
 
-The following example shows how to query the service API receivers for Alertmanager.
+The following example commands show how to query the service API receivers for Alertmanager.
 This example requires that the associated user account be bound against the `monitoring-alertmanager-edit` role in the `openshift-monitoring` namespace and that the account has the privilege to view the route.
 This access only supports using a Bearer Token for authentication.
 
-[source, terminal]
+[source,terminal]
+----
+$ oc login -u <username> -p <password>
+----
+
+[source,terminal]
 ----
 $ host=$(oc -n openshift-monitoring get route alertmanager-main -ojsonpath={.spec.host})
+----
+
+[source,terminal]
+----
 $ token=$(oc whoami -t)
+----
+
+[source,terminal]
+----
 $ curl -H "Authorization: Bearer $token" -k "https://$host/api/v2/receivers"
 ----
 
diff --git a/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc b/modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc
@@ -15,7 +15,7 @@ You can use the following measures when Prometheus consumes a lot of disk:
 
 * *Check the number of scrape samples* that are being collected.
 
-* *Check the time series database (TSDB) status in the Prometheus UI* for more information on which labels are creating the most time series. This requires cluster administrator privileges.
+* *Check the time series database (TSDB) status using the Prometheus HTTP API* for more information about which labels are creating the most time series. Doing so requires cluster administrator privileges.
 
 * *Reduce the number of unique time series that are created* by reducing the number of unbound attributes that are assigned to user-defined metrics.
 +
@@ -47,9 +47,32 @@ topk(10,count by (job)({__name__=~".+"}))
 
 ** *If the metrics relate to a core {product-title} project*, create a Red Hat support case on the link:https://access.redhat.com/[Red Hat Customer Portal].
 
-. Check the TSDB status in the Prometheus UI.
-.. In the *Administrator* perspective, navigate to *Networking* -> *Routes*.
-.. Select the `openshift-monitoring` project in the *Project* list.
-.. Select the URL in the `prometheus-k8s` row to open the login page for the Prometheus UI.
-.. Choose *Log in with OpenShift* to log in using your {product-title} credentials.
-.. In the Prometheus UI, navigate to *Status* -> *TSDB Status*.
+. Review the TSDB status using the Prometheus HTTP API by running the following commands as a cluster administrator:
++
+[source,terminal]
+----
+$ oc login -u <username> -p <password>
+----
++
+[source,terminal]
+----
+$ host=$(oc -n openshift-monitoring get route prometheus-k8s -ojsonpath={.spec.host})
+----
++
+[source,terminal]
+----
+$ token=$(oc whoami -t)
+----
++
+[source,terminal]
+----
+$ curl -H "Authorization: Bearer $token" -k "https://$host/api/v1/status/tsdb"
+----
++
+.Example output
+[source,terminal]
+----
+"status": "success",
+----
+
+
diff --git a/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc b/modules/monitoring-investigating-why-user-defined-metrics-are-unavailable.adoc
@@ -91,15 +91,12 @@ If there is a issue with the service monitor, the logs might include an error si
 level=warn ts=2020-08-10T11:48:20.906739623Z caller=operator.go:1829 component=prometheusoperator msg="skipping servicemonitor" error="it accesses file system via bearer token file which Prometheus specification prohibits" servicemonitor=eagle/eagle namespace=openshift-user-workload-monitoring prometheus=user-workload
 ----
 
-. *Review the target status for your project* in the Prometheus UI directly.
-.. Establish port-forwarding to the Prometheus instance in the `openshift-user-workload-monitoring` project:
-+
-[source,terminal]
-----
-$ oc port-forward -n openshift-user-workload-monitoring pod/prometheus-user-workload-0 9090
-----
-+
-.. Open http://localhost:9090/targets in a web browser and review the status of the target for your project directly in the Prometheus UI. Check for error messages relating to the target.
+. *Review the target status for your endpoint* on the *Metrics targets* page in the {product-title} web console UI.
+.. Log in to the {product-title} web console and navigate to *Observe* → *Targets* in the *Administrator* perspective.
+
+.. Locate the metrics endpoint in the list, and review the status of the target in the *Status* column.
+
+.. If the *Status* is *Down*, click the URL for the endpoint to view more information on the *Target Details* page for that metrics target.
 
 . *Configure debug level logging for the Prometheus Operator* in the `openshift-user-workload-monitoring` project.
 .. Edit the `user-workload-monitoring-config` `ConfigMap` object in the `openshift-user-workload-monitoring` project:
diff --git a/monitoring/accessing-third-party-monitoring-uis-and-apis.adoc b/monitoring/accessing-third-party-monitoring-uis-and-apis.adoc
@@ -7,8 +7,8 @@ include::_attributes/common-attributes.adoc[]
 toc::[]
 
 [role="_abstract"]
-In {product-title} {product-version}, you cannot access third-party web browser user interfaces (UIs) for the following monitoring components: Alertmanager, Thanos Ruler, and Thanos Querier. 
-However, you can access web UIs for Grafana and Prometheus, although this access is deprecated and is planned to be removed in a future {product-title} release.
+In {product-title} {product-version}, you cannot access third-party web browser user interfaces (UIs) for the following monitoring components: Alertmanager, Prometheus, Thanos Ruler, and Thanos Querier. 
+However, you can access the web UI for Grafana, although this access is deprecated and is planned to be removed in a future {product-title} release.
 In addition, you can access web service APIs for third-party monitoring components from the command line interface (CLI).
 
 // Accessing web UIs for third-party monitoring components
diff --git a/monitoring/troubleshooting-monitoring-issues.adoc b/monitoring/troubleshooting-monitoring-issues.adoc
@@ -14,6 +14,8 @@ include::modules/monitoring-investigating-why-user-defined-metrics-are-unavailab
 
 * xref:../monitoring/configuring-the-monitoring-stack.adoc#creating-user-defined-workload-monitoring-configmap_configuring-the-monitoring-stack[Creating a user-defined workload monitoring config map]
 * See xref:../monitoring/managing-metrics.adoc#specifying-how-a-service-is-monitored_managing-metrics[Specifying how a service is monitored] for details on how to create a `ServiceMonitor` or `PodMonitor` resource
+* See xref:../monitoring/managing-metrics-targets.adoc#monitoring-accessing-the-metrics-targets-page_managing-metrics-targets[Accessing metrics targets in the Administrator perspective]
+
 
 // Determining why Prometheus is consuming a lot of disk space
 include::modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc[leveloffset=+1]
diff --git a/support/troubleshooting/investigating-monitoring-issues.adoc b/support/troubleshooting/investigating-monitoring-issues.adoc
@@ -19,6 +19,7 @@ include::modules/monitoring-investigating-why-user-defined-metrics-are-unavailab
 
 * xref:../../monitoring/configuring-the-monitoring-stack.adoc#creating-user-defined-workload-monitoring-configmap_configuring-the-monitoring-stack[Creating a user-defined workload monitoring config map]
 * See xref:../../monitoring/managing-metrics.adoc#specifying-how-a-service-is-monitored_managing-metrics[Specifying how a service is monitored] for details on how to create a service monitor or pod monitor
+* See xref:../../monitoring/managing-metrics-targets.adoc#monitoring-accessing-the-metrics-targets-page_managing-metrics-targets[Accessing metrics targets in the Administrator perspective]
 
 // Determining why Prometheus is consuming a lot of disk space
 include::modules/monitoring-determining-why-prometheus-is-consuming-disk-space.adoc[leveloffset=+1]
