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 *):
  • Full wildcard check (if one or more * are entered exclusively):
  • Spaces between characters:
    if(match($form.field1$,&quot;\\S\\s\\S&quot;),&quot;null() &quot;,$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!

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.