Splunk Search

Using token in query where token is evaluated in the query itself

denzelchung
Path Finder

I have the following query to be performed, where "STRING" is replaced across different queries. Is there a way to replace the STRING with a token and make it such that only 1 query is performed?

host="$host$" "STRING" | sort -_time | head 1 | eval time = _time
| eval sender = "STRING" 
| table sender time
...
host="$host$" "STRING2" | sort -_time | head 1 | eval time = _time
| eval sender = "STRING2" 
| table sender time
...
host="$host$" "STRING3" | sort -_time | head 1 | eval time = _time
| eval sender = "STRING3" 
| table sender time
...

Simplify to be something like this where $sender$ is set to a dynamic value, but the following doesn't work.

<query id="masterQuery">
    host="$host$" "$sender$" | sort -_time | head 1 | eval time = _time
    | table sender time
</query>
...
<query base="masterQuery"> | eval sender = "xx" </query>
<query base="masterQuery"> | eval sender = "yy" </query> 
Tags (3)
0 Karma
1 Solution

VatsalJagani
Super Champion

Hi @denzelchung,

If you want your search to run only once and do further processing you can do with basesearch, where you add dynamic search content in child search rather than in base-search, hence your base search will be executed only once.

<query id="masterQuery">
     host="$host$" | sort -_time | head 1 | eval time = _time
     | table sender time *
 </query>
 ...
 <query base="masterQuery"> | search "$sender$"| eval sender = "xx" </query>
 <query base="masterQuery"> | search "$sender$"| eval sender = "yy" </query>

But, as we are adding search command later most of the time searching all three queries requires less time than this base search as this base-search does not have more search criteria and will return lots of result to process.

So choose your approach wisely. Hope this helps!!!

View solution in original post

VatsalJagani
Super Champion

Hi @denzelchung,

If you want your search to run only once and do further processing you can do with basesearch, where you add dynamic search content in child search rather than in base-search, hence your base search will be executed only once.

<query id="masterQuery">
     host="$host$" | sort -_time | head 1 | eval time = _time
     | table sender time *
 </query>
 ...
 <query base="masterQuery"> | search "$sender$"| eval sender = "xx" </query>
 <query base="masterQuery"> | search "$sender$"| eval sender = "yy" </query>

But, as we are adding search command later most of the time searching all three queries requires less time than this base search as this base-search does not have more search criteria and will return lots of result to process.

So choose your approach wisely. Hope this helps!!!

denzelchung
Path Finder

Thank you! This is exactly that I'm looking for! I couldn't figure out how to do it.

niketn
Legend

@denzelchung it would be better if you explain what is the data you have and what is the output required. Seems like you are complicating the use case.

What is the reason to perform several queries, do you want to have separate visualization for each result? Have you tried Trellis Layout in this case?

____________________________________________
| makeresults | eval message= "Happy Splunking!!!"
0 Karma

denzelchung
Path Finder

Hi @niketnilay, I am trying to evaluate sender to be a fixed string. I have over 10 of these strings and I want 10 different individual visualization.

I don't think Trellis Layout fits my case as they cannot be split by sourcetype, host, etc.

0 Karma
Get Updates on the Splunk Community!

Build Scalable Security While Moving to Cloud - Guide From Clayton Homes

 Clayton Homes faced the increased challenge of strengthening their security posture as they went through ...

Mission Control | Explore the latest release of Splunk Mission Control (2.3)

We’re happy to announce the release of Mission Control 2.3 which includes several new and exciting features ...

Cloud Platform | Migrating your Splunk Cloud deployment to Python 3.7

Python 2.7, the last release of Python 2, reached End of Life back on January 1, 2020. As part of our larger ...