Skip to content
Article

Mastering Splunk Drilldowns With Conditions

Splunk Dashboards really start to shine after empowering Splunk Users with drilldowns. With drilldowns, users can click on any number or visual that suits their fancy and by default see the query powering it. Alternatively, specific drilldown actions can be defined, such as setting a token. Of course, there is the next level as well. By using the conditional elements <condition> and <eval> in their Splunk drilldowns, Splunk Admins can define multiple different possible sets of drilldown actions, creating a dynamic experience for users.

Splunk Admins can utilize Splunk’s XML syntax to conditionally populate tokens, link to new pages, and more! Imagine setting different tokens with specific values based on where users click on a table or based on the value they clicked compared to other search results. Join me as we dive into the deep end of Splunk Drilldowns!

The Basics

The first thing you need to know for conditionals and drilldowns is where they go. To use conditionals, Splunk Admins will need to get intimate with the XML view of their dashboards, since these features are not found on the Splunk Dashboard UI. So, create a dashboard, create a table with some good test data, and follow along!

This is the basic outline for where conditional elements live.

Conditional Expressions and the <condition> Element

This element wraps your drilldown actions, allowing Splunk Admins to define conditions using either the matchattribute to use an eval-like Boolean expression, or the field attribute to simply check the field that was clicked. If you have more than one condition, you can stack <condition> elements in the drilldown section. Only the first condition evaluating to true will perform its actions. Having a <condition> element at the end with no condition specified will let you define actions to perform when no condition has been met. Unfortunately, no, you cannot nest <condition> elements, but I like where your head is at!

Conditional attributes, like drilldown actions, can utilize tokens, including Splunk’s native ones. These come in two varieties, drilldown tokens and search job tokens. Mastering these both, and knowing where to go when you need guidance, will do wonders for making drilldowns work for you.

Here is an easy to reference picture that outlines how all these native tokens populate when a user clicks the circled “Login” in the following table:

If you are working with other visualizations, such as bar charts, check Splunk’s documentation for more direction! All these tokens will be extremely useful as we add condition statements to our drilldowns, so keep this knowledge handy!

Finally, Splunk XML has its own rules that may trip up newcomers. You cannot put down greater than (>) or less than (<) signs willy-nilly into the XML. Same goes for quotes (“) or ampersands (&). Check the table below for reference, but this will help you out later when writing out conditional expressions!

CharacterSplunk XML Approved Replacement
>&gt;
<&lt;
>=&gt;=
<=&lt;=
&quot;
&&amp;

With that out of the way, let’s get cracking!

Conditional Drilldowns Based on Columns Clicked

Let’s set the scene, you have an amazing table that tracks latest actions on your website.

You want users to be able to click on a User in the User column to see more historical actions captured from that user, BUT if the user clicks on something in the Action column (like “Login”), you want to show all those actions regardless of users. Finally, if they click on an ID, don’t do anything! How can you make this easy to use for your users, so they are none the wiser? 

By using conditions!

This code snippet shows you 3 interesting things! 

  1. When using the match attribute to compare two strings, we can inject the field name using the $click.name2$ token, and we must use &quot; to wrap non-token strings. .
  2. You can use the field condition to easily do the above with built in functionality. We are using it to mimic the first condition but with comparing to the Action column instead.
  3. Finally, we have a condition match=”1=1”, this illuminates that conditions run in placement order, so when a user selects a cell, the first condition is performed, and if it fails, then the second field action tested, and if it fails, then finally this 1=1 would function like the “else” of the if statement. If any of the tests succeed, then no more conditions are executed.

With this code in place, if a User clicks on UserBravo in column User, then token user would be set to “UserBravo”, and nothing else. If a User clicks on Login in the Action column in the first row, then actiontracker would be set to “Login”, and nothing else. Finally, if a user selects 3333, then nothing happens! Amazing!

Condition Drilldowns Based on Cell Content

Wow, everyone was impressed with your snappy Splunk dashboard, they just can’t get enough! But Fred from IT has a request to turn it from awesome to legendary. You see, he can’t easily remember what those IDs in the far-right column mean. 

Crazy right? Everyone knows that if the ID is less than or equal to 4000 then its BAD and if its above 4000 its GOOD. Basic business Fred! But we are kind Splunk Rulers Admins and have gone mad with power want to help our colleague out. So, let’s see what conditions can do for comparing values!

Remember, as we previously discussed, conditions work in order from top to bottom, and if one conditional ‘passes’ then the others are ignored. Using this, we have created conditionals using match that achieves 3 great things!

  1. Ensures, as we did before, that we are clicking on something in the ID column
  2. Uses Boolean ‘AND’ to join the column name checker with the comparison $click.value2$ [>/<=] 4000. This compares the value we click with the number 4000.
  3. Ends with a conditional catch all of 1=1 that unsets the id token. 

With this code in place, when Fred clicks on 3333, it will fail the first condition, but succeed on the second since its both in the ID column and less than or equal to 4000, setting the id token to “BAD”. When Fred clicks on Login, then the id token gets cleared since the final conditional executes. Finally, when Fred clicks on 5555, then the id token will be populated with “GOOD” since he passes the first conditional. 

You can combine this code with the code from the previous example to have all features execute with no issues, giving your users the cool dashboards they deserve!

Evals, as a Treat

To close out, let’s unveil an underutilized condition option, the <eval> element. Now this won’t revolutionize your dashboards on the front end per se, but they can help Admins craft better drilldown logic. Unlike the <condition> element, the <eval> element is a type of drilldown action, meaning it can be used inside of, or instead of, <condition> blocks! Let’s just jump right to an example!

This code snippet shows two eval commands slipped right into your drilldown xml block. Let’s break down each one!

The ifTest block starts off with an if statement and works like any normal Splunk eval command. Just like an eval command, you can add eval functions such as tonumber and isint, and then we do a strict number comparison to see if we clicked on the magic “BOOM” number. This if statement is checking if the value being clicked is a number, and if it’s 5555. If it passes both, thanks to the AND, the token gets assigned “BOOM”. If not, then “UNBOOM”.

The second statement uses if’s partner in crime, case! With case logic, the system evaluates a logical statement, and if it evaluates to true, utilizes the next parameter as the return value. If the logical statement is false, then it moves on to the next statement. In our case here, it is validating the clicked value to see if it’s NOT a number. If it’s NOT a number, it sets the caseTest token to “WORD”. If it is a number, then the next logical statement checks to see if it’s 5555, and if it is, sets it to “BOOM”. Finally, if it’s neither of these things (like 3333), then nothing happens!

A neat thing about eval conditions is that all of them execute in parallel. Instead of the other conditions where they trigger one after another until one succeeds, all evals trigger with each click. This enables Admins to set multiple tokens easily with one click!

Let’s Wrap Up!

I hope with the previous examples and guidance you can see how pairing drilldowns with conditions can empower your Splunk dashboarding and give you more toys to play with! As a closing thought, a lot of examples given here use $click.value2$ and token manipulation. This was chosen for simplicity, but all these methods can utilize any of the tokens populated as described in The Basics above and could use drilldown links to other dashboards or websites as well! So, get creative, and go build something awesome!

Author