startminutesago/endminutesago vs earliest/latest

[southeringtonp]

I know that from version 4 onward, use of the earliest and latest time parameters are preferred over the older startminutesago and related keywords, which appear to be deprecated.

Are there any differences in the way the two approaches are handled internally?

I'm wondering especially in the context of scheduled searches, where the actual time at which a search is kicked off may vary slightly from the time at which it is nominally scheduled (e.g., due to many searches scheduled at the same time).

[jrodman · Accepted solution]

Earliest and latest can be provided out-of-band to the splunk engine, which matters if you're using REST, but not to most users. Earliest and latest are quite a bit more flexible in their behavior, it's common to want to snap the time ranges to day boundaries or similar which is clumsy with the old terms. Earliest and latest expressions can be a bit trickier to read though.

The scheduler runs searches with a now value, now=1234777433 or whatever unix seconds-from-epoch time the search was configured to be run at, so it will consider all relative times to be from that scheduled time, not at the moment it executes.

However, in the case of delays (when there are more searches than can possibly be run) not all timeslots for a search occur. This may appear to you a bit differently if you use the snapping behavior for earliest/latest and not for startminutesago.

Incidentally, in 4.1 there are status dashboards for the scheduled searches to give you a window into your scheduled search load and whether they are all happening as expected. This allows you to prune searches you don't really need or increase search capacity (or raise the capacity allotted to scheduled searches over interactive searches).