|
In Splunk GUI, after I create a real time report and put it on my dashboard, it eventually times out. Wondering if there is a way to prevent that timeout from occurring and keep the dashboard up and running indefinitely (as long as I keep my browser open). |
|
What happens is that when the Splunk UI doesnt see someone there clicking the mouse every now and then, it'll stop talking to the backend. This means the UI will stop updating and the sessions on splunkWeb and on splunkd will start timing out. (technically we do that precisely because we want them to start timing out) Eventually the unattended real-time search will get cancelled automatically by splunkd (courtesy of the autocancel value provided by the view), and a while after that your sessions will expire. When you return to the UI you'll get kicked to the login screen. As far as getting a real time dashboard running indefinitely. 1) If the UI for the dashboard is going to remain on a single screen somewhere 24x7, like in a NOC--- then the best practice I've come across, is to have a dedicated search head, where you actually turn off the POLLER_INACTIVITY_TIMEOUT entirely. Ideally I would strip that search head down so that it really only has that one view on it. Or otherwise ensure that people arent going to run other long running searches on it. Check out the second part of this answer which is related (note the first suggestion is not related) http://answers.splunk.com/questions/3273/real-time-views-are-hanging 2) If the UI for this real time search is NOT going to remain on a single screen, but you want any number of users to come to a particular dashboard and rather than dispatch 1 real-time search for each user, you want them all to share a single permanently-running real time search -- honestly we dont have this yet. We are working on this very problem for our next release believe me. =) There are some hacky and limited ways that are fun to explore but I cant say I recommend them and they are of course undocumented and essentially untested. At base all 3 methods involve making a dashboard that is basically hardwired to always display the permalink to one specific job. You then manually run a real-time search in the 'advanced charting view', and fish out its sid using 'get link to results'. From there the advanced reader can figure out the 3 distinct methods that would work from the following hints: a) put hardwired permalink directly in the nav xml b) postProcess magic, c) IframeInclude insanity |
