I did see a typo in my syntax for the one that didn't work - I had "valuies()" instead of "values()" hehe. I figured your actual desired end goal wasn't that values() output. OK I'll try and circle back when I get a chance. ... View more

I agree. My accepted answer here is from the 4.2 era. Looking in the docs, it seems graceful=true has been there since at least 4.3. As a wild guess, graceful=true has just been there forever and you could always do this and i just didn't notice until today. 😃 Agree that yours should be the accepted answer. ... View more

This shouldn't work, because the calculated fields are made well before the typer even runs. Typer and thus eventtypes, don't exist until after all the other props.conf stuff is done -- extractions, Aliases, calculated fields and lookups. ... View more

YIKES - the question got edited so as to pretty fundamentally change the searches, so a) my answer doesn't make any sense anymore. b) The two searches after the edits, return identical results. Tested it pretty extensively and I can find no differences. ... View more

I think the problem is that in the first one, the one with two stats commands, your second stats command is average(bytes) and median(bytes), but the values of bytes being fed into it, are not the small per-event bytes numbers, they are instead the much larger "sum(bytes) per clientip" numbers generated by the first stats. In other words the first search is doing something kind of unexpected statistically -- "get me the total bytes for each of the N clientips, and then give me the average of those N totals". Which isn't what you meant, and happens to yield answers that are quite a lot bigger. Be very careful of average.... you can chain stats together and still do averages and medians and stuff if you're paranoid. the problem is that the "first" one has to preserve both sums and counts.... In this case technically I think you could rewrite the first search's first stats command, to also pass along the counts per clientip, total up all those counts, and then device the final bytes by that factor but..... even as an "exercise for the reader" that's a bit insane. . ... View more

some side notes about this XML. There are two identical Search params so one of those can be removed. Not entirely sure how the framework picks a winner there but it's just picking one of them. you might like to know that ValueSetter has a more compact syntax. Instead of this: <module name="ValueSetter"> <param name="value">now</param> <param name="name">search.timeRange.earliest</param> you can do this: now And for that matter instead of this: <module name="HiddenChartFormatter"> <param name="charting.chart.showDataLabels">all</param> <param name="charting.axisY.scale">log</param> <param name="charting.axisY.scale">log</param> you can do this: <module name="ValueSetter"> <param name="arg.charting.chart.showDataLabels">all</param> <param name="arg.charting.axisY.scale">log</param> <param name="arg.charting.axisY.scale">log</param> ... View more

I see you're using our Editor, which is great. Can you fish out the XML for those four modules from "Settings>User Interface > Views" and paste it into the question? that'll show all the params and values. I think I know what the problem is, but want to make sure first. ... View more

Getting some disclaimers out of the way -- Sideview XML is a different way of thinking about it, and a whole other system to learn. Although basically everything from a simple xml dashboard has some equivalent in Sideview XML, there's no conversion utility and the best advice is to read all the docs and working examples inside Sideview Utils itself (60+ pages of docs and living working examples), and work your way up from simple examples to complex ones. The Multiplexer module is definitely on the "complex examples" side. The short version is that Sideview UI modules are little things like "Pulldown" or "Table" or "Pager" or "HTML" or "Search". You string modules together, and the framework figures out which searches you need dispatched for which modules, and how to pass all the little $foo$ tokens around so everyone gets what they need. You don't write code, but you either write the XML raw, or use the Sideview Editor, which is a little clunky but which is a full authoring tool for the format. MULTIPLEXER then, is an extremely powerful module - you configure it with one branch of modules downstream from it - which can be practically any set of modules. And it looks at the search results it's given, and it then creates one copy of that branch of modules ,for each row it sees in the search results. So effectively you can end up with one "paged table with a postprocess" for each row in an upstream search. Generally what is multiplexed 90% of the time is "a single HTML module" which is still super powerful.... And on the extreme end there isn't really an upper bound. You can multiplex module config using JSCharts, Tables, drlldown config, even other Multiplexer modules. Note - you can only download the real Sideview Utils here - https://sideviewapps.com/apps/sideview-utils/ ... View more

