All Apps and Add-ons

Custome time "Now" passes nothing

kmattern
Builder

I have a search that looks, in part, like this:

sourcetype=iis cs_uri_stem=*$pub$*.pdf*
earliest=$search.timeRange.earliest$
latest=$search.timeRange.latest$   
| dedup _time, cs_username

All the parameters pass correctly except when the user selects Custom time from the Time picker and clicks on Now. In that event nothing is passed and the search looks like this:

sourcetype=iis cs_uri_stem=*01-c35caa-1*.pdf*
earliest=1393394400
latest=   
| dedup _time, cs_username

I'm not using a Redirector or a URLLoader as all this is happening in one panel.

Why is Latest showing as nothing/Null?

1 Solution

sideview
SplunkTrust
SplunkTrust

1) The best solution here is to just not use the earliest="" and latest="" searchterms in the search at all. the searchterms for the all-time timerange are technically empty. ie the "all time" search is a lack of time terms.

If you just dont put those terms into the 'search' param of the Search module, the module will pick them up and use them to dispatch the search. Don't use an earliest param or latest param either.

2) The only reason you would ever need the legacy searchterms in there explicitly like that is if you were in a subsearch and you needed the subsearch to run over a different timerange than the outer search. If that's the case here, let me know and I'll update my answer.

View solution in original post

martin_mueller
SplunkTrust
SplunkTrust

Instead of this

[ search * | head 1 | eval ... ]

You may want to use this:

[ stats count | eval ... ]

That way you don't even need to touch all default indexes to grab that one event.

sideview
SplunkTrust
SplunkTrust

1) The best solution here is to just not use the earliest="" and latest="" searchterms in the search at all. the searchterms for the all-time timerange are technically empty. ie the "all time" search is a lack of time terms.

If you just dont put those terms into the 'search' param of the Search module, the module will pick them up and use them to dispatch the search. Don't use an earliest param or latest param either.

2) The only reason you would ever need the legacy searchterms in there explicitly like that is if you were in a subsearch and you needed the subsearch to run over a different timerange than the outer search. If that's the case here, let me know and I'll update my answer.

kmattern
Builder

Nick, you're right. I think I duplicated the top portion of an earlier search that drilled down to another search and used them to pass the time ranges. I didn't need them in this search.

I removed them from the search.

0 Karma

somesoni2
Revered Legend

one workaround will be to use below instead of phrase 'latest=$search.timeRange.latest$'

[* | head 1 | eval latest=coalesce($search.timeRange.latest,now()) | table latest]

0 Karma

theouhuios
Motivator

I think that's because it makes it a real time search where the time of the dispatch is considered as the earliest timestamp and increases the data as the data comes in. So there is no latest value for it as time keeps increasing.

0 Karma
Get Updates on the Splunk Community!

Introducing Splunk Enterprise 9.2

WATCH HERE! Watch this Tech Talk to learn about the latest features and enhancements shipped in the new Splunk ...

Adoption of RUM and APM at Splunk

    Unleash the power of Splunk Observability   Watch Now In this can't miss Tech Talk! The Splunk Growth ...

Routing logs with Splunk OTel Collector for Kubernetes

The Splunk Distribution of the OpenTelemetry (OTel) Collector is a product that provides a way to ingest ...