**Bart Farrell (00:00.098)**  

No big deal, right? Okay, cool. So, Eric, welcome to The Landscape. Congrats on all the exciting stuff happening with Perses. It’s really a great opportunity for us here on the podcast to speak to someone who’s working on something just getting into the ecosystem. That being said, for people who don’t know Perses, what problem does it solve?

**Eric D. Schabell (00:20.498)**  

What problem does it solve? That’s a really good question. One of the very first things, which is kind of cool to see, and what they put at the top of the list from the beginning, is that there was no dashboard and visualization project within the CNCF landscape—big miss, right? What triggered this whole project was a desire to have that choice: to have some kind of open, fully open-source standard, unlike some of the other options out there that recently became more closed. The first commit was back in 2021, and several large companies pushed it forward, giving you a standard dashboard definition—essentially, a data model.

The tooling focuses on “dashboard as code” and is fully Kubernetes-native. Think operators, CRDs, etc., to make it easy to use alongside the applications you’re trying to visualize. There’s a big emphasis on GitOps, dashboard-as-code principles, and making the tool part of a Kubernetes-native workflow.

I got involved while working for an observability company that started investing in this project and sharing what they were building. I found it super interesting, put together a workshop on how to get started with it, and it’s been a great learning curve. In the early days, it was really simplistic—there wasn’t even a visualized dashboard-building capability, just code and YAML configurations. There have been several iterations since then to get something more visual up and running, but yeah, that’s kind of where it’s at.

**Sylvain Kalache (02:37.451)**  

Among the project features, if you had to pick one, which one would be your favorite?

**Eric D. Schabell (02:45.97)**  

That’s hard—there are a couple of things that are great. Making dashboards as code means you can run it through CI/CD pipelines and have automated checks to ensure you don’t break things. There’s a command-line tool called the Perses CLI, which validates your configurations before you deploy them, so you know it’s not broken. I really like that. There’s also API access, so you can integrate it into your own validation frameworks and architectures. It’s also super easy to get started, and it’s fun to be part of something at its early stages.

Everyone knows what dashboard visualization is, but when you combine it with CNCF’s open-source projects, standardizing things like OpenTelemetry protocols and PromQL, it gets exciting. This helps bring cohesion to a cloud-native observability space that’s currently fragmented with proprietary ways of storing and querying metrics, logs, and traces. Watching it coalesce slowly but surely is really neat.

**Sylvain Kalache (05:01.524)**  

You mentioned “dashboard as code.” Can you tell us more about that? Is the project introducing something new to the industry?

**Eric D. Schabell (05:22.728)**  

I wouldn’t say it’s entirely new—it’s more of a continuation of the GitOps focus. Everyone, whether on the infrastructure, observability, or app dev side, likes automation. You don’t want to push code and then go manually test everything. Being able to integrate dashboard management into your CI/CD or DevOps processes is really helpful. That’s what we’re talking about with “dashboard as code”—you can automate the whole process, and it fits seamlessly with cloud-native Kubernetes environments.

**Bart Farrell (06:21.506)**  

Although Perses is a young project, can you share some success stories of organizations that have implemented it?

**Eric D. Schabell (06:31.889)**  

I can share a little about what my company has done. We’ve been involved early on, contributing while working our day jobs. Amadeus has been a big contributor, as well as Red Hat’s OpenShift team, and Chronosphere was heavily involved from the start. In fact, you’ll find elements of Perses embedded in the Chronosphere product. It’s used to build what we call “native dashboards” that differentiate from other vendor offerings.

I’ll be speaking at PromCon EU in a couple of weeks about Perses and will show some examples of how it integrates with Prometheus and OpenShift for visualizing tracing data, which is a new functionality. I don’t have all the details yet, but I’ll be working with OpenShift developers on this. So, it’s already integrated in some form within OpenShift, and I’d assume Amadeus is using it for internal dashboard visualization.

**Sylvain Kalache (08:50.518)**  

So, it’s all about consuming data. Can you tell us more about what types of data the tool can consume?

**Eric D. Schabell (09:19.654)**  

The baseline is having a storage backend for observability data, whether it’s traces, logs, metrics, or events. Initially, the focus has been on metrics, aligning with Prometheus, a CNCF project. Prometheus is one of the storage backends, and Perses supports PromQL as the query language. In my workshop, I show how you can use queries to actual hosted Prometheus instances. They’re also working on visualizing tracing data, so think about Kubernetes microservices and tracking where delays occur in requests. There’s no log support yet, but the project is still in early stages.

**Bart Farrell (12:52.802)**  

We’ve talked about the benefits and adoption, but when is Perses not the right answer? When should you look elsewhere?

**Eric D. Schabell (13:17.482)**  

An obvious case is if you’re dealing with proprietary vendor data that can’t be queried using open-source tools like Prometheus. If you need something specific that isn’t supported by Perses yet, that could be a reason to look elsewhere. The project is still in early days—it’s only a sandbox project, not even at version 1.0. So, if it’s missing something crucial for you, that’s a limitation. But why not contribute and help solve that problem?

**Bart Farrell (14:17.74)**  

Absolutely. Speaking of contributions, are there any shout-outs to folks who have been heavily involved?

**Eric D. Schabell (14:34.58)**  

For sure, Amadeus deserves a shout-out for letting their developers work on it. Steven Cobb, who worked at Chronosphere, and Augustin Husson from Amadeus have been significant contributors. There’s also Julie Paganon, who contributed from Chronosphere. They’ve all been key players. The project is really friendly, and everyone is approachable if you have questions.

**Bart Farrell (16:07.874)**  

What can we expect next in the Perses world? Any exciting developments on the roadmap?

**Eric D. Schabell (16:32.721)**  

The roadmap is broad, but key areas include revamping the plugin system, improving Knative integration, and building out an explorer feature for easier querying of metrics and traces. They’re also discussing adding an alert view, though that’s further down the road. There are about 100 open issues, so it’s not overwhelming if someone wants to jump in and help.

**Sylvain Kalache (18:30.226)**  

If someone wants to contribute, where should they start?

**Eric D. Schabell (18:44.316)**  

It’s set up like other CNCF projects with a clear contribution guide. If you’re new or not super technical, contributing to user documentation is a great place to start. The docs can always be improved. You could go through my workshop, find areas where the documentation is lacking, and add those improvements. That’s the easiest way to get started.