Well, you shouldn't be using the LGPL version (1.3.6) - it's extremely old and no longer maintained. Definitely switch to the latest on the sideview free internal use license (3.3.17). It's a whole ton of versions you're about to upgrade through, but it should be backwards compatible - granted for many things your views are going to be doing things in the pretty old and maybe deprecated ways. ... View more

I agree. Reading the new license it looks like a great improvement. Nice Work! I hope it's the shape of some things to come - there are some other splunk-owned things that would be much happier if they were licensed under this as well. ... View more

What is happening, is that the /splunkd segment is giving you access to the somewhat more "real" rest API on the splunk management port (typically 8089), and with the default output_mode being "xml", the results come back with this a directive on it to use a particular XSL stylesheet: <?xml-stylesheet type="text/xml" href="/static/atom.xsl"?> Now if you were actually making this request on the management port, there is an XSL file at /static/atom.xsl. However on the Splunkweb port it's a different http server and there is no such file there. When you hit these URL's using something like curl or an XMLHttpRequest object in Javascript, they don't care about the missing stylesheet. But for whatever reason browsers treat this as a fatal error. So bottom line, this isn't really a serious problem - it's just a mild and occasional annoyance for developers. SOLUTION: You can quite easily fix this by copying the atom.xsl file from $SPLUNK_HOME/etc/system/atom.xsl over to $SPLUNK_HOME/share/splunk/search_mrsparkle/exposed/atom.xsl and restart splunkweb. The problem will go away. OR, you can also not use the default xml outputmode. 😃 Tack on ?output_mode=json to get json instead (and thus you wont get any xsl stylesheet directive at all. ... View more

This really shouldn't be the case, at least I've never seen it happen. Are you sure the searchterms in the second search aren't also changing so that it happens to also have zero results? Here is a search that will always not return any events in the first search, and that (if you have any indexed data in the timerange) will always have some results in the second. foo NOT foo | append [search index=* | head 100 | stats count by sourcetype index] ... View more

Hello - The latest version of Sideview Utils (3.3.17 ) is actually vetted for Splunk Cloud and deployed in Cloud by several customers. You can download it from this page - http://sideviewapps.com/apps/sideview-utils/ using the "Download Full Version" link. NOTE - there is an extremely old version on Splunkbase (1.3.6) that is very much not vetted for Splunk Cloud and that will never be. If anyone is using that still on-premise I strongly recommend updating to the latest. Feel free to reach out to us if you have any questions or any confusion about it and I'll try to help - support [at] sideviewapps.com or submit the contact form at https://sideviewapps.com/contact/ I'd also love to hear, perhaps privately, where you heard that it wasn't available for cloud accounts, so I can perhaps correct whatever or whoever gave you that impression. ... View more

