Splunk Search

FlashTimeline - how many time bars can be displayed?

Motivator

I have noticed that when doing a search in the default Search view, flashtimeline, the green time bars will be a useful small amount of time - up to a certain point. Then the time per bar will round up and the bars will be very wide and not useful.

What is the number of x-axis datapoints that can be displayed on the flashtimeline's histogram, and can this be changed?

Searches over a week could easily show 7 days x 1hr or 4hr increments on a screen as wide as mine, but instead show only 1 day increments.

1 Solution

SplunkTrust
SplunkTrust

You cant control the bucket size of the FlashTimeline directly, but you can set a ceiling on how many buckets it's allowed to use. It takes a param called statusBuckets, and the docs list the default as 300 ( http://<host:port>/en-US/modules#Splunk.Module.FlashTimeline ). You can set this to any positive integer you like, but be careful going past about a thousand. The module refreshes itself every few seconds while a search is in progress so if it's a huge dataset you're asking it to pull down from the server every time, high numbers will slow things down a lot.

By the way, this may remind you of the bins=X / span=Y arguments that the timechart has. However the comparison only goes so far. The logic in the timechart is more sophisticated, in that it will display bucket sizes like 15minutes or 4hours, or 12 hours. The FlashTimeline module on the other hand always renders with one bar equal to one second, minute, hour, day, month or year.

Also, strictly speaking statusBuckets is not just a param for FlashTimeline. It's actually one of the arguments that you can send when you dispatch a search, and the effect is to set Splunk's granularity for preserving summary information throughout the lifetime of the job. Setting FlashTimeline's param thus effects the entire job, not just FlashTimeline's requests. Strangely though, there's no documentation about statusbuckets, nor about it's often-related POST arg, requiredFieldList. http://docs.splunk.com/Documentation/Splunk/4.2.4/RESTAPI/RESTsearch#POST_search.2Fjobs I could have sworn there used to be a mention of it in the old REST docs, but maybe the docs were removed.

View solution in original post

SplunkTrust
SplunkTrust

You cant control the bucket size of the FlashTimeline directly, but you can set a ceiling on how many buckets it's allowed to use. It takes a param called statusBuckets, and the docs list the default as 300 ( http://<host:port>/en-US/modules#Splunk.Module.FlashTimeline ). You can set this to any positive integer you like, but be careful going past about a thousand. The module refreshes itself every few seconds while a search is in progress so if it's a huge dataset you're asking it to pull down from the server every time, high numbers will slow things down a lot.

By the way, this may remind you of the bins=X / span=Y arguments that the timechart has. However the comparison only goes so far. The logic in the timechart is more sophisticated, in that it will display bucket sizes like 15minutes or 4hours, or 12 hours. The FlashTimeline module on the other hand always renders with one bar equal to one second, minute, hour, day, month or year.

Also, strictly speaking statusBuckets is not just a param for FlashTimeline. It's actually one of the arguments that you can send when you dispatch a search, and the effect is to set Splunk's granularity for preserving summary information throughout the lifetime of the job. Setting FlashTimeline's param thus effects the entire job, not just FlashTimeline's requests. Strangely though, there's no documentation about statusbuckets, nor about it's often-related POST arg, requiredFieldList. http://docs.splunk.com/Documentation/Splunk/4.2.4/RESTAPI/RESTsearch#POST_search.2Fjobs I could have sworn there used to be a mention of it in the old REST docs, but maybe the docs were removed.

View solution in original post

Motivator

Thanks. I think the confusion arises when you run a search, the search bumps up to the next summary granularity, then the search realizes it has hit the end of the results (or is finalized) and then shrinks back to the events available, sometimes showing only a few time bars.