Skip to content

Community#

Introducing the Perses MCP Server

We're thrilled to introduce the Perses MCP Server, now available in public beta. This new tool empowers you to interact with your Perses instances using natural language, opening up a world of possibilities for monitoring and visualization.

With the Perses MCP Server, users can use AI Agents to understand, query and interact with Perses APIs in a standardized and secure manner.

Imagine being able to prompt your favorite AI Agent with questions like:

  • "How many dashboards are created in the last 5 days in project 'Test Project'?"
  • "What is the default datasource for project 'Test Project'?"
    • "Is this datasource in proxy mode? and what is the URL?"
  • "Analyze this dashboard 'Dashboard A' in project 'Test Project'"
    • Suggest me some improvements to panels and PromQL queries in this dashboard

As you can see, the possibilities are endless. The Perses MCP Server allows you to interact with Perses in ways that were previously not possible.

Composable Dashboards - Lessons from building Perses Community Dashboards

Why we keep rewriting the same dashboards

Every CNCF User/Developer/Contributor has, at some point, to endure the frustration of trying to salvage an outdated dashboard, or adapting upstream YAML, only to get to the point of wondering why it doesn't work on their setup. This leads to a recurring pattern: everyone ends up rebuilding the same dashboards, over and over again, each slightly different.

The Mixins Dashboards helped bring about a sense of relief, as users now could use dashboards and alerts packaged together with the code they are deployed with. In theory, this promised consistency and easier integration. In practical terms, as the concept of mixins relies on Jsonnet, and even though it’s a suitable language for configuration management, it leads to a few issues:

  • Jsonnet has a steep learning curve. It’s not a conventional Turing-complete programming language, and often makes it hard for downstream users of mixins to be able to do any sort of customization on their dashboards;

  • Mixin Jsonnet is completely detached from the actual application code. It was introduced as a way to maintain dashboarding config for code that you are deploying side by side, to ensure it never goes out of sync. However, many mixins are rarely updated, even when the code is - sometimes these are maintained out of the tree. And Jsonnet cannot use Go structs, so there is no automatic validation during code changes. Thus keeping mixins accurate and reliable demands a lot of effort.;

  • Adoption has also been uneven. A good example of this is kube-prometheus stack, built with Jsonnet, where many users bypass it entirely and only fetch the rendered YAML from that repository, then doing any sort of changes with tools like Kustomize instead. This undermines the original goal of reuse and standardization.

The end result is, that despite the promise of reusable dashboards, the reality is there’s still not a widely used solution for automatic dashboards creation.