piping events from a custom generating command into timechart results in irregular buckets when not using all-time

[ruman]

I have 26 days of events (Monday 9/15 through Friday 10/10) piped to a timechart span=7d.

I'd like to have 3 buckets of 7 days each, and one bucket with the 5 remainder days. It doesn't matter to me if the remainder bucket is at the beginning or end but it would be nice if Splunk was consistent about it.

Instead, my buckets begin at 9/15, 9/22, 9/29 (Mondays), 10/3, 10/10 (Fridays) which means I have 5 buckets, instead of 4,
with 7, 7, 4, 7, and 1 day in them.

How can I make timechart behave reasonably?

I'm running Splunk 6.1.2

[acharlieh · Accepted solution]

So the crux of this issue here is that every search in Splunk has a timerange with it. Also timechart uses the earliest time of the search to figure out what times fit into what bucket. When you generate results (with an external command or creative uses of other commands) that have results with _time fields outside of the range of the search, oddity occurs. As jrodman says in the comments below, often times you should set the search timeframe to all time, or at least manipulate earliest.

Alternatively you can use eval with the relative_time function to manipulate _time into desired buckets, and then use chart.

---

Original Comment:

Ah! So the issue there is that every search in Splunk has an earliest and latest time. When you generate events from an external command that fall outside the time range of your search, it throws off the bucketing done by the bin / timechart command. My gist is generating 40 days of events so I needed to make sure my search window was 40 days otherwise you wind up with funniness at the search boundary. But the second form using eval and relative_time should work better

[jrodman]

I moved this to an answer because it was the crucial insight. If you're willing to edit it a bit to be clearer for future readers feel free, or I'm happy to do so.

[ruman]

oh, that's really interesting. so maybe i need to match the time picker to range of the events that hit timechart in order to make the buckets happy? i've got lots to experiment with now, thank you!

[ruman]

yup, ding. setting the time picker to all time makes very normal buckets. thanks everyone.

[ruman]

and even better, setting the time picker to the exact day the events start, makes the buckets start on that day, e.g. i can make sure the buckets start on mondays by having the timepicker set earliest to -3w@w1.

[jrodman]

I assumed your search was all-time. Is it?

[ruman]

no, the time picker was definitely not set to 'all time', and the external command i'm running completely ignores the time picke.r

[jrodman]

It should probably be set to all time if the input is going to ignore it.

[acharlieh]

Next year at conf, I need to not give away so much karma that I can no longer comment. But what are you using for your earliest search time? I've noticed that timechart and bucket/bin use this for the base of the buckets: https://gist.github.com/acharlieh/777d6767378e82427d00

[acharlieh]

Indeed! Or instead of manipulating the search range, use eval to manipulate the _time field into the correct buckets and then chart (instead of timechart) 🙂 have fun!

[ruman]

in this case the events are coming from an external command, then i'm removing older events with a where clause. i don't know what that means "earliest" is. And I don't quite get what's going on with your gist, but I'll experiment with it and write back...if span=w, then why does earliest need be -40d or earlier?

| foo bar bas
| eval earliest_ts=relative_time(now(), "-3w@w0")
| where _time > earliest_ts
| timechart span=1w count by bat

[jrodman]

I'd suggest editing this to describe your specific goal. Documenting the fail seems more like a thing for jira.

[ruman]

okay, i tried!