Inconsistent Behavior With Timechart and "Today" Timeframe

[aferone]

This is really weird. I am hoping someone else has seen this and has a fix.

This is my query. I want to make a chart that shows the entire day (full 24 hours) for TODAY.

host="hostname" SnortID="[1000]" earliest=@d latest=+1d@d | timechart span=5m count(SnortID) by SnortID

When I run this query the FIRST TIME, I get a chart that shows all of today, including up to tomorrow at midnight, which is what I want. Here is an exmaple:

However, if I only refresh this query, it will only show the chart up from the first found record until the last found record. Here is an example:

All I did was hit refresh, and the chart changes! The data is the same.

Does anyone have a fix or seen this?

Thanks!

[woodcock]

Try forcing this behavior one way or the other by playing with the cont and partial` options.

[rickybails]

I am experiencing this same problem, over 3 years later. Not sure why this hasn't been fixed by now. For me, the problem happens (i.e. fixedrange=true is not respected) when there is no 'latest' arg set in the time picker, which explains why the same query string will behave differently in different search screens (because they are getting the time picker from the search window). Simply setting latest=now fixed this for me - the problem is that splunk's default time ranges that are up to current time (e.g. 'today' or 'last 4 hours') do not always set latest=now, but leave latest empty. You can confirm this in the URL. On dashboards using a shared time picker you can set latest=now in the default time but if the user changes this to one of the defaults with an implied latest=now setting, that setting might unset 'latest' and stop fixedrange=true from working.

[richgalloway]

@rickybails You're adding on to a three-year-old posting. For better chances at a helpful response, please post a new question.

[natdsuarez]

Same exact behavior, running 6.1.4 on Windows. I started out with these 2 queries and different events were returned.

these are the queries:

index= | lookup local=1 userstatus UserID as user_id OUTPUTNEW UserStatus as user_status | eval user_status = if(user_status="NONE", true, user_status) | search userstatus=true AND status = 200 AND (file=search OR file=content) | timechart count(method) by user_id
index= | lookup local=1 userstatus UserID as user_id OUTPUTNEW UserStatus as user_status | eval user_status = if(user_status="NONE", true, user_status) | search userstatus=true AND status = 200 AND (file=search OR file=content) | dedup user_id, date_month, date_mday | timechart count(user_id) As "User Count"

Then, I cut and pasted the 2nd query to the 1st window and received different results. (Same time frame for both queries).

,

[lguinn2]

I don't know why it is inconsistent - that's weird. But I do know how to force it to behave the way you want, whatever that is. Use the fixedrange option for the timechart command.

fixedrange=f means "only graph the data that is there." This is what happened when you refreshed.

fixedrange=t means "graph the time range selected in the search." This is the default, and what happened when the search ran the first time.

So

host="hostname" SnortID="[1000]" earliest=@d latest=+1d@d 
| timechart fixedrange=t span=5m count(SnortID) by SnortID

should get you what you want every time. If it doesn't, then I think there could be some bug in Splunk that makes it refresh wrong.

[aferone]

I was really hoping for this to work. I tried it, and the first few times I refreshed it was fine. But then it reverted back to the view I have described above. And then it was correct again. This is really weird. I appreciate the response.

[curtisb1024]

I see this same behavior running 6.2 on Linux. Timechart inconsistently uses the first event or the earliest search time specified. fixedrange has no effect.

[sves]

I see the exact same behaviour, running 6.1.4 on Windows. Any news on this?

[sansay]

I see the same behavior with Web UI in Windows 7, using either Firefox or Chrome, and Splunk version 6.1.5.
I put in a bug report with Splunk for this issue.

[aferone]

The behavior occurs in a dashboard as well as from the search bar.

[somesoni2]

You are running this search in a dashboard??