Early in this short series, we talked about SWQL and how to format queries to bring information out of the SolarWinds Orion Platform and making it work for you and your users/customers. If you’re just joining us, I’d recommend reading up on that post before moving forward since I’m building directly on those notes.
SolarWinds made it easier to manage your dashboards by introducing a “Manage Dashboard” menu item located under the “Settings” menu. When you go to the page, you’ll be presented with “Add modern dashboard” and “Add classic dashboard.”
Like all things, choosing a name is important, and renaming a dashboard after creation is non-trivial, so take a moment to think on your name before getting started. If you don’t like the name, you can always create a new one and import widgets from your old (bad) name. For this example, we’re going to call our dashboard “Production Servers Summary.” Once you give it a name, you can either stop there or open immediately to start crafting it.
If you elect to edit it (and you should), the first thing you will notice are two buttons in the upper-right corner.
And once you drag the box and position it on the grid (more to follow on that later), you’ll get a fresh “New Widget.” This is just a placeholder for the content, and you’ll need to click on “Finish configuring” to select what the widget will present.
There are four basic types of widgets:
- The Proportional Widget gives you nice little charts.
- The Table widget presents your information in quick and easy-to-consume tables.
- The KPI widget displays numbers in a pleasing, easy-to-comprehend format.
- The Timeseries widget embeds a PerfStack chart directly in your dashboard.
For the first example, we’ll refer to my original example of looking at the CPU Load for the nodes in your environment, so we’ll select the Table Widget by selecting the widget and then clicking on “Customize.” From this screen we can enable searching, sorting, and change the refresh rate if you need. The “Sorting” feature cannot be selected until you complete the data model, so for the time being, give the widget a name, and we’ll return the other options in a few moments. Now go to “Data Model.” You’ll see that you can select building the data model by using the graphical query builder or by using a hand edited SWQL query.
I (personally) tried the graphical builder but felt it a little slow considering I could use SWQL Studio for most of the heavy lifting and prep work. And if you’ve read this far, let’s just keep going with SWQL.
To use the SWQL editor, click on Edit and enter your query. You can type it in, but I prefer pasting in a known-valid query (as tested in SWQL Studio).
The results look like this after you click “Show records.”
If you notice I added a line to my SELECT statement. This provides the URL that will link the node in the table directly to the node details page because we’re building a high-level overview, and this allows your users to dig deeper into any “troubled nodes.” Go ahead and save the model.
The builder will automatically build the table using the columns from your select statement, but let’s face it, that’s not very sexy at all, so let’s spice it up. Start by deleting Column 2 – CaptionURL. We'll use this information by formatting the first column (Node Name) to use a link. There are other options as well, but for this table all I want is the link, so that’s what I’ll use.
Now look at the CPU Load column; it’s just a number. Raw numbers are B-O-R-I-N-G. Thankfully, it’s easy to jazz it up. Under “Format,” you’re given several options.
For all of these, it takes the information pulled by your query and adds information from your settings such as “Thresholds” to change things up. And for this example, let’s select “Threshold Value.” If you’re following along, the result should update with a sparkline showing the load.
“But wait Ben, you can’t read the CPU Load at all, that practically the opposite of sexy.” You’re right, and it’s not. But this is when you go to the bottom-right corner of the widget and resize it. As you drag the box, a blue box will appear ahead of your mouse. This shows the upcoming size of the widget. Grabbing the widget on the dotted vertical pipes near the title allows you to drag it around to other locations on the page.
Modern Dashboards are laid out in a grid pattern (unlike Classic Dashboards, which are based on column architecture). Much like icons on your smartphone, the widget will “snap” to the first free position on that grid and must be sized based on that position. Widget sizing has improved greatly since the first release of Modern Dashboards. I’m running Orion Platform 2020.2.6, so I get all the benefits of more recent releases. (If you are able, I’d strongly encourage you to go to your Customer Portal to review the release notes and upgrade to the newest release.)
But hey, look at that, now not only do you have some good data showing but it looks good, too. Even this simple widget tells a good story. You can hover over the Node Name and see some of the critical information for the node and access commands or click and go to the node’s detail view—all things we want in a convenient dashboard.
You can also add a URL to the overall widget itself to take users to another useful screen. For example, you can add a widget showing the status of all your NetPath probes. By clicking on the widget’s title, it can take you to the NetPath page for more details. Remember, the goal is to reduce the number of clicks and confusion by giving our users the information they need as fast as we can.
This is the basics of building a table widget. You can add other information or whatever is requested, but now you’re well on your way to building a beautiful, eye-catching dashboard. Let’s move onto the other widget we’ll be using in this example: the Proportional Widget. This is where the information on using COUNT will be useful.
Within the options of this widget, you’ll see four chart types: Pie, Donut, Vertical Bar, and Horizontal Bar. I highly recommend looking at the data and selecting the best chart type to display this information. The histogram options are good for some things, but for this example I’ll use a donut chart. Seriously, who doesn’t enjoy a good donut?
This is where giving the values in your query-friendly names really works in your favor. After you build the data model, you’ll need to tell the widget how to use this information. Which for our example will look like this:
Resulting in hopefully a big blue donut . But what does it mean? No one’s going to know what blue means. All it tells me is I have eight things. Well, let’s format the data by changing “Custom” to “Orion Statuses.” Now look, you hopefully have a nice green circle, and the legend will tell you green is “up.”
The modern dashboards provide you with one more widget to provide a simple element: the KPI widget. A KPI widget will take a query and return the number. While there are other functions like MIN, MAX, and AVG; for the point of this document, I’m trying to keep things simple because this is meant to be the first step in you mastering your SWQL Fu.
In this example, I wanted to get a count of the number of applications I’m monitoring and count them by their status. Unlike the proportional widget, the KPI widget doesn’t provide you with a direct comparison unless you add a secondary value. You can’t set up one value to show you the count of multiple things. In the following example, I’ve set up a KPI widget to return two values, one showing the number of UP applications and one showing the number of DOWN applications.
The query for these is very straightforward. It uses the COUNT function to return the number of Application Checks that are set up and a WHERE clause to limit the number of things it counts by the status. So, as you can see, in my home lab, I have eight application monitors configured, all of which are up. You can set up custom thresholds to change the color of the KPI widget based on the number returned by the query.
And those are the basics. Now we can use these few widgets to build a beautiful dashboard. The following screenshot comes from my production system; names, locations, and specific details have been redacted.
Next up is going to be Part 3, where we’ll discuss some limitations of Modern Dashboards as well as the feedback I received from my supervisor, director, and other key stakeholders as I started to introduce Modern Dashboards into our production environment.
Have you built any Modern Dashboards you’d like to share? I’m always looking for inspiration and some of the best has come from the THWACK community, so I’d love to see what you all have done with this new way of presenting data.