Recently I had to configure some dashboards and alerts on Grafana, but the manual process of creating such a repetitive dashboard is a huge pain. Because Grafana doesn’t support a way to generate alerts dynamically, you will need to set up a dashboard for alerting only, and preferably you use a single graph per specific alert.
I want to specify a single server/instance per graph because it’s easily overlooked and can shoot you in the foot. For example, when you have a graph monitoring the storage of all your servers, and it triggers a warning alert for one instance. Sometimes this situation can take some time to resolve if this instance is a database server, you need to plan for extra capacity, which can take a while to execute to resolve the warning. But if you have other servers passing the warning threshold, you won’t be notified since the alert is already active. So, in a nutshell, I like to use Grafonnet to generate comprehensible and repetitive dashboards quickly.
Great, so what is Jsonnet 😅? Well, Jsonnet is a simple extension of JSON, and Jsonnet defines itself as a data templating language for app and tool developers. Indeed yet another templating language 🎉. Yes, I know but bear with be I promise it makes your life easier.
First of all, you have to make sure you have both Jsonnet and Grafonnet installed. On macOS and using Homebrew, you can
install jsonnet with Homebrew:
brew install jsonnet. The most straightforward approach to get started with Grafonnet
is to clone the repo
git clone https://github.com/grafana/grafonnet-lib.git.
However, when you are ready to set up a project properly, I recommend you check out jsonnet-bundler. Like it’s Ruby counterpart Bundler, jsonnet-bundler is a way to manage jsonnet dependencies like Grafonnet. After installing jsonnet-bundler, these two lines should be enough to get going
jb init jb install https://github.com/grafana/grafonnet-lib/grafonnet
In this example, we will generate a simple dashboard with a graph per server instance to visualize the disk usage and create an alert to notify us when we reach a certain threshold.
First of all, we are going to import a couple of dependencies from the Grafonnet library.
In the first line, we define the main import of our Grafonnet library, all the other are helper variables, which
makes it easier and shorter to work with them, but it’s perfectly fine to use
I’ve abstracted this part into a function so we can reuse it more easily later, here is how that looks like, and I’ll explain it below the code snippet.
To start with lines 1-4, we define a function named
postgresqlAlertTimeseries, which takes two input params
threshold. Next, we define a new
graphPanel with the
db_instance name. For this graph, we use an
InfluxDB target, but Grafonnet ships with support for Prometheus and a few others like Elasticsearch and raw SQL. We
define the measurement
disk-usage and pass a where clause to match our single DB instance.
In the next few lines 15-24, we tweak the axes a little, but then we come to the exciting part defining the alert and the alert condition (lines 25-38). The tricky part is in line 27. You will need to look up the valid ID of the notifications you have configured. If you leave this empty, it falls back to the default notification channels. I looked it up checking an existing dashboard source 😉
Ps: for brevity, I’ve omitted most of our other params we used to tweak the dashboard, for example, to hide the legend, but make sure to check the docs to configure the graph your style.
At this point, it’s pretty straight forward. We define an array variable
db_instances containing the list of DB
instances we are generating a graph for (line 1).
Then we also define a small wrapper function
generateDBPanel to add the grid position to the generated graph. The
gridPos is a necessary argument for the
addPanels method when adding a new graph to the dashboard.
Eventually, we define the essential part, the actual Grafana dashboard, from lines 12-21. Most input parameters speak
for themself, but I will mention the
uid field. If you want to have shareable dashboard links, it makes sense to keep
the UID the same and provide one. Otherwise, Grafana will assign a random UID each time you import it, and you lose the
reference to the dashboard.
And ultimately, we map over our
db_instances array using the Jsonnet standard library
std.map function, it will
generate the graph for each DB instance.
Now we defined the dashboard. The only thing that’s left for us to do is to generate the actual JSON model of the Grafana dashboard using Jsonnet. If you followed the instructions in “How do I get started?" properly, you should be able to run the following Jsonnet command and get a nice JSON output in your terminal.
jsonnet -J . -J vendor/grafonnet-lib example.dashboard.jsonnet
Depending on your Grafana setup, there can be multiple ways to import dashboards, but I will only discuss the manual
approach for now. So you copy the output of the previous command and visit the
https://grafana.example.com/dashboard/import page and follow the step-by-step process.
There is one big caveat, though, when you are defining alerts this way. At the time of writing, there is a known bug grafana/grafana#11419, which prevents alerts from being “activated” during the import process.
So the current workaround means you will need to open the dashboard and save it manually to “activate” the alerts. You can verify the alerts are created by adding checking your dashboard with an [alerts list] panel. But I’ll leave that exercise up to you to define a Grafonnet dashboard with the alert list panel since you all expert in grafonnet now 😜.
- What helped me when I wasn’t familiar with the options or parameters would be to configure a dashboard manually and investigate the JSON model. And try to iterate over my grafonnet definition until I ended up with the same result 😅
- Grafonnet is a superset of JSON, so you can dive into the source code and figure out which options and functions are available. The most used Grafonnet features are also well documented, so it’s worth checking that out.
- Check out the Jsonnet tutorial and standard library documentation to familiarize yourself with Jsonnet.
Fortunately, we are migrating away to a monitoring stack with Grafana, Prometheus, and Alert Manager, so we won’t have those weird quirks to set up alerts soon anymore. However, we will still be leveraging Jsonnet and Grafonnet to generate our dashboards.
The goal is to have dashboards as code so we can use our regular review process when creating or updating dashboards and tracking why changes happened in the first place, unlike the untransparent approach of manually creating and updating dashboards in Grafana, which results in inconsistent dashboards and conventions.
Eventually, we want to reach a point where we have our own set of library components that we can easily use to compose a dashboard. So we have a unified approach across our dashboards and can reuse existing library components without reinventing the wheel every time. I didn’t come up with this idea myself but stole it by investigating the incredible runbook repository of Gitlab’s SRE team, which is open for everyone to read, it’s full of lot’s of good stuff. But you have to make it fit for your organization, of course. Make sure to check it out.
If you made it this far, thanks for reading! Feel free to reach out on twitter if you have any questions or remarks 👋