iIf you only ever care about the last few hours or the last day of your data, this simple change will speed up your search results tremendously. Until our next big release which will basically be this way by default, here’s how you can do this in 2.1 code.

This is a change in three places, but fortunately very fast to make, and all in the same file.
$SPLUNK_HOME/share/splunk/search/dynamic/main_ui.html

Note: The example here will set your UI to search only the past 6 hours by default. After doing this it should be easy to see how to change it to search 1 day, or 45 minutes etc…

Note: Also you dont need to restart the front end to see these changes, but you DO have to refresh your browser by clicking the refresh button up top.

step 1) around line 70, change
<div class=”#productVersion#Version landingPageState #userType#User noTimeFields eventsTab relativeTimeMode #dynamicallySetStates#” id=”outerWrapper” />

to
<div class=”#productVersion#Version landingPageState #userType#User eventsTab relativeTimeMode #dynamicallySetStates#” id=”outerWrapper” />
(basically this removes the ‘noTimeFields’ state so the time controls are now open by default)

step 2) around line 122 of the same file, change
<input type=”text” id=”relStartTime” />

This is a quick update to Mark’s post from 10/9/2006

Again, to reiterate Mark’s qualifier - this is all assuming you understand that by doing this, you send users and passwords in clear text and the risks involved.

So, uncommenting the 2 lines as described in Mark’s post will only get you the first part, ie the ability to send a GET request that logs you in. We’ve had people ask if that request can go further and also return results right away for a particular search they also pass in. Obvious request but somehow we didnt anticipate it.

So until we wrap this feature up in a bow in a release, once again this involves editing python by hand. And this time it’s more than just uncommenting two lines. It’s cut and paste, and if you know python you know that tab-indentation is meaningful, and this seemingly simple action can be deadly. You have been warned. Back up the file and proceed carefully.

Alrighty, still with us? =) Find the 2 lines that Mark blogs about uncommenting. (this will be XMLResource.py, line 395 - 400 ish depending on which 2.1 release this is)

Everybody wants this, and until the day when it’s built into the UI somewhere, you can use this little bookmarklet to do it in about a minute.

So. the link below is your friend. (If you’ve used bookmarklets before you know what to do. Otherwise, read on. )

Instead of clicking this link though, right-click it or option click it, and choose ‘bookmark this link’.
splunk 30 second refresh

Once you’ve done that, then whenever you have Splunk loaded, clicking that bookmark will run the tiny little script, and the upshot is that the UI will start autorefreshing in 30 seconds and every 30 seconds thereafter.

And if you want to change the 30 seconds, edit the bookmark, find the 30000 and change it to whatever.

Full speed ahead for the next big round of improvements and fixes and we’re all going cheerfully bonkers. I was especially cheerful/bonkers today because I spent the morning prototyping some SVG stuff. In particular, since the splunk ui runs almost entirely on xml and client-side xslt, I was looking into how feasible/fast/stable it would be for our client-side XSL to just generate SVG directly, and for javascript to clone those svg nodes into a big complex DOM.

The answer is - omg it works well. Fast, seemingly stable, it can be pushed. Even in a big javascript front end like ours, the event handlers on svg elements pass right up into our existing framework. Some small tweaks had to be made to accomodate it, but no showstoppers. And it is rare for such a complicated thing to present so few obstacles in practice.
So thanks to Mozilla for being generally awesome, and particularly for turning on SVG in their release builds . Of course i have absolutely no idea if any svg will ever appear in the product … We do after all have a great deal of other more mundane improvements in the works. =)

First post, so i’ll begin at the beginning.

Im the front-end guy. From the xsl,js,html and css on the client side, up to the python in splunkSearch, I am responsible (read: to blame) for the current implementation, and also for much of the interaction design. I’ve worked here just over a year now, and I have no noticeable scars or weird tics to show for it, so I guess I’ve got that going for me.

What possessed me to come work here: Essentially all of my experience before splunk was at services companies, and for the prior 3 or 4 years specifically I had become this sort of high-throughput template builder and dhtml-specialist. Boring stuff I know, but I mention it because I came to splunk partly to get away from this. You can build lots of really complex front ends while at services companies. You can do build for flexibility and simplicity all you want, but when the project is over you never really see the code again (or worse the code never gets updated or changed by anyone and so it never evolves at all). So outside of maybe some escalated issues, you never really know what were the good parts of the implementation and what were the bad. And the development pain induced by changing requirements, the codebase evolution and accidental devolution, the day to day suffering really, you get spared from all that and that sucks.