In Splunk _time is the most important field of them all 😉 It's the single most effective method of speeding up your search - by narrowing your timerange. And the process of onboarding new source should include analysis where should Splunk get the event's timestamp (the _time value) from. Sometimes the appropriate timestamp is the moment when forwarder receives the data (for example when a log file doesn't contain any time-related information whatsoever). Sometimes the time is explicitly given in a "header" file of the event (like with most syslog messages). But sometimes the event can contain many different bits of time-related info. For example you might have a transaction start, end and a request timestamp along with a timestamp from the logging system. All within the same event. And it's a part of the onboarding process to decide which of these timestamps is the "true" event's timestamp and which should be extracted as the _time field. This will be the one that events are by default ordered by and it's the one that you can easily limit search timerange with timepicker or earliest/latest condition. And this one works very fast. You can have also other time containing fields extracted but you can't easily limit your search the way you do with _time. With those fields you have to search for some superset of your events and filter it by the | where clause.
... View more