We all know that Prometheus is a popular system for collecting and querying metrics, especially in the cloud native world of Kubernetes and ephemeral instances. But people forget that Java has been running enterprise software since 1995, while Prometheus is a relative newcomer to the scene. It was only created in 2012! Even though Java has had its own metric collectors since before Prometheus was born, none of our new environments speak its (metric) language. How can you bridge that gap?

There are a lot of great things about Grafana 7.0, but one of my favorite features is the new React-based plugin platform, which has a set of new APIs and design system to help you build your own plugin. The process is easier and faster than ever. In this blog post, I’ll show how you can create a panel plugin for visualizing scatter plots. A scatter plot is a type of graph that displays values for (usually) two variables as a set of points along a horizontal and vertical axis.

Do you have a Prometheus histogram and have you asked yourself how to visualize that histogram in Grafana? You’re not alone. Here, we will show you how it’s done. This post assumes you already have a basic understanding of Prometheus and Grafana and it will look at Prometheus histograms from the perspective of Grafana 7.0.

As many of you already know, we created Grafana using AngularJS, but we have been migrating to React for about two years now. One of the big missing pieces in our migration puzzle was the templating system. This post starts in late 2019 when I first got my hands on this mysterious and complex area of the Grafana code base.

Tracing is a widely adopted solution to provide performance insights into distributed applications. It is a valuable resource for developers to view the service call graph and track service latency at a granular level. It’s also a handy tool for on-call engineers to drill down and debug a problematic service during an outage. There are a number of open source distributed tracing frameworks out in the wild, including Jaeger, Zipkin, and OpenTelemetry.

Since Petr Slavotinek created the Carpet plot plugin in 2017, it’s been one of the most popular community plugins for Grafana. Unfortunately, even though the Carpet plot plugin continues to be useful to many users, it’s no longer being maintained. Grafana 7.0 introduced a brand new React-based platform, along with a set of improved APIs for building plugins.

At Grafana Labs, we’re all big fans of the Prometheus and Grafana combination. To an extent, we just won’t shut up about it. We strongly believe in simplicity and think you shouldn’t need any extra effort to understand the metrics of your service(s) holistically. Yet we’ve all been in that situation where it is challenging to fully grasp what the metrics of our service(s) are and what they do. While naming conventions exist, at times they are not followed or enforced.

Among the many new features introduced in Grafana 7.0, one of the most exciting ones is transformations. The concept of data transformation is not new to Grafana, but prior to Grafana 7, it was fairly rigid and available only in the Table panel.

The just-released Prometheus v2.19.0 introduces the new feature of memory-mapping full chunks of the head (in-memory) block from disk, which reduces memory usage and also makes restarts faster. I will be talking about this feature in this blog post.

Running your software on dynamic infrastructure means that your monitoring platform needs to change dynamically. Variables let you reuse a single dashboard for all your services. Select the service you want to inspect from a drop-down menu, and watch panels update to only show you metrics from that service. Grafana lets you create dynamic dashboards using template variables. Any variables in your queries interpolate the current value of the variable before the query is sent to the database.