Hi. We are looking to estimate retention needs for a new Splunk Cloud deployment. I'm looking at using the following formula: total space required = (retention time in days)x(ingestion/day)x[0.15*RF + 0.35*SF] where RF/SF are the index clustering replication/search factors, and 0.15/0.35 are the commonly adopted compression ratios for rawdata/tsidx data. I'm aware that to calculate the extra storage to be purchased, I can subtract the 90 days retention that comes with the license. So really I need to know: is there a default set of values for RF and SF in Splunk Cloud deployments? Is it just the default on-prem indexer clustering values of RF=3, SF=2? The values could potentially make a big difference to retention needs but I don't see them mentioned in the Cloud docs. ... View more

We have a dashboard that lists a series of events representing alarms that need to be 'cleared' by the user as non-issues; we have a 'Clear-All'-style button interface that clears multiple events at once matching a given field value, it's implemented in Javascript and triggers a search similar to the one below: | inputlookup cleared.csv | append [| makeresults | eval Id="1000" | eval Reason="Low Level" | eval Timestamp=now()] | append [| makeresults | eval Id="1234" | eval Reason="Low Level" | eval Timestamp=now()] | append [| makeresults | eval Id="1301" | eval Reason="Low Level" | eval Timestamp=now()] ... | append [| makeresults | eval Id="1567" | eval Reason="Low Level" | eval Timestamp=now()] | table Reason,Id,Timestamp | sort Timestamp desc | outputlookup cleared.csv i.e. the cleared events have their unique "Id" field appended to a lookup file, which is then used to hide them in the original search. We've been using this tool successfully for a couple of years now; usually this list of alarms is checked daily and around 20-30 events are cleared simultaneously with a few clicks, however since upgrading to 7.1 we are finding that attempting to clear a large number of alarms causes a hanging behaviour and it can take tens of minutes for the clearing to complete. Further testing of the search above, with around 30 entries appended to the lookup table, shows that the search can take an extremely long time, over 30 minutes, in Splunk 7.1, while the search runs in 2 seconds in 7.0. Also when it eventually completes the job inspector in 7.1 is erroneously reporting that the search only took seconds. It would be simple enough to manually run the search 30 times with a single 'append' each time, but this would be massive change to the Javascript we had to put together to run the search as it is now. I've not seen anything in the release notes to suggest what might be causing this. Any one else having similar problems? Should this be reported as a bug? ... View more

We have a custom app with several dashboards comprised of tables arranged one after another in rows of panels, written in HTML/Javascript. After upgrading to 7.1 recently the pagination of the table entries is completely obscured, they just end abruptly like the bottom of one row of table panels is being covered by the top of the next row. I'm trying to restore the appearance by tweaking the panel margins with CSS but am having no luck. There's no way to scroll through the remaining entries in any table panel that aren't on its front page, or even see that they exist, due to the missing page scrolling buttons. I've tried setting the TableElement's 'pagerPosition' attribute to 'top'; in this case the page numbers and 'next'/'prev' buttons are visible along the top but they are completely non-interactive. This seems like a bug introduced by the UI refresh. It would be good to hear if anyone has any insight on the expected or observed effects of the 7.1 UI changes on HTML dashboards? ... View more