Splunk Search

startminutesago/endminutesago vs earliest/latest

southeringtonp
Motivator

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).

1 Solution

jrodman
Splunk Employee
Splunk Employee

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).

View solution in original post

jrodman
Splunk Employee
Splunk Employee

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).

Get Updates on the Splunk Community!

Index This | I am a number, but when you add ‘G’ to me, I go away. What number am I?

March 2024 Edition Hayyy Splunk Education Enthusiasts and the Eternally Curious!  We’re back with another ...

What’s New in Splunk App for PCI Compliance 5.3.1?

The Splunk App for PCI Compliance allows customers to extend the power of their existing Splunk solution with ...

Extending Observability Content to Splunk Cloud

Register to join us !   In this Extending Observability Content to Splunk Cloud Tech Talk, you'll see how to ...