Does anyone know of a way to reverse the order of the automatic start/end values used for bucket creation when working with timechart (or other similar commands)? For example, if I have a timechart with a span of 7 days and a search window of 30 days, the 7-day-buckets start with the oldest data and move forward to the most recent results, resulting in the most recent bucket having a small sample-size; maybe only two days, or three days, rather than the full seven.
It seems reasonable to me that most people would care about the more recent data and less about the oldest (incomplete) data and therefore would have an option to adjust this behavior and choose to start at now() and work backwards rather than earliest() and working forward.
Am I missing something? Any tips or tricks? I asked support and was basically told this is by design with no real workaround. That doesn't seem right to me.
Oh, and again, this is not necessarily limited to timechart, but that's where I run into this frustration the most and where I imagine it is the .
You probably need to do your own bucketing e.g.
| addinfo
| eval daysago=floor((relative_time(info_max_time,"+1d@d")-_time)/(60*60*24))
| eval weeksago=floor(daysago/7)
| eval _time=relative_time(info_max_time,"+1d@d")-(weeksago*60*60*24*7)
This buckets _time based on the end of the last day in the time period (which actually equates to the beginning of the next day) and then every seven days prior to that point.
You may still experience some oddities around how this is displayed with standard charts as _time is treated as a special case and even though the dates aren't Mondays, the X-axis may still be marked using the Monday as the date displayed. You can get around this by formatting _time as a different field and using that instead.
You probably need to do your own bucketing e.g.
| addinfo
| eval daysago=floor((relative_time(info_max_time,"+1d@d")-_time)/(60*60*24))
| eval weeksago=floor(daysago/7)
| eval _time=relative_time(info_max_time,"+1d@d")-(weeksago*60*60*24*7)
This buckets _time based on the end of the last day in the time period (which actually equates to the beginning of the next day) and then every seven days prior to that point.
You may still experience some oddities around how this is displayed with standard charts as _time is treated as a special case and even though the dates aren't Mondays, the X-axis may still be marked using the Monday as the date displayed. You can get around this by formatting _time as a different field and using that instead.
I will mark this as the (workaround) solution for now. If another trick/solution comes in with better direction I think I can update the solution later, but otherwise your answer is I think the most practical response.
Thanks to you @ITWhisperer and @yuanliu also.
Ouch. Thanks for the input. That's more or less the direction I started going but it's painful.
Not sure if this is less painful, just simpler
| addinfo
| eval offset=strftime(info_max_time, "%w")
| eval _time = _time + (6 - offset) * 86400
| timechart span=1w@w ``` or bin span=1w@w _time ```
Similar but different, the additional ideas help. Thanks for the input, and yes that's simpler. I guess I should put in an ideas request to add a param/option to the bucket, or timechart, or anything with a span parameter to allow reversing the bucket chronology. I just really was hoping there was a lesser known command or trick to get this working without hacking _time.
I created an IDEAS post, if anyone is interested in voting on it. Hopefully my proposal is clear enough to get the idea across.
Option to Reverse Chronological Order of Span Buckets | Ideas (splunk.com)
Agreed. When I first saw it, I was absolutely convinced that this could be achieved with manipulation of snap-on options but it didn't work out as I had hoped.
Meanwhile, if you are willing to force your users' hands - with dashboard selectors, for example, you could do something like "earliest=-3w@+1d". For example, the following
index=_telemetry date_wday=* ``` emulation ```
earliest=-3w@+1d
``` testing below ```
| eval date=strftime(_time, "%F")
| sort - _time
| bin span=1w _time
| stats dc(date) list(date_wday) list(date) by _time
| sort - _time
outputs
_time | dc(date) | list(date_wday) | list(date) |
2022-04-01 | 7 | thursday wednesday tuesday monday sunday saturday friday | 2022-04-07 2022-04-06 2022-04-05 2022-04-04 2022-04-03 2022-04-02 2022-04-01 |
2022-03-25 | 7 | thursday wednesday tuesday monday sunday saturday friday | 2022-03-31 2022-03-30 2022-03-29 2022-03-28 2022-03-27 2022-03-26 2022-03-25 |
2022-03-18 | 7 | thursday wednesday tuesday monday sunday saturday friday | 2022-03-24 2022-03-23 2022-03-22 2022-03-21 2022-03-20 2022-03-19 2022-03-18 |
2022-03-11 | 6 | thursday wednesday tuesday monday sunday saturday | 2022-03-17 2022-03-16 2022-03-15 2022-03-14 2022-03-13 2022-03-12 |
(Splunk also allows you do define custom time ranges so your users do not have to manually enter if they want to use such in search window and dashboard alike.)