As Grafana powers our star product – Percona Monitoring and Management (PMM) – we have developed a lot of experience creating Grafana Dashboards over the last few years. In this article, I will share some of the considerations for designing Grafana Dashboards. As usual, when it comes to questions of design they are quite subjective, and I do not expect you to chose to apply all of them to your dashboards, but I hope they will help you to think through your dashboard design better.
Design Practical Dashboards
Grafana features many panel types, and even more are available as plugins. It may be very attractive to use many of them in your dashboards using many different visualization options. Do not! Stick to a few data visualization patterns and only add additional visualizations when they provide additional practical value not because they are cool. Graph and Singlestat panel types probably cover 80% of use cases.
Do Not Place Too Many Graphs Side by Side
This probably will depend a lot on how your dashboards are used. If your dashboard is designed for large screens placed on the wall you may be able to fit more graphs side by side, if your dashboard needs to scale down to lower resolution small laptop screen I would suggest sticking to 2-3 graphs in a row.
Use Proper Units
Grafana allows you to specify a unit for the data type displayed. Use it! Without type set values will not be properly shortened and very hard to read:
Compare this to
You can specify the number of values after decimal points you want to display or leave it default. I found default picking does not always work very well, for example here:
For some reason on the panel Axis, we have way too many values displayed after the decimal point. Grafana also often picks three values after decimal points as in the table below which I find inconvenient – from the glance view, it is hard to understand if we’re dealing with a decimal point or with “,” as a “thousands” separator, so I may be looking at 2462 GiB there. While it is not feasible in this case, there are cases such as data rate where a 1000x value difference is quite possible. Instead, I prefer setting it to one decimal (or one if it is enough) which makes it clear that we’re not looking at thousands.
Label your Axis
You can label your axis (which especially makes sense) if the presentation is something not as obvious as in this example; we’re using a negative value to lot writes to a swap file.
Use Shared Crosshair or Tooltip
In Dashboard Settings, you will find “Graph Tooltip” option and set it to “Default”,
“Shared Crosshair” or “Share Tooltip” This is how these will look:
Shared crosshair shows the line matching the same time on all dashboards while Tooltip shows the tooltip value on all panels at the same time. You can pick what makes sense for you; my favorite is using the tooltip setting because it allows me to visually compare the same time without making the dashboard too slow and busy.
Note there is handy shortcut CTRL-O which allows you to cycle between these settings for any dashboard.
If you’re displaying truly dynamic information you will likely have to rely on Grafana’s automatic color assignment, but if not, you can pick specific colors for all values being plotted. This will prevent colors from potentially being re-assigned to different values without you planning to do so.
Picking colors you also want to make sure you pick colors that make logical sense. For example, I think for free memory “green” is a better color than “red”. As you pick the colors, use the same colors for the same type of information when you show it on the different panels if possible, because it makes it easier to understand.
I would even suggest sticking to the same (or similar) color for the Same Kind of Data – if you have many panels which show disk Input and Output using similar colors, this can be a good idea.
Fill Stacking Graphs
Grafana does not require it, but I would suggest you use filling when you display stacking data and don’t use filling when you’re plotting multiple independent values. Take a look at these graphs:
In the first graph, I need to look at the actual value of the plotted value to understand what I’m looking at. At the same time, in the second graph, that value is meaningless and what is valuable is the filled amount. I can see on the second graph what amount of the Cache, blue value, has shrunk.
I prefer using a fill factor of 6+ so it is easier to match the fill colors with colors in the table. For the same reason, I prefer not to use the fill gradient on such graphs as it makes it much harder to see the color and the filled volume.
Do Not Abuse Double Axis
Graphs that use double axis are much harder to understand. I used to use it very often, but now I avoid it when possible, only using it when I absolutely want to limit the number of panels.
Note in this case I think gradient fits OK because there is only one value displayed as the line, so you can’t get confused if you need to look at total value or “filled volume”.
Separate Data of Different Scales on Different Graphs
I used to plot Innodb Rows Read and Written at the same graph. It is quite common to have reads to be 100x higher in volume than writes, crowding them out and making even significant changes in writes very hard to see. Splitting them to different graphs solved this issue.
Consider Staircase Graphs
In the monitoring applications, we often display average rates computed over a period of time. If this is the case, we do not know how the rate was changing within that period and it would be misleading to show that. This especially makes sense if you’re displaying only a few data points.
Let’s look at this graph which is being viewed with one-hour resolution:
This visually shows what amount of rows read was falling from 16:00 to 18:00, and if we compare it to the staircase graph:
It simply shows us that the value at 18 am was higher than 17 am, but does not make any claim about the change.
This display, however, has another issue. Let’s look at the same data set with 5min resolution:
We can see the average value from 16:00 to 17:00 was lower than from 17:00 to 18:00, but this is however NOT what the lower resolution staircase graph shows – the value for 17 to 18 is actually lower!
The reason for that is if we compute on Prometheus side rate() for 1 hour at 17:00 it will be returned as a data point for 17:00 where this average rate is really for 16:00 to 17:00, while staircase graph will plot it from 17:00 to 18:00 until a new value is available. It is off by one hour.
To fix it, you need to shift the data appropriately. In Prometheus, which we use in PMM, I can use an offset operator to shift the data to be displayed correctly:
Provide Multiple Resolutions
I’m a big fan of being able to see the data on the same dashboard with different resolutions, which can be done through a special dashboard variable of type “Interval”. High-resolution data can provide a great level of detail but can be very volatile.
While lower resolution can hide this level of detail, it does show trends better.
Multiple Aggregates for the Same Metrics
To get even more insights, you can consider plotting the same metrics with different aggregates applied to it:
In this case, we are looking at the same variable – threads_running – but at its average value over a period of time versus max (peak) value. Both of them are meaningful in a different way.
You can also notice here that points are used for the Max value instead of a line. This is in general good practice for highly volatile data, as a plottings line for something which changes wildly is messy and does not provide much value.
Use Help and Panel Links
If you fill out a description for the panel, it will be visible if you place your mouse over the tiny “i” sign. This is very helpful to explain what the panel shows and how to use this data. You can use Markup for formatting. You can also provide one or more panel links, that you can use for additional help or drill down.
With newer Grafana versions, you can even define a more advanced drill-down, which can contain different URLs based on the series you are looking at, as well as other templating variables:
This list of considerations for designing Grafana Dashboards and best practices is by no means complete, but I hope you pick up an idea or two which will allow you to create better dashboards!