From 8f75fe4738e08bcfcd74fc5b45c31767f8263e42 Mon Sep 17 00:00:00 2001 From: Gwynne Monahan Date: Thu, 27 Jul 2023 15:20:35 -0500 Subject: [PATCH] Add Kiali Configuration for user-workload-monitoring. --- ...grating-with-user-workload-monitoring.adoc | 83 +++++++++++++++++-- 1 file changed, 77 insertions(+), 6 deletions(-) diff --git a/modules/ossm-integrating-with-user-workload-monitoring.adoc b/modules/ossm-integrating-with-user-workload-monitoring.adoc index 42b991dc3829..ccf415d1d52d 100644 --- a/modules/ossm-integrating-with-user-workload-monitoring.adoc +++ b/modules/ossm-integrating-with-user-workload-monitoring.adoc @@ -15,9 +15,60 @@ The following steps show how to integrate Service Mesh with user-workload monito * User-workload monitoring is enabled. * {SMProductName} Operator 2.4 is installed. +* Kiali Operator 1.65 is installed. .Procedure +. Create a token to Thanos for Kiali by running the following commands: ++ +.. 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] +---- +$ TOKEN=`echo $(oc get secret $SECRET -n openshift-user-workload-monitoring -o jsonpath='{.data.token}' | base64 -d` +---- ++ +.. Create a token to Thanos for Kiali by running the following command: ++ +[source,terminal] +---- +$ oc create secret generic thanos-querier-web-token -n istio-system --from-literal=token=$TOKEN +---- + +. Configure Kiali for user-workload monitoring: ++ +[source,yaml] +---- +apiVersion: kiali.io/v1alpha1 +kind: Kiali +metadata: + name: kiali-user-workload-monitoring + namespace: istio-system +spec: + external_services: + istio: + url_service_version: 'http://istiod-basic.istio-system:15014/version' + 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 + version: v1.65 +---- + . Configure the SMCP for external Prometheus: + [source,yaml] @@ -34,7 +85,12 @@ spec: grafana: enabled: false # <2> kiali: - enabled: false + name: kiali-user-workload-monitoring +spec: + meshConfig: + extenstionProviders: + - name: prometheus + prometheus: {} ---- <1> Disable the default Prometheus instance provided by OSSM. <2> Disable Grafana. It is not supported with an external Prometheus instance. @@ -47,7 +103,7 @@ apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: user-workload-access - namespace: bookinfo + namespace: bookinfo # <1> spec: ingress: - from: @@ -58,6 +114,7 @@ spec: policyTypes: - Ingress ---- +<1> The custom network policy must be applied to all namespaces. . Apply a `Telemetry` object to enable traffic metrics in Istio proxies: + @@ -99,11 +156,18 @@ spec: interval: 30s relabelings: - action: replace - replacement: "-" # <2> + replacement: "basic-istio-system" # <2> targetLabel: mesh_id ---- <1> Since {product-title} monitoring ignores the `namespaceSelector` spec in `ServiceMonitor` and `PodMonitor` objects, you must apply the `PodMonitor` object in all mesh namespaces, including the control plane namespace. -<2> A shared Prometheus instance can include metrics from multiple meshes. However, if you are deploying Kiali, the metrics must be associated with a single mesh. To associate metrics with a single mesh, add a unique `mesh_id` to each one. Doing so narrows the query scope in Kiali to only the relevant mesh metrics. +<2> The string `"basic-istio-system"` is a combination of the SMCP name and its namespace, but any label can be used as long as it is unique for every mesh using user workload monitoring in the cluster. The `spec.prometheus.query_scope` of the Kiali resource configured in Step 2 needs to match this value. ++ +[NOTE] +==== +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 there might be multiple meshes using user-workload monitoring, then both the `mesh_id` relabelings and the `spec.prometheus.query_scope` field in the Kiali resource are required so that Kiali only sees metrics from its associated mesh. If Kiali is not being deployed, applying the `mesh_id` relabeling is still recommended so that metrics from different meshes can be distinguished from one another. +==== . Apply a `PodMonitor` object to collect metrics from Istio proxies: + @@ -149,10 +213,17 @@ spec: action: replace targetLabel: pod_name - action: replace - replacement: "-" # <2> + replacement: "basic-istio-system" # <2> targetLabel: mesh_id ---- <1> Since {product-title} monitoring ignores the `namespaceSelector` spec in `ServiceMonitor` and `PodMonitor` objects, you must apply the `PodMonitor` object in all mesh namespaces, including the control plane namespace. -<2> A shared Prometheus instance can include metrics from multiple meshes. However, if you are deploying Kiali, the metrics must be associated with a single mesh. To associate metrics with a single mesh, add a unique `mesh_id` to each one. Doing so narrows the query scope in Kiali to only the relevant mesh metrics. +<2> The string `"basic-istio-system"` is a combination of the SMCP name and its namespace, but any label can be used as long as it is unique for every mesh using user workload monitoring in the cluster. The `spec.prometheus.query_scope` of the Kiali resource configured in Step 2 needs to match this value. ++ +[NOTE] +==== +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 there might be multiple meshes using user-workload monitoring, then both the `mesh_id` relabelings and the `spec.prometheus.query_scope` field in the Kiali resource are required so that Kiali only sees metrics from its associated mesh. If Kiali is not being deployed, applying the `mesh_id` relabeling is still recommended so that metrics from different meshes can be distinguished from one another. +==== . Open the {product-title} web console, and check that metrics are visible. \ No newline at end of file