Realtime clock of Splunk server time on dashboard?

[phoenixdigital]

Hi All,

A client has requested we give them a realtime clock on a dashboard showing the current server time. I have seen many examples which show how to use a javascript clock on a dashboard but this is obviously the local users computer time.

The only thing I can think of that comes close is this in a 30 second realtime window.

index=* | eval clock = strftime(time(), "%H:%M:%S") | sort 1 -_time | table clock

Is there a better way to show the server time?

[chrisprangnell]

I have a 1 server install of splunk.

My ubuntu server is in UTC, but splunk seems to be in another timezone, and is 1 hour out from my local timezone, how do we change this timezone?

[chrisprangnell]

give these queries my Splunk is out by 1 hour. How to I update the timezone of splunk? my Ubuntu server is in UTC time but my splunk seems to be in another timezone.

[ArthurGautesen]

If you just want the clock out of the date/time of makeresults, then
|makeresults | eval Clock=strftime(_time,"%H:%M:%S") | table Clock

it takes less time and uses less resources then
index="_internal" | stats count | eval clock = strftime(time(), "%H:%M:%S") | table clock

[ateixeira_splun]

| makeresults is your friend 🙂

[chimbudp]

| stats count as Now | eval Now = strftime(now(), "%+")

Ans:

Sat Jul 26 12:23:22 UTC 2014

[phoenixdigital · Accepted solution]

Thanks guys for the responses unfortunately Nick yours will only work if the "main" index gets updated frequently which is why I put index=* in there.

Sadly just stats for a realtime search never updates
| stats count | eval clock = strftime(time(), "%H:%M:%S") | table clock

I have however used your ideas to come up with this

index="_internal" | stats count | eval clock = strftime(time(), "%H:%M:%S") | table clock

We can pretty much assume the _internal index would be updated the most frequently so it would be a good one to base the time from.

I like the idea of using an offset too gkanapathy but will stick with this simple version unless they want it to change every second as opposed to every 3 seconds or so.

[phoenixdigital]

I feel like I am spamming now but this would probably be even less of a hit on the system as it doesnt need to "count"

* | head 1 | eval clock = strftime(time(), "%H:%M:%S") | table clock count

[sideview]

Interesting. They both refresh every 3 seconds for me, even though my system has no realtime events coming into index main - if I leave the count field in there it remains at 0 throughout.

[phoenixdigital]

Actually this is the fastest its not the internal index giving the speedup

 * | stats count | eval clock = strftime(time(), "%H:%M:%S") | table clock

[phoenixdigital]

I take that back it was the foo NOT foo causing the 6 second interval plus a substantial delay when compared to my system clock.

My answer still stands as the fastest updating version (with minimal delay) but does have the issue of not showing when users dont have access to _internal.

[phoenixdigital]

However without index=_internal (on a dashboard not in search module/dash) it appears to update every 6 seconds. Wheras with index=_internal it appears to update every 3 seconds.

[sideview]

I don't really know either, but foo NOT foo does seem to work reliably in this context, in that it sets up a streaming portion of the search without actually doing anything. In general the same trick comes in handy in odd places. For instance if you ever need to launder result rows back into event rows, (for example so that EventsViewer can render them), you can do foo NOT foo | append [some other search | stats count by username sessionid]

[phoenixdigital]

Ahhhh thanks for an insight into how Splunk works on the inside. I was under the "assumption" that it only updated when data arrived.

[sideview]

Indeed just a | stats count search wont update in a realtime timerange. But that's what the foo NOT foo is doing. the job updates every cycle regardless of whether or not the main index is getting new data. Splunk isn't smart enough to know the foo NOT foo will never match any events so it keeps trying. The _internal is another way to go, but don't forget that not all users and roles can actually see internal, so their clocks will stop.

[gkanapathy]

Well, first you don't want to start with index=*, because that has to do a massive search that hits the disk for the index, or else it might return zero results. Starting off with | stats count doesn't do that, and guarantees exactly one result, a single field with a value of zero. So with that:

| stats count | eval clock=_time | fields - count

Will do it more cleanly.

On the other hand, if you trust the client clock, you could just get the offset from the server time once at page load, then use that to display the browser time with that offset. This can let you keep the clock ticking without server queries.

[sideview]

Also pretty bizarre, but you could run this search with any realtime timerange:

foo NOT foo | stats count | eval clock = strftime(time(), "%H:%M:%S") | table clock

It would never match any events, but it would keep checking enough to keep advancing the clock time every few seconds...