Imagine setting different tokens with specific values based on where users click on a table or the value they clicked compared to other search results. 

Join me as we dive into the deep end of Splunk Drilldowns.

What is a Splunk Drilldown?

Splunk drilldowns add additional functionality to dashboards by allowing users to see the query powering a particular visualization when they click on it. 

Alternatively, specific drilldown actions, like setting a token, can be defined. To take drilldowns a step further, it’s possible to use conditional elements <condition> and <eval> in a Splunk drilldown. Splunk Admins can define multiple different possible sets of drilldown actions like XML syntax to conditionally populate tokens and link to new pages to create an even more dynamic experience for their Splunk users.

The Basics of Splunk Drilldowns

The first thing you need to know for conditionals and drilldowns is where they go. To use conditionals, Splunk Admins will need to get familiar 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.

The Elements of Splunk Drilldowns

Conditional Expressions and the <condition> Element

The <condition> element wraps the 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. Before you ask, no, you cannot nest <condition> elements, but I like where your head’s at.

Tokens

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 of these tokens will be extremely useful as we add condition statements to our drilldowns, so keep this knowledge handy.

XML Limitations in Drilldowns

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. The same goes for quotes (“) or ampersands (&). Check the table below for reference, but this will help you out later when writing out conditional expressions.

Character	Splunk XML Approved Replacement
>	>
<	&lt;
>=	&gt;=
<=	&lt;=
“	&quot;
&	&amp;

With that out of the way, let’s try a drilldown together.

 

How to Use a Perform a Splunk Drilldown

Conditional Drilldowns Based on Columns Clicked

Let’s set the scene: You have an amazing table that tracks the 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? 

Use a conditional drilldown based on columns clicked.

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 comparing it 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.

Splunk Pro Tip: This type of work can be a considerable resource expense when executing it in-house. The experts at Kinney Group have several years of experience architecting, creating, and solving in Splunk. With Expertise on Demand, you’ll have access to some of the best and brightest minds to walk you through simple and tough problems as they come up.

See for Yourself

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.

Everyone knows that if the ID is less than or equal to 4000 then it’s BAD and if it’s above 4000 it’s GOOD. But we are kind Splunk Rulers Admins and have gone mad with power want to help our colleague out. So, let’s use conditions 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 it’s 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 executed with no issues, giving your users the cool dashboards they need.

Condition Drilldowns Based on Evals

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 to an example.

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

1. IfTest: 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”.
2. Case: 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.

If you found this helpful… 

You don’t have to master Splunk by yourself in order to get the most value out of it. Small, day-to-day optimizations of your environment can make all the difference in how you understand and use the data in your Splunk environment to manage all the work on your plate.

Cue Atlas Assessment: a customized report to show you where your Splunk environment is excelling and opportunities for improvement. Once you download the app, you’ll get your report in just 30 minutes.