Hm. Very strange and I don't know of anyone else seeing this. 1) Did you restart the server after installing the app? If not, does restarting now fix it? 2) Did you clear your browser cache after installing the app? Or click the button on the "bump" endpoint? If not does navigating to http://YOUR_HOST:8000/en-US/_bump and clicking the grey button fix the problem? 3) If you open the "error console" of your app are there any javascript errors displaying? ... View more

That's great. OK well Callmanager CDR lists all timestamps in epochtime, and in that format there is no concept of any associated timezone nor is any needed, so there's kind of no way to get this part wrong. To give an example, let's say callmanager says a call originated at 1469800000. That one number is sufficient to completely determine the time, without any need for any associated timezone. That epochtime value of "1469800000", if written out as a string, in GMT would be Fri, 29 Jul 2016 13:46:40 GMT and in US Pacific time that same instant in time is 7/29/2016, 6:46:40 AM GMT-7:00 DST Those strings need tz information to determine what time they're talking about, but epochtime timestamps don't. ... View more

I think the Timezone part of this question is a bit of a red herring. Callmanager CDR reports its timestamps in epochtime, which is often confused with UTC. UTC is technically a timezone, sort of like GMT without any Daylight Saving Time shenanigans. Epochtime on the other hand is simply the number of seconds since midnight on 1/1/1970 gmt. Despite the odd gmt reference there at the end, the number of seconds itself entirely determines the time, no TZ info is necessary or needed by Splunk. As to how to display this time and date as a string, Splunk by default uses the timezone that it is located in. This can be changed in user-prefs.conf but it's not often done. You might also take a look at the Splunk app "Cisco CDR Reporting and Analytics". Although it's not free, it is available as a free 90 day trial. I'm certainly biased as it's owner and creator, but it enables a very wide range of reporting use cases on Callmanager CDR and you may find it very useful. ( http://sideviewapps.com/apps/cisco-cdr-reporting-and-analytics/ ) There are several timestamps in Callmanager CDR data and although dealing with them correctly isn't particularly difficult, it's one of many things that the app would handle for you. ... View more

If you want a Sideview UI dashboard to be printable to PDF, the key thing to do is to build it using Splunk's JSChart module instead of their FlashChart module. This will allow you to manually print-to-pdf, but you still wont be able to automate or schedule the creation of the pdf. You may also notice some idiosyncracies with other modules when you print to pdf. Some of these are cases where the modules are trying not to display information that they feel is relevant to the web only, but you may find bugs in legacy Splunk modules or even Sideview modules. I'm glad that you like it. Thanks for the great question. PS. Sometime in the next few releases Sideview Utils will have its own "Chart" module which will quickly supercede both JSChart and FlashChart so subscribe to the mailing list and watch out for that module when it comes. Technically I'm currently working on superceding all Splunk modules as well as all remaining advanced XML code and dependencies. ... View more

Actually this particular answer+comment thread didn't resolve his issue - That seems to be a bug or at least a strange convention in timechart. I just refactored his search a bit as a side matter. ... View more

Interesting. Can you replace the timechart command with just table _time after_gc max_gc , rerun, export those rows and either paste them here or put them on pastebin? Sounds like some interesting behavior in timechart, quite possibly a bug, and I'd like to reproduce. ... View more

Oh right. Sorry I forgot that appendcols will happily append extra rows if the base search has fewer rows. It's a strange way to do that. By way of apology, here is your search refactored as a disjunction without the appendcols: eventtype=mlc (sourcetype=murex_log4j source=launchermxmlc.mxres.log ) OR ( sourcetype=sun_jvm service_name=mxmlc.gc.log ) | eval log4j_start=if(sourcetype="murex_log4j",_time,null()) | fields log4j_start relative_time after_gc max_gc | eventstats min(log4j_start) as start_time | eval _time = start_time + relative_time | fields - start - start_time - relative_time | timechart fixedrange=false bins=2000 max(after_gc), max(max_gc) ... View more

Can you share the search syntax that you're working with now? Likely there are some clauses doing things to create these multivalue fields and if that's the case the best answers may involve changing some of that upstream search language. ... View more

I think this search may have once made sense, but that it has lost it's way recently. I'm going to walk through it pipe by pipe. In particular, I think the problem is that all the search language before the timechart command can only ever produce a single row and a single _time value for timechart to chart. Here are the first two commands. eventtype=mlc sourcetype=murex_log4j source=launchermxmlc.mxres.log | stats earliest(_time) as start As always when a stats has no group-by field, this will produce only a single output row. that row has one field named "start". the next command will add two fields to that single row, but it will not add any rows. | appendcols [ search eventtype=mlc sourcetype=sun_jvm service_name=mxmlc.gc.log | table relative_time after_gc max_gc ] The next command is a strange-looking way to create a new field called "start_time" and set it to the value of "start". If there were ever more than one row here, it would make more sense, so I suspect at one point the earlier clauses were quite different. | eventstats max(start) as start_time Then there follow an eval and a fields clause, neither of which can ever create more than our one row. So when the timechart clause receives its input rows, there will only be one value coming in, and only one value of "_time". ... View more

Interesting. O well. Good luck. One more dumb idea - have you tried running the msi as an administrator? it's maybe distantly possible they're doing the privilege escalation hoopjumping in some way that Windows 7 doesn't like. ... View more

I've seen that same error in a prior upgrade, and the somewhat surprising solution for me was to manually shutdown Splunk before running the MSI to upgrade. The MSI should be able to shutdown Splunk during the course of the installation process but for some reason it was failing and that generic error message was all that was coming back to me. I think I've seen it on two different upgrades (both were windows 7 x64 fwiw), and since then I just shutdown splunk before ever upgrading via an msi. hth. ... View more

Since you have the alert trigger specifically when there are zero events, you have to modify things here. Change the alert so that instead of alerting when the search gives zero rows, instead it'll alert "when a custom condition is met. I would actually modify this search from source=/var/log/messages ("shutdown" OR "reboot") NOT (date_hour=0 AND date_minute>14 AND date_minute<46) | stats count by host to source=/var/log/messages ("shutdown" OR "reboot") | eval is_expected_downtime=if(date_hour=0 AND date_minute>14 AND date_minute<46,"yes","no") | stats values(is_expected_downtime) as is_expected_downtime count by host and then set as your custom condition to | stats sum(count) as total values(is_expected_downtime) as is_expected_downtime | search total=0 is_expected_downtime="no" If the alert fires in a condition where all the data is occurring during expected downtime, then the condition will not match. Outside of expected downtime, it will match whenever there are no raw events. ... View more

quick clarification - in general the date_ fields aren't supposed to be generated when there's no clear TZ info for Splunk to rely on. So indeed without keeping a close eye on your sourcetypes you can't rely on them always being present. Then there is a bug that when time is pulled from an epochtime value (integer number of seconds since 1/1/1970) the date* fields will be present, and will be calculated in GMT. Here, since the examples posted are all within a known sourcetype, it may very well be fine to use the date_ fields. ... View more

Unless there's some weird mismatch of definitions, like the "weekly" is only counting the last full monday-to-monday week, this has to be a bug in the logging or in the app. ... View more

Note this will not work properly whenever an event has both destCity and sourceCity fields - in such cases it will disregard that event's sourceCity field. ... View more

Strange. It really shouldn't be. And on my system index=_internal | head 100000 | bin _time span="1h" | stats count by _time sourcetype | sort - count | head 1 is quite a lot faster than the other options. I'm glad they all work for you though. 😃 ... View more

My money is on @sideview option 2! I love the 2-dimensional max(*) as * craziness though. ... View more

1) You want to use untable to turn the chart/timechart style result set into a "stats style" result set, then you can find the maximum value along with both the time value and the relevant value of the split-by field. Using your index=_internal example it would look like index=_internal | timechart count by sourcetype | untable _time sourcetype count | sort - count | head 1 2) the other way to do it is to just use bin and stats instead of timechart in the first place, like so: index=_internal | bin _time span="1h" | stats count by _time sourcetype | sort - count | head 1 but then you have to do the binning by hand with the bin command. ... View more

Well this is pretty straightforward in Sideview Utils, but you can also do this without much trouble just using the default Splunk Dashboard editor. Here's how to do it in hand-edited Sideview XML. <module name="TextField" layoutPanel="panel_row1_col1"> <param name="name">to</param> <param name="label">to:</param> <module name="TextField"> <param name="name">subject</param> <param name="label">subject:</param> <module name="Button"> <param name="allowSoftSubmit">True</param> <module name="Search"> <param name="search">foo | sendemail $address$ $subject$ </param> <module name="JobProgressIndicator"></module> </module> </module> </module> </module> If you're using the Sideview Editor you would click and edit your way to the above hierarchy. Be sure to read the first few introductory documentation pages within the Sideview Utils app, and then also read the TextField docs and examples page. That'll give you enough to understand this simple view, and then you can expand out to the other UI modules and their docs and examples pages. But again, in this (really very simple) use case you can also just use core Splunk UI features - in brief, add a search to a dashboard panel, edit the panel, and then click "add input", and read a bunch of Splunk docs about how to then parametrize your search with $foo$ tokens. ... View more

If I understand your question, the answer is some kind of conditional eval statement. | eval normalizedId=if(sourcetype="A",someIdField,sourcetype="B",someOtherIdField) ... View more

When you need to retain some kind of data or marker from the "inner" search, and have that thing survive into the outer search, then this is where you take a left turn out of subsearches and into the broader world of eval+stats Broadly speaking, (<Search 1> ) OR (<Search 2>) | eval <some things to normalize and/or create markers> | stats <some things> by <field(s) by which you need to group> specifically ( index=web_logs sourcetype=http matched!=google.com) OR (index=web_logs sourcetype=dns_requests response=true) | eval type=case(sourcetype="http","http",sourcetype="dns_requests","dns") | stats count by uri domain_name type Now this wont filter out the "loud" ones yet. But we have the raw ingredients now. The next step would look something like this: ( index=web_logs sourcetype=http matched!=google.com) OR (index=web_logs sourcetype=dns_requests response=true) | eval type=case(sourcetype="http","http",sourcetype="dns_requests","dns") | stats count by uri domain_name type | eventstats sum(count) as totalDomainCount by domain_name | where totalDomainCount<10000 Notes: Somewhat obviously, the base search here can be refactored a bit as index=web_logs ( sourcetype=http matched!=google.com) OR (sourcetype=dns_requests response=true) The eval statement that creates the "type" field is a little trivial, and in this particular case we could just use the sourcetype value itself. However I've left the eval clause here as a stand-in for what is often a more complicated eval expression. ... View more