Your stats command is not syntactically correct so it will not work anyway. But that's another problem.
The most important thing is that whenever you can, limit your events as early as you can. And time limiting is the most effective way to speed up your search. So it's way more effective to do a search for last 15 minutes and calculate something from that set of data than running a search over "All time" only to limit the results in the last step.
But sometimes of course limiting results by some time-related field is desirable.
In general, when working with timestamps in Splunk, unless you're doing some very unusual magic, you manipulate so called epoch or unix timestamps - numbers containing numbers of seconds since midnight Jan 1st 1970. So it's only natural to think in seconds when doing any timestamp manipulation comparison.
So you usually do it like this - if you want only those results in which a, let's say, start_time field is between 2 and 3 days ago you simply add
| where start_time>now() - 3*86400 AND start_time<now() - 2*86400
Of course you must have the field start_time as the numerical unix timestamp so if needed you have to parse your event's field with strptime()
But it's a constant 600 seconds. Where's the catch? 🙂
I dont need to convert now() in minutes?
And how to apply it in my search
Like this?
| stats dc(x) where delta < 10
Your stats command is not syntactically correct so it will not work anyway. But that's another problem.
The most important thing is that whenever you can, limit your events as early as you can. And time limiting is the most effective way to speed up your search. So it's way more effective to do a search for last 15 minutes and calculate something from that set of data than running a search over "All time" only to limit the results in the last step.
But sometimes of course limiting results by some time-related field is desirable.
In general, when working with timestamps in Splunk, unless you're doing some very unusual magic, you manipulate so called epoch or unix timestamps - numbers containing numbers of seconds since midnight Jan 1st 1970. So it's only natural to think in seconds when doing any timestamp manipulation comparison.
So you usually do it like this - if you want only those results in which a, let's say, start_time field is between 2 and 3 days ago you simply add
| where start_time>now() - 3*86400 AND start_time<now() - 2*86400
Of course you must have the field start_time as the numerical unix timestamp so if needed you have to parse your event's field with strptime()
@jip31 - Is there a reason why you cannot use timerange as last 10 minutes only?
Is there any specific reason you want to use it in the search to calculate and filter by delta?
Can you please explain the requirement bit more?
Hi
Yes because I already use an earliest and latest command in my search in ordre to filmer events between 7h and 18h
So in this slot of time only i need to count events which only existe sin ce 10 minutes or less