Dynamically Validate Splunk XML Dashboard Inputs
Ever felt a need to restrict Splunk searches on your XML dashboards based on a certain criterion? While the input types such as a dropdown or multiselect provide a controlled means of presenting a list of values to choose from, often the use of a text input is necessary to allow the user to manually enter a series of characters. For example, entering a specific src and/or a dest IP address to review communication from and/or to the IP address over a period.
Although the text-box input works well in such scenarios, it does leave the doors wide open for full wildcard searches which may generate excessive search load on the environment, while not delivering the desired output for the user. How can we make this better?
- Perhaps adding some form of input validation could help with this concern?
- Possibly also feedback to the user on why the checks failed.
- What if the searches are blocked from running until the validation criteria are met?
- How about a capability to decide on validation results based on multiple inputs?
Sound interesting? Let’s get started…
While there are no native validation capabilities for the dashboard inputs, we can leverage the power of dashboard tokens to accomplish this. We will also need to dive into the dashboard XML source view to add the tokens and the necessary logic. We will go over a simple use-case of listing sourcetype values for the _internal index with a sourcetype and component filters as text inputs. A full XML code for the example use-case is available towards the bottom of the page.
The Concept
The idea here is to intercept the entered value within each text input and analyse/validate and save the validation result within a related new token. This validated result could be the same as the entered value, if the input was valid; or a null() if one or more of the validation criteria were not met. The validation result tokens are then used within the base or panel searches. A null validation result essentially unsets the token that will keep the search(es) from running.
The Inputs
In our example use-case, we have a set of 2 inputs, the sourcetype and the component fields. For the sourcetype input, the token sourcetype captures the entered value. With each update to the entered value, a corresponding change-condition will be re-evaluated and the result saved to the validated_sourcetype token. The same logic applies to the component input using a component token where the validated result is stored within the validated_component token.
The Validation
The entered value within each input is evaluated using a conditional token eval statement. In this example the validation is looking for at least 4 characters (excluding the *) within any one of the inputs. For example, a sourcetype value of splunk* and a component value of * will pass the criteria of minimum 4 characters in at least one of the two inputs. However, a value of spl* in the sourcetype input and a * in the component input would fail the validation. Notice that both inputs are being evaluated within each of the validated_* tokens. This is to provide a consolidated result looking at the entries in both inputs. Also notice that the validated_sourcetype, validated_component and validation_feedback (see below) tokens are being repeated in both inputs. This is so that with every change to any of the inputs, the validation and feedback tokens are refreshed and provide the relevant output.
The Feedback
Along with the validation exercise, the validation_feedback token analyses the criteria and provides a text-based value if the validation fails, which can be displayed on the dashboard. If the validation passes, the feedback value is null() which essentially unsets the token and hides the feedback panel.
The Search
The search within the dashboard is configured with the validated_* tokens to allow control over blocking the search execution if the validation fails.
The Default Input values, and the Init Tokens
The default/initial values for both inputs are configured as *. To allow evaluation of inputs on dashboard load, the token eval statements configured within the input stanzas have also been added to the <init> tag. This automatically fails validation logic upon dashboard load and displays the feedback message. The initial failure serves as a visual cue for the user to know the input requirements to pass the validation.
Other examples validation criteria
The above scenario looks at a single criterion of the length of the input to be minimum 4 characters. Some other examples of validation criteria could be as follows:
- Leading wildcard check (if a search string is prefixed by a *):
if(like($form.field1$,"*%"),’null()’,$form.field1$) - Full wildcard check (if one or more * are entered exclusively):
if(len(trim($form.field1$,"*"))==0,’null()’,$form.field1$) - Spaces between characters:
if(match($form.field1$,"\\S\\s\\S"),"null() ",$form.field1$)
The token eval does allow a limited set of functions and may require some creative ways to work through more advanced criteria.
Splunk XML Dashboard Example
Here is a sample XML dashboard code that provides a working example of the features we listed above. Happy Splunking!
<form version="1.1" theme="light">
<label>Input Validation Test</label>
<init>
<eval token="validated_sourcetype">if(len(trim($form.component$,"*"))>3 OR len(trim($form.sourcetype$,"*"))>3,$form.sourcetype$,'null()')</eval>
<eval token="validated_component">if(len(trim($form.component$,"*"))>3 OR len(trim($form.sourcetype$,"*"))>3,$form.component$,'null()')</eval>
<eval token="validation_feedback">case(len(trim($form.component$,"*"))<4 AND len(trim($form.sourcetype$,"*"))<4,"Minimum 3 characters are required in at least one of the inputs.",1=1,'null()')</eval>
</init>
<search id="base_search">
<query>index=_internal sourcetype="$validated_sourcetype$" component=$validated_component$ | stats count by index, sourcetype, component</query>
<earliest>-60m</earliest>
<latest>now</latest>
</search>
<fieldset submitButton="false">
<input type="text" token="sourcetype" searchWhenChanged="true">
<label>Sourcetype</label>
<default>*</default>
<initialValue>*</initialValue>
<change>
<condition value="*">
<eval token="validated_sourcetype">if(len(trim($form.component$,"*"))>3 OR len(trim($form.sourcetype$,"*"))>3,$form.sourcetype$,'null()')</eval>
<eval token="validated_component">if(len(trim($form.component$,"*"))>3 OR len(trim($form.sourcetype$,"*"))>3,$form.component$,'null()')</eval>
<eval token="validation_feedback">case(len(trim($form.component$,"*"))<4 AND len(trim($form.sourcetype$,"*"))<4,"Minimum 3 characters are required in at least one of the inputs.",1=1,'null()')</eval>
</condition>
</change>
</input>
<input type="text" token="component" searchWhenChanged="true">
<label>Component</label>
<default>*</default>
<initialValue>*</initialValue>
<change>
<condition value="*">
<eval token="validated_sourcetype">if(len(trim($form.component$,"*"))>3 OR len(trim($form.sourcetype$,"*"))>3,$form.sourcetype$,'null()')</eval>
<eval token="validated_component">if(len(trim($form.component$,"*"))>3 OR len(trim($form.sourcetype$,"*"))>3,$form.component$,'null()')</eval>
<eval token="validation_feedback">case(len(trim($form.component$,"*"))<4 AND len(trim($form.sourcetype$,"*"))<4,"Minimum 3 characters are required in at least one of the inputs.",1=1,'null()')</eval>
</condition>
</change>
</input>
</fieldset>
<row depends="$validation_feedback$">
<panel>
<html>
<p style="color:red">$validation_feedback$</p>
</html>
</panel>
</row>
<row>
<panel>
<table>
<search base="base_search">
<query>| fields index, sourcetype, component, count</query>
</search>
<option name="count">100</option>
<option name="dataOverlayMode">none</option>
<option name="drilldown">none</option>
<option name="percentagesRow">false</option>
<option name="refresh.display">progressbar</option>
<option name="rowNumbers">false</option>
<option name="totalsRow">false</option>
<option name="wrap">true</option>
</table>
</panel>
</row>
</form>
Looking to expedite your success with Splunk? Click here to view our Professional Service offerings.
© Discovered Intelligence Inc., 2024. Unauthorised use and/or duplication of this material without express and written permission from this site’s owner is strictly prohibited. Excerpts and links may be used, provided that full and clear credit is given to Discovered Intelligence, with appropriate and specific direction (i.e. a linked URL) to this original content.
