Merge pull request #72324 from gwynnemonahan/OSSM-6010

OSSM-6010 [DOC] Update user-workload monitoring so Kiali can fetch metrics from Thanos

Author: mburke5678

modules/ossm-integrating-with-user-workload-monitoring.adoc

@@ -19,31 +19,47 @@ The following steps show how to integrate Service Mesh with user-workload monito
 
 .Procedure
 
-. Create a token to Thanos for Kiali by running the following commands:
+. Grant the `cluster-monitoring-view` role to the Kiali Service Account, replacing `<kiali-namespace>` with the name of the Kiali deployment namespace:
 +
-.. Set the `SECRET` environment variable by running the following command:
-+
-[source,terminal]
-----
-$ SECRET=`oc get secret -n openshift-user-workload-monitoring |
- grep  prometheus-user-workload-token | head -n 1 | awk '{print $1 }'`
-----
-+
-.. Set the `TOKEN` environment variable by running the following command:
-+
-[source,terminal]
+[source,yaml]
 ----
-$ TOKEN=`oc get secret $SECRET -n openshift-user-workload-monitoring -o jsonpath='{.data.token}' | base64 -d`
+apiVersion: rbac.authorization.k8s.io/v1
+kind: ClusterRoleBinding
+metadata: 
+  name: kiali-monitoring-rbac
+roleRef: 
+  apiGroup: rbac.authorization.k8s.io
+  kind: ClusterRole
+  name: cluster-monitoring-view
+subjects: 
+- kind: ServiceAccount
+  name: kiali-service-account
+  namespace: <kiali-namespace>
 ----
+
+. Configure Kiali for user-workload monitoring:
 +
-.. Create a token to Thanos for Kiali by running the following command:
-+
-[source,terminal]
+[source,yaml]
 ----
-$ oc create secret generic thanos-querier-web-token -n istio-system --from-literal=token=$TOKEN
+apiVersion: kiali.io/v1alpha1
+kind: Kiali
+metadata:
+  name: kiali-user-workload-monitoring
+  namespace: istio-system
+spec:
+  external_services:
+    prometheus:
+      auth:
+        token: secret:thanos-querier-web-token:token
+        type: bearer
+        use_kiali_token: false
+      query_scope:
+        mesh_id: "basic-istio-system"
+      thanos_proxy:
+        enabled: true
+      url: https://thanos-querier.openshift-monitoring.svc.cluster.local:9091
 ----
-
-. Configure Kiali for user-workload monitoring:
+** If you use Istio Operator 2.4, use this configuration to configure Kiali for user-workload monitoring:
 +
 [source,yaml]
 ----
@@ -52,15 +68,15 @@ kind: Kiali
 metadata:
   name: kiali-user-workload-monitoring
   namespace: istio-system
-spec: 
-  external_services: 
-    istio: 
+spec:
+  external_services:
+    istio:
       config_map_name: istio-<smcp-name>
       istio_sidecar_injector_config_map_name: istio-sidecar-injector-<smcp-name>
       istiod_deployment_name: istiod-<smcp-name>
       url_service_version: 'http://istiod-<smcp-name>.istio-system:15014/version'
-    prometheus: 
-      auth: 
+    prometheus:
+      auth:
         token: secret:thanos-querier-web-token:token
         type: bearer
         use_kiali_token: false
@@ -168,7 +184,7 @@ spec:
 ====
 If there is only one mesh using user-workload monitoring, then both the `mesh_id` relabeling and the `spec.prometheus.query_scope` field in the Kiali resource are optional (but the `query_scope` field given here should be removed if the `mesh_id` label is removed).
 
-If multiple mesh instances on the cluster may use user-workload monitoring, then both the `mesh_id` relabelings and the `spec.prometheus.query_scope` field in the Kiali resource are required. This ensures that Kiali only sees metrics from its associated mesh.
+If multiple mesh instances on the cluster might use user-workload monitoring, then both the `mesh_id` relabelings and the `spec.prometheus.query_scope` field in the Kiali resource are required. This ensures that Kiali only sees metrics from its associated mesh.
 
 If you are not deploying Kiali, you can still apply `mesh_id` relabeling so that metrics from different meshes can be distinguished from one another.
 ====
@@ -227,7 +243,7 @@ spec:
 ====
 If there is only one mesh using user-workload monitoring, then both the `mesh_id` relabeling and the `spec.prometheus.query_scope` field in the Kiali resource are optional (but the `query_scope` field given here should be removed if the `mesh_id` label is removed).
 
-If multiple mesh instances on the cluster may use user-workload monitoring, then both the `mesh_id` relabelings and the `spec.prometheus.query_scope` field in the Kiali resource are required. This ensures that Kiali only sees metrics from its associated mesh.
+If multiple mesh instances on the cluster might use user-workload monitoring, then both the `mesh_id` relabelings and the `spec.prometheus.query_scope` field in the Kiali resource are required. This ensures that Kiali only sees metrics from its associated mesh.
 
 If you are not deploying Kiali, you can still apply `mesh_id` relabeling so that metrics from different meshes can be distinguished from one another.
 ====