Yes absolutely. At a high level, the useful pieces are 1) the transfers field, which is integer valued, and which basically represents the number of individual call legs in the call where the termination cause code indicated a transfer. 2) the on_hook_party field, which as you might expect, has the value of either "caller" or "recipient", and indicates who of the two went on hook to end the final leg of the call. 3) terminatingCalledPartyNumber This is as you might guess, the called party number, from the very last leg of the call. Note - all 3 of these fields are added/calculated by the app's conf and its UI, and are not fields present in the core CDR format. (Back on the homepage there's that table going through all the 250 or so fields available, and you can find more info on these fields there as well as some sample reports) Putting it all together, 1) Using the app's own interfaces, ie clicking your way to things. Go to Browse Calls, set call types to just "incoming" in the "misc search terms" box type on_hook_party="caller" transfers>3 terminatingCalledPartyNumber="<GENERAL VOICEMAIL BOX EXTENSION>" hit return. You'll see a list of (fairly terrifying) calls. Note that there's a little "graph calls over time" link on the right hand side. Click that and it will roll up all these filtering arguments and kick you over into the Reporting side of the product. From there you can change the reporting pulldowns to things like chart the of over callingPartyAreaCode by transfers and by doing lots of permutations like this, you might spot some interesting patterns. You might also see for that matter, if a lot of these callingPartyNumbers have had the same thing happen to them many times.... which would be variously over 2) Using the Search Langauge directly This is really, really, not for the faint of heart. But you could do this in the search language manually Of course you still need to be within the app for some of these pieces to be defined. And the great great benefit of course, is that the app automatically handles all the logic why this query needs to be so crazy complicated.... `cdr_events` | sort 0 - dateTimeConnect | stats min(_time) as _time list(callingPartyNumber) as callingPartyNumber list(dateTimeConnect) as dateTimeConnect list(dateTimeDisconnect) as dateTimeDisconnect first(_time) as detailLatest min(dateTimeConnect) as dateTimeConnectFirst max(dateTimeDisconnect) as dateTimeDisconnectLast list(eventtype) as eventtype list(finalCalledPartyNumber) as finalCalledPartyNumber list(on_hook_party) as on_hook_party list(originalCalledPartyNumber) as originalCalledPartyNumber first(finalCalledPartyNumber) as terminatingCalledPartyNumber sum(transfers) as transfers by globalCallID_callId globalCallID_callManagerId globalCallId_ClusterID | eval duration_elapsed=if(dateTimeConnectFirst==0,0,dateTimeDisconnectLast - dateTimeConnectFirst) | fields - dateTimeDisconnectLast dateTimeConnectFirst | search on_hook_party="caller" transfers>3 terminatingCalledPartyNumber="<GENERAL VOICEMAIL BOX EXTENSION>" ( eventtype="incoming_call" ) | sort 0 - _time | fields _time callingPartyNumber dateTimeConnect dateTimeDisconnect detailLatest duration_elapsed eventtype finalCalledPartyNumber on_hook_party originalCalledPartyNumber terminatingCalledPartyNumber transfers `id_fields` It could however be optimized quite a lot with a subsearch that narrows it down to just calls that have had at least one call leg hitting the general voicemail extension, like so: `cdr_events` [ search `cdr_events` finalCalledPartyNumber="<GENERAL VOICEMAIL BOX EXTENSION>" | stats count by globalCallID_callId globalCallID_callManagerId globalCallId_ClusterID | fields - count] | sort 0 - dateTimeConnect | stats min(_time) as _time list(callingPartyNumber) as callingPartyNumber list(dateTimeConnect) as dateTimeConnect list(dateTimeDisconnect) as dateTimeDisconnect first(_time) as detailLatest min(dateTimeConnect) as dateTimeConnectFirst max(dateTimeDisconnect) as dateTimeDisconnectLast list(eventtype) as eventtype list(finalCalledPartyNumber) as finalCalledPartyNumber list(on_hook_party) as on_hook_party list(originalCalledPartyNumber) as originalCalledPartyNumber first(finalCalledPartyNumber) as terminatingCalledPartyNumber sum(transfers) as transfers by globalCallID_callId globalCallID_callManagerId globalCallId_ClusterID | eval duration_elapsed=if(dateTimeConnectFirst==0,0,dateTimeDisconnectLast - dateTimeConnectFirst) | fields - dateTimeDisconnectLast dateTimeConnectFirst | search on_hook_party="caller" transfers>1 terminatingCalledPartyNumber="6131361016" ( eventtype="incoming_call" ) | sort 0 - _time | fields _time callingPartyNumber dateTimeConnect dateTimeDisconnect detailLatest duration_elapsed eventtype finalCalledPartyNumber on_hook_party originalCalledPartyNumber terminatingCalledPartyNumber transfers `id_fields` ... View more

We can solve this in the app's "Browse Calls" page, and I'll walk you through a couple super-obvious things, on the way to some things at the end that will really lock it down and give you just the calls you need. (I think) -- First, Go to "Browse Calls". -- next to "call types", narrow it down to just "incoming" -- leave the second pulldown set to "show all activity for" and set the "number/ext" value to office main line, and the front desk number, separated by a comma. (the field allows multiple extensions to go in there, separated by commas) You can throw in the autoattendant extension there too, so in the "number" field it might look like 4155551212,1000,1200 That field will always be used as an "OR" so you can throw in any extensions or DN's. The caveat is that without a "" wildcard on the start or the end, they have to match what's appearing in the CDR *exactly. OK. If you follow those steps and hit return, you still aren't quite there yet, but you'll be looking at inbound calls to the main number that then transfer to the front desk. Next -- add two more searchterms to the "other search terms" box. on_hook_party="caller" terminatingCalledPartyNumber="<YOUR FRONT DESK NUMBER HERE>" The on_hook_party term is saying that we only want to see calls where the inbound caller hung up to end it all. The terminatingCalledPartyNumber field is saying we want only calls that ended here and didn't transfer on any further. These are both fields that are actually added by the app - not present in the CDR data itself. I at least wanted to show you how to get to this point. From here, there are more ways to nail it down further, but they may be unnecessary. The engineer in me wants to tell you how to really nail it down to be just the calls "where the second leg had zero duration". This is totally possible, however that road is too complicated for the "Browse Calls" UI and it's not a good idea to throw you into the raw search language so quickly. So I think a combination of on_hook_party and terminatingCalledPartyNumber can actually get you there just as reliably. Hopefully we can do this in a few stages - get to the point above and add any questions or thoughts you have from there. ... View more

If this search, DEF <index and sourcetype and service terms to narrow down to just DEF events> | stats count by ABC returns relatively quickly, and with only a few hundred or thousand rows, and especially if the number of events coming out of your main stats clause is being radically filtered down by the | search XYZ="def" clause, then you should absolutely switch this to a subsearch use case. index=INDEXA earliest=-7d@d latest=@d sourcetype=GHI "service=randomservice" (api_name=API1 OR api_name=API2 ) [DEF <index and sourcetype and service terms to narrow down to just DEF events> | fields ABC | dedup ABC] | stats first(_time) as _time, values(XYZ) AS XYZ, values(PQR) AS PQR by ABC | fillnull PQR value="NULL" | timechart span=1d count by PQR ... View more

Well it's not a question we've seen before, but yes I think we can absolutely do well here. One similar thing that's come up a few times, is around fraud/security - finding inbound numbers that are suddenly making large amounts of outbound international calls. (!) 1) At the simplest level, being that which you can merely click your way to, in our app, Navigate in the menu to Report > General Report. Change the "type" pulldown at the top left to just "incoming" calls. a) then change the reporting row from saying of over time to instead say of over and also set the "sort by" pulldown (which will then appear) to say "calls descending" OR another report that you might find useful is to: b) change the reporting row to of by callingPartyNumber and same thing - set the sort by. This will show you the outside parties who have called the largest number of different numbers. 2) At progressively more sophisticated levels, in the app we can a) combine those two metrics in a single report. b) have a sort of two level approach, where we find over a few weeks, what numbers are the top callers by one or both of these metrics, bake that list into a lookup once a day and then search for those numbers explicitly against only the last few hours or 24 hours worth of calls. 3) of course... I wonder if other software or another tool is capable of providing an explicit list of suspected spam numbers? I'm suddenly curious how android does it. Ingesting that list into splunk independently, or putting it into a Splunk lookup, might offer both a better and shorter path to success. And it's easy enough to wire in custom pieces like that into the app. For instance I could help you turn this into a new field called simply "is_suspected_spam_caller" =0,1 or "spam_score" perhaps between 1 and 5 intended to resemble the email spam scores. ... View more