search with sub search doesnt get the correct defined time range

[splunkinator53]

Hey,  lately i was working on an SPL and wondered why this aint working. This is simplified

index IN(anonymized_index_1, anonymized_index_2, anonymized_index_3, anonymized_index_4) 
    NOT index IN (excluded_index_1) 
    earliest=-1h@h latest=@h 
    EventCode=xxxx 
    sourcetype="AnonymizedSourceType" 
    NewProcessName IN (*)
[| tstats count 
    where index IN(anonymized_index_3, anonymized_index_1, anonymized_index_4, anonymized_index_2) 
        NOT index IN (excluded_index_1) 
        earliest=-1h@h latest=@h 
        idx_EventCode=xxxx 
        sourcetype="AnonymizedSourceType" 
        idx_NewProcessName IN(*) 
    by idx_Field1 _time idx_Field2 host index span=1s 
    | search anonym_ref!="n/a"
        OR (idx_NewProcessName IN (*placeholder_1*, *placeholder_2*) AND (placeholder_field_1=* OR placeholder_field_2=*)) 
]

When I run this SPL, I’ve noticed inconsistent behavior regarding the earliest and latest values. Sometimes the search respects the defined earliest and latest values, but at other times, it completely ignores them and instead uses the time range from the UI time picker.

After experimenting, I observed that if I modify the search command to combine the conditions into one single condition instead of having two separate conditions, it seems to work as expected. However, I find this behavior quite strange and inconsistent.

I would like to retain the current structure of the search command (with two conditions) but ensure it always respects the defined earliest and latest values. If anyone can identify why this issue occurs or provide suggestions to resolve it while maintaining the current structure, I’d greatly appreciate your input.

[splunkinator53]

-

[PickleRick]

OK. Firstly, this is something you should use job inspector for and possibly job logs. You might also want to just run the subsearch on its own and see what results it yields.

Having said that, some remarks:

1. Unless your "index IN (...)" contains some wildcards, the exclusion following it doesn't make sense.

2. "NewProcessName IN (*)" is a very ineffective approach.

3. Your subsearch restults will get rendered as set of OR-ed composite AND conditions. Each of them will have a specific _time value. So while your main search contains earliest/latest, your subsearch will either return empty conditions set or will tell Splunk to search only at specific points in time at full seconds. If your data has sub-second time resolution, you're likely to not match much.

4. Your subsearch will actually not yield any results at all since you're doing tstats count over some fields but then searching through tstats results using a field which is not included in those results.

So either you've trimmed your search too much while anonymizing it or it's simply broken.

[splunkinator53]

Thank you very much for your feedback! I apologize for the anonymized query; I realize some parts were trimmed incorrectly.

Regarding Point 3:

I aim to have both the main search and the subsearch use the same earliest and latest time fields. The idea is that the tstats command serves as a pre-filter, while the base search is used to retrieve the raw events.

The query I wrote generally works as expected, but sometimes it fails to correctly use the specified earliest and latest. For instance, during one test, it returned the correct time range, but when tested an hour later, it didn’t align with the specified time.

Interestingly, I noticed that tweaking the search command sometimes resolves this issue and ensures it searches within the correct time range. 

[PickleRick]

You have earliest and latest explicitly set in your searches so they should be used. Again - check the job inspect and job logs to see what searches are being run and how. (The search contents, the time ranges, the expanded subsearch...).