The last Grafana Boom Table plugin tutorial you’ll ever need

Photo by Stephen Dawson on Unsplash

Although Grafana is robust, fast and easy to set up, it is fairly limited when it comes to working with tabular data coming from lots of different disconnected queries (and their units) or working with data that needs to be visualized in tiny visual elements.

I’m a devops engineer that has a passion for data pipelines, metrics and automation. I am frequently asked to automate a database query, create a parsing script that cleans and converts the output into a Prometheus-friendly format, get the data into Prometheus and finally build some visualizations in Grafana.

I have spent an enormous amount of time in this stack and figured I had reached many levels of enlightenment along the way… Until my boss wanted a “one-stop-shop” dashboard that displayed all of our hosts (50+) OS health, infrastructure health as well as application health metrics. This is not difficult to do if you want to have an enormous dashboard that requires you to scroll or you have to select the host or group of hosts you want to see from the filter menu… No, he wanted it in one easy to see page with no scrolling or filtering. The whole enchilada on the plate.

He pointed me to a page detailing a plugin called “Boom Table”. And this is where my frustration began, for weeks… Not to be a documentation snob but, let’s just say the engineer who wrote it is probably one of the few people on Earth who understands how to set it up on prometheus. Its complexity stems from the fact that it is highly customizable, but at the peril of being well understood enough to implement it easily.

I struggled for several hours with it and then put it off for a week as lots of other tickets were in my face, went back to it, put it off, went back to it, put it off… Until I had no more options, all roads kept leading back to what Boom Table was offering, but kept locked away in limited instruction and little guidance.

My boss wanted an at-a-glance dashboard that delivered the following items from all of our hosts:

• CPU usage (idle percentage)
• Disk usage (on multiple mount points)
• Application processing speed (processing terabytes)
• Check steps of a process (where are we in a multi-step process)
• Database table space
• Things running on schedule (assuming you have a reference schedule)

I cannot show you our production dashboard but I will gladly show AND explain in detail how to set up some of the cool features that make Boom Table highly desirable.

Single element multi-host multi-row panel:

The above is the end result, below is how you get it. Please understand I would like to show you every single option but I only display here the critical items you need to adjust to get this to work. Any items that I didn’t show (various check boxes and such) are not necessary to get this done, feel free to experiment as you like.

Legend field:

In the query section you can place a normal query as you would anywhere else. The key that connects the individual query to the column you want is in the “legend” field. Notice there is this format in the legend:

{{instance}} | CPU

You can choose whatever you like to call the column but the column name for that query is going to be declared after the pipe in this field. As the author of the plug in stated, this was not written for Prometheus, this is one spot where you need to help it along.

Single element multi-host multi-row visualization section screenshots:

Pattern field:

In this section you will place the column name in the “pattern” field as you typed it in the “legend” field in the previous query section. This will connect the data from the query with the pattern of the column name.

Delimiter field:

Stick with the pipe, |

Row and column names:

You will also want to change the settings for row name and column name. Column name is a field that uses the “legend” field as an index. The “{{instance}}” text is _0_ index. The pipe is the delimiter. The text after the pipe is the next index _1_. Programmaticly it’s a genius way to do it, it’s just not that intuitive. The row name in this single element example is left at _1_. Can’t really explain why this works, just does. But the column name is the important thing! The column name has to be declared at _0_, the instance name, in order to have all of your instances appear in the row.

Notice I have another row in the example above, this requires another pattern to pull the column data from the other query into a new row.

The thresholds are extremely important and give you the ability to see at a glance the health of various metrics. You place your threshold like you normally would but you must make sure to check the “Change display value based on thresholds” box and then include the Font Awesome calls in the field that becomes available. These are calls to a font awesome icon, a color, a single element and then a pipe to delimit the next threshold. Use these calls for this field:

_fa-square,green,1_|_fa-square,yellow,1_|_fa-square,red,1_
and for the bottom row:
_fa-square,green,1_|_fa-square,yellow,1_|_fa-warning,red,1_

Now, how do you get rid of the header and first column? In case you missed it in the original instructions, you must click on “options” in the visualization tab and then select “hide first column” and “hide headers”. This will be the final step for you to achieve two rows of just visual elements. You can mouse over and display each metric in a tool tip pop up that the developer has already adorned the panel with!

Battery level and bar graph panel:

Again we have two different yet normal queries, nothing special, only that the “legend” field requires the boom table formatting:

{{instance}} | CPU

Here we see the pattern field again identical to the above “legend” field after the pipe. Notice the row and column fields are now _0_ and _1_. This is different from the previous panel since now we want each row to be a unique “instance” and the column data is no longer each instance but the data itself that is pulled from the _1_ index from the legend field which is equal to “CPU”.

Bar Graph threshold setup:

The thresholds for the bar graph are quite unique and need to be set up as such:

10,20,30,40,50,60,70,80,90

Take this whole chunk and put it in the transform field shown.

_fa-square,green,1_ _fa-square,gray,9_|_fa-square,green,2_ _fa-square,gray,8_|_fa-square,green,3_ _fa-square,gray,7_|_fa-square,green,4_ _fa-square,gray,6_|_fa-square,yellow,5_ _fa-square,gray,5_|_fa-square,yellow,6_ _fa-square,gray,4_|_fa-square,yellow,7_ _fa-square,gray,3_|_fa-square,red,8_ _fa-square,gray,2_|_fa-square,red,9_ _fa-square,gray,1_|_fa-square,red,10_ _fa-square,gray,0_

Battery level threshold setup:

50,70

Take this chunk and place it in the transform field as above:

_fa-battery-full,green_ _value_|_fa-battery-quarter,yellow_ _value_|_fa-battery-empty,red_ _value_

Different queries as columns panel

Sometimes you just want the ease of throwing lots of weird disconnected queries into their own column on a single pattern along with colored thresholds. Boom table works much quicker and better-er than the stock Grafana table setup, like, night and day.

Here we see 4 very unique queries and how they are declared as unique columns using the “legend” field.

{{instance}} | DiskAvailable

The setup by now should be very easy for you, this time we have 4 queries, 4 column declarations and now we see 4 patterns. Each query gets its own pattern since it needs its own thresholds and column declaration.

Here is another example of another pattern in that list of 4 queries.

So… My greatest hope at this point of the tutorial is that you have this up and running and you’re able to apply this powerful plugin to your own metrics and create some super impressive, super unique dashboards!