Let's say that I want a search to run the main search under the time picker selection and then run a join over one day before the time picker range. While this may be possible in a dashboard by passing the search range with $earliest$ and $latest$ (I would be interested in following up on resources along this route, I am looking for the method for implementation at the search line. I tried implementing this token pass over with
|join .. [search earliest=$earliest$-60*60*24 .. ]
treating the token as an epoch value integer in seconds but this returned an error on invalid value for the token.
How do I pass the search time restriction parameters to a subsearch for manipulation?
Try something like this
your base search using timerange picker of search app | join <Join fields> [your subsearch [|gentimes start=-1 | addinfo | eval earliest=info_min_time-86400 | eval latest=info_max_time-86400| table earliest,latest | format "" "" "" "" "" ""] rest of subsearch]
I must ask, what is the deal with the format command and all those sets of double quotes? That's the only part of your solution which does not make sense to me.
This is to format the output of the subsearch into plain key-value pairs e.g. earliest=someepoch latest=someepoch.
Most of the time if you don't specify the format command or specifically format "" "" "" "" "" "", Splunk returns blank value from subsearch. With format "" "" "" "" "" "" works all the time for me.
More details on format command here. http://docs.splunk.com/Documentation/Splunk/6.1.4/SearchReference/Format
by blank value, do you mean something like earliest=null where the filter | search earliest=* does the same function as format?
because | table earliest latest should make a pretty clean key-value pair for passing to the subsearch filter that you setup.
It will show in the job inspector that
subsearch returned " ". As I said this happens to me sometimes only, so just to be sure I add that. Most of the time having just a table commands does the job.
Thank you for the excellent feedback. I will look into that feature a bit more at a later time. I usually find that unexpected "features" are artifacts of other important features, and that understanding how unexpected results are generated increases my power to use the tools at hand to avoid more serious side effects and to implement unexpected use cases.
this will create a race condition for the "All Time" queries, which are discouraged but still an option