Integrating Perses Dashboards With Kiali For Enhanced Data Visualization

Jul 21, 2025 by JurnalWarga.com 73 views

Perses Add Support for Visualizing Data with Perses Dashboards in Kiali

Hey everyone! Today, we're diving deep into an exciting proposal to enhance Kiali by adding support for Perses, a cool open-source observability platform. If you're familiar with Grafana, you'll find Perses quite similar, as it's designed to visualize data from sources like Prometheus, Thanos, and Jaeger. What's awesome is that Perses is a CNCF Sandbox project, which means it's got some serious backing and potential. Let's break down what this integration means for Kiali and how it will work.

What's the Plan? Enhancing Kiali with Perses Dashboards

The main goal here is to bring Perses dashboards into the Kiali interface, giving you even more ways to visualize and understand your data. To make this happen, there are a few key tasks we need to tackle. First, we need to update Kiali to recognize and support Perses as an external service. This means Kiali needs to know how to talk to Perses and display its dashboards seamlessly. The process involves a bit of URL wrangling because Perses and Grafana use different URL formats. For example, a Perses URL might look like this:

http://localhost:9080/projects/istio/dashboards/istio-control-plane?start=1h&refresh=0s

While a similar Grafana dashboard URL looks like this:

http://localhost:13000/d/1813f692a8e4ac77155348d4c7d2fba8/istio-control-plane-dashboard?orgId=1&from=now-30m&to=now&timezone=utc&var-datasource=PBFA97CFB590B2093&refresh=15s

See the difference? We need to make sure Kiali can handle these variations. When dealing with workloads, we'll also be using variables to filter data. Here’s an example of how a Perses URL with variables might look:

http://localhost:9080/projects/istio/dashboards/istio-workload-dashboard?var-namespace=bookinfo&var-workload=productpage-v1&var-qrep=destination&var-srcns=%24__all&var-srcwl=%24__all&var-dstsvc=%24__all&start=1h&refresh=0s

Comparing this to a Grafana URL with variables, you can see the adaptations needed to seamlessly integrate Perses:

http://localhost:13000/d/cesluk24q5ts0a/istio-workload-dashboard?orgId=1&from=now-30m&to=now&var-datasource=PBFA97CFB590B2093&var-namespace=bookinfo&var-workload=details-v1&var-qrep=destination&var-srcns=$__all&var-srcwl=$__all&var-dstsvc=$__all&refresh=1m

OpenShift Considerations and OSSMC Adaptation

Another important point is that Perses URLs might look different in OpenShift environments, so we'll need to account for that with additional configuration. Also, we're planning to adapt the URL structure for OSSMC (Open Service Mesh Configuration). The good news is we can probably auto-discover the URL and settings since they'll likely be on the same host. Finally, we'll update the hack scripts, like run-kiali, to ensure Perses can run smoothly within the Kiali ecosystem. This involves modifying the scripts to include Perses-specific configurations and dependencies, allowing developers to easily spin up Kiali with Perses support for testing and development purposes. The goal is to make the integration as seamless as possible, so anyone can leverage Perses dashboards directly from Kiali.

Current vs. New Behavior: What's Changing?

Currently, Kiali doesn't have any built-in support for Perses. This means you can't directly view Perses dashboards within the Kiali UI. The new behavior will introduce Perses as a supported external service. This means you'll be able to configure Kiali to connect to your Perses instance and display dashboards right alongside your other Kiali visualizations. Imagine having all your monitoring and observability tools in one place – that's the goal!

Configuration Deep Dive: How Will Perses Integrate?

To make this happen, we'll introduce a new section in Kiali's configuration for Perses. It might look something like this:

external_services:
 perses:
 enabled: true
 internal_url: http://localhost:14000
 external_url: http://localhost:14000
 health_check_url: http://localhost:14000
 auth:
 # TODO: which auths are supported?
 project: "istio"
 format: openshift/
 dashboards:
 - name: "Istio Service Dashboard"
 variables:
 namespace: "var-namespace"
 service: "var-service"
 datasource: "var-datasource"
 - name: "Istio Workload Dashboard"
 variables:
 namespace: "var-namespace"
 workload: "var-workload"
 - name: "Istio Mesh Dashboard"
 variables:
 namespace: "var-namespace"
 workload: "var-workload"
 datasource: "var-datasource"

Let's break down this configuration:

enabled: This is a simple boolean to turn Perses support on or off.
internal_url and external_url: These define the URLs Kiali will use to access Perses, whether internally within your cluster or externally. This dual configuration allows for flexibility in different deployment environments.
health_check_url: This URL is used by Kiali to periodically check if the Perses service is up and running. This ensures that Kiali can alert administrators if Perses becomes unavailable, maintaining the reliability of the observability platform.
auth: Here, we'll need to figure out which authentication methods Perses supports and configure Kiali accordingly. Security is super important, so getting this right is key.
project: This specifies the Perses project Kiali should connect to, which helps in organizing dashboards and access control within Perses.
format: This field is particularly important for handling the variations in Perses URLs, especially in environments like OpenShift. It allows Kiali to adapt its URL construction based on the specific deployment context.
dashboards: This section is where you define the dashboards you want to make available in Kiali. For each dashboard, you specify a name and a set of variables. These variables are used to map Kiali's context (like namespaces or workloads) to the corresponding Perses dashboard parameters.

Dashboard Variables: Dynamic Data Mapping

The variables section is particularly powerful. It allows you to map Kiali concepts like namespaces and workloads to Perses dashboard parameters. For example, if you're viewing a specific namespace in Kiali, the var-namespace variable will ensure that the Perses dashboard displays data for that namespace. This dynamic mapping makes it super easy to drill down into specific areas of your mesh.

Updating the Mesh Page

Once we have this configuration in place, we'll update the Kiali mesh page to include Perses dashboards. This will likely involve adding new UI elements that allow you to select and view Perses dashboards directly from Kiali's interface. The goal is to make the integration feel natural and seamless, so you can easily switch between Kiali's built-in visualizations and your Perses dashboards.

Grafana vs. Perses: A Key Question

Now, here's a key question we need to consider: since Perses and Grafana have similar functionality, should we replace Grafana support with Perses support in Kiali? There's a lot of overlap in what these tools can do, but there are also some differences. Some configurations are the same between the two platforms, while others differ. It's unlikely that you'd use both at the same time, but we don't want to create any problems if you do. This is something we need to think about carefully. The decision to replace or coexist will hinge on user needs, technical feasibility, and the long-term vision for Kiali's observability capabilities.

Compatibility Considerations

One potential issue is that if we rename the external_services.Grafana configuration, it could affect compatibility with existing Kiali setups. We need to make sure that any changes we make don't break existing workflows. This might involve providing a migration path or ensuring that the new configuration is backward-compatible. We must weigh the benefits of the new Perses integration against the potential disruption to existing Grafana users. The aim is to provide a smooth transition, minimizing any inconvenience and maximizing the value users derive from Kiali.

Conclusion: Exciting Times Ahead!

Overall, adding Perses support to Kiali is a really exciting step. It gives you more flexibility in choosing your observability tools and provides a more integrated experience. There are some challenges to work through, like URL differences and configuration options, but the end result will be a more powerful and versatile Kiali. What do you guys think about this? Let's discuss and make this integration awesome!