Agreed, it should be extremely fast for Splunk to dispatch an inputlookup search, have that search complete and have the client side modules pull down the results. Especially when the lookup is very small, the whole thing should be instantaneous. Unfortunately there's a bit of overhead in the search dispatching logic inside the Splunk Server itself, and this adds about a second or two. The worst thing in this case is that when the next search is dispatched, the modules downstream clear themselves, and this is the "flashing". It's particularly annoying if it's literally taking away the content for a second, then reloading the same content. Cooking up a testcase locally, with a combination of small lookups and large lookups, I'm surprised how long the searches take to "complete", even for the tiny lookups. the UI actually has to poll the search API several times before Splunkd gives the OK that the search is finished. So unless we can eliminate the actual search dispatches, there's not a lot that can be done. Leaving out the Tabs module, the xml looks like this: <module name="Switcher" group=" "> <param name="selectedGroup">$selectedTab$</param> <module name="Search" group="test1"> <param name="search">| inputlookup lookup1</param> <module name="Pager"> <module name="Table" /> </module> </module> <module name="Search" group="test2"> <param name="search">| inputlookup lookup2</param> <module name="Pager"> <module name="Table" /> </module> </module> <module name="Search" group="test3"> <param name="search">| inputlookup lookup3</param> <module name="Pager"> <module name="Table" /> </module> </module> </module> </module> So let's talk about why and where the searches are dispatching and redispatching. The answer is that the "dispatch points for the three searches are downstream from the Tabs modules". If your response to this is "huh?" then read the very important page in the Sideview Utils docs, "Introduction to the advanced xml". To change it to make the push from the Tabs module not dispatch the search at all, we have to "move the dispatch point above the push". Yes this is a bit insane. Just read that page again. There's a reason why the Sideview Utils homepage tells you to read it a few times. In a nutshell though, what's happening is that the Tabs module starts a cascading push downstream through the modules. Because of how the modules are arranged, the search(es) dont get dispatched until a point downstream from the Tabs. But if we glom together all three inputlookup commands into one large search result, using the handy "append=t" option in the inputlookup command, then we can move this single giant Search above the Tabs, and then use three different PostProcess requests under the Tabs to pull out the right data. <module name="Search"> <param name="search">| inputlookup lookup1 | inputlookup lookup2 append=t | inputlookup lookup3 append=t </param> <module name="JobProgressIndicator" /> <module name="Tabs" layoutPanel="panel_row1_col1" > <param name="name">selectedTab</param> <param name="staticTabs"> <list> <param name="label">test1</param> <param name="value">test1</param> </list> <list> <param name="label">test2</param> <param name="value">test2</param> </list> <list> <param name="label">test3</param> <param name="value">test3</param> </list> </param> <module name="Switcher" group=" "> <param name="selectedGroup">$selectedTab$</param> <module name="PostProcess" group="test1"> <param name="search">search call_connected=*</param> <module name="Pager"> <module name="Table" /> </module> </module> <module name="PostProcess" group="test2"> <param name="search">search code=* NOT call_connected=*</param> <module name="Pager"> <module name="Table" /> </module> </module> <module name="PostProcess" group="test3"> <param name="search">search field=*</param> <module name="Pager"> <module name="Table" /> </module> </module> </module> </module> </module> Note that the Search is above the Tabs now. And note that there is a JobProgressIndicator just below, as a sibling to the Tabs. This means that when the Tabs module gets its data from upstream, the search will already have been kicked off. So subsequent clicks (and therefore pushes) at the Tabs module wont need to redispatch any search(es). And note that one tricky part, is to figure out what search criteria in the PostProcess will tease apart the right lookups into the right tabs. the searches that I left in there are remnants of the three callmanager lookups I was using in my testcase, and you will have to find your own search terms. And it is indeed much faster this way. There's hardly any noticeable flash. ... View more

So to recap, you have a table with a number of fields. One of these fields is "testcolumn4". You want the drilldown to basically pass only the value of this column. In your example the value is "testfield10". And you want to send the user to the default search view and run a search that includes the value from the clicked-on row, "testfield10"? If that's the case, here is sample XML to do that. I'm also passing the drilldown timerange for you, because that's a best practice. And I took the liberty of replacing some core Splunk modules with the newer Sideview equivalent. <module name="SavedSearch" layoutPanel="panel_row1_col1" group="test1" autoRun="True"> <param name="useHistory">True</param> <param name="name">test1</param> <module name="JobProgressIndicator" /> <module name="Export"> <param name="exportType">results</param> </module> <module name="Pager"> <module name="Table" > <module name="Redirector"> <param name="url">search</param> <param name="arg.q">index=index1 $row.fields.testcolumn4$ | timechart count by testfield10</param> <param name="arg.earliest">$search.timeRange.earliest$</param> <param name="arg.latest">$search.timeRange.latest$</param> </module> </module> </module> ... View more

I'm afraid I can't reproduce any problem with this view, either in Firefox nor in Chrome 38.0.2125.104. The view loads fine in the Editor for me. I believe you though. What version of Sideview Utils are you on? If it's several releases old, there have been a number of fixes to the Editor and maybe updating will resolve the problem. You can always see the release notes here - http://sideviewapps.com/apps/sideview-utils/release-notes/ and you can get on the mailing list (to get emailed those release notes whenever there's an update) here - http://sideviewapps.com/apps/sideview-utils/mailing-list/ I would also try updating Chrome to 38.X ? ... View more

Anything you can do to preserve readability is pretty essential to success. In this case, I strongly recommend using CDATA to escape your HTML contents rather than manually escaping the characters. If I rewrite your XML this way and with proper indentation, it becomes very obvious what the problem is. The actual content of the table cell was output after the closing `` tag. Browsers will just sort of dump this content out and in this case it ended up overlapping the next element. <module name="HTML" layoutPanel="viewHeader"> <param name="html"><![CDATA[ <script type="text/javascript"> popupWindow = window.open(url,'popUpWindow','height=500,width=850,left=10,top=10,resizable=yes,scrollbars=yes,toolbar=yes,menubar=no,location=no,directories=no,status=yes') } </script> <table> <tr> <td width='100%'></td> <td align='left'></td> <a align='left' target="self" href="test1"><b>&#9668;test1&#9658; <a align='left' target="self" href="test2"><b>&#9668;test2&#9658; </tr> </table> ]]></param> </module> Just move those elements inside the TD and the problem will go away. Also, there are no closing tags for your or <b> tags and you should get those in there too. ... View more

Well, one unreliable method would be to go to Settings > Searches and Reports, and use the search bar at the top right to search for sourcetype="foo" . One problem is that some searches might use macros, or they might use wildcards in their sourcetype searchterms, or the search might not use quotes around the sourcetype value. Each of those scenarios would result in a search not matching although technically that search does itself match events of that sourcetype or index. Also sometimes the admin section search can match a little too liberally (I think it searches the raw atomfeeds, so if you search for structural words in the api feeds like "EAI" or "value" or "values", you'll always get all the results to match =/ ) A different approach might be to use the rest search command to pull all the searches and reports out of the API and then filter on them. | rest /services/saved/searches | table title search eai:acl.app eai:acl.owner eai:acl.sharing * However basically all three problems persist - macros, wildcards and presence/absence of quotes. We can deal with the quotes problem with an OR | rest /services/saved/searches | table title search eai:acl.app eai:acl.owner eai:acl.sharing * | search search="*index=\"_internal\"*" OR search="*index=_internal*" Otherwise, in theory we could deal with the macros problem by also using the rest command to pull out all the macros, use the append command to stick those on the end. Then make a multiple match regex to pull multivalue macro_name field out of our searches, normalize the macro_name vs "name" field with eval so they match. Then use eventstats by macro_name to roll up for every search, which macros it uses. Then we could make a big fake string-valued field that gloms together the raw search with the 0-n macros, and then filter against that constructed field. But that would be crazy. And we still wouldnt deal with the case where a search did things like sourcetype="access_*" Short Answer: if the searches dont use macros and dont use wildcards in sourcetype terms, yes! On the other hand if they do use macros and/or wildcarded values, then no not really. ... View more

OK. What is the kind of dashboard here? simple XML in 6.X? sideview xml? core advanced xml? simple xml in 5.X? Is postprocess involved at all? ... View more

What is the search syntax that you have right now? There's a good chance that the best answer is to rework what you have rather than adding more syntax on the end. ... View more

Well, the JSChart module lacks the Table module's "default" param options, meaning that barring custom JS patching, modules downstream from JSCharts will be hidden by default. So that rules out actually putting the set of Tabs downstream from the JSChart. And this does indeed take us back to the Gate module. 😃 But at least with the loadjob trick we have more degrees of freedom. I would explore having a Gate downstream from the JSChart and the other Gate just upstream from the Tabs module. And also bear in mind that if a Tabs module receives a $foo$ token from upstream, whose name (ie foo) matches it's own "name" exactly, and whose value matches one of it's values, it will switch to that Tab then and there.... So you could put an argument into the JSChart, send it across the Gate, and that should take care of the autoswitching part. The part of actually using $click.searchTerms$ should be fairly obvious. And my last piece of advice is try not to worry about passing the timerange explicitly - most likely it'll just get passed through the Gate when relevant without any extra effort. ... View more

Very detailed writeup. I know that in the older versions of the UI the i18n coverage was tricky to keep at 100%. Out of curiosity, and a selfish desire to find bugs I can fix, have you found any untranslated strings with views built with the advanced xml or sideview xml? ... View more

There's some ambiguity in your last question, but I think the best thing is for you to play around with eventstats vs stats. Basically eventstats keeps the incoming rows the same (ie doesn't transform them), and just paints extra fields onto those rows. The answer to your last question may involves changing | stats avg(Duration) as AvgDuration last(globalAverageDuration) as globalAverageDuration by Channel to | eventstats avg(Duration) as AvgDuration last(globalAverageDuration) as globalAverageDuration by Channel . eventstats with a by clause is quite subtle in that it will keep the rows the same, but do the calculations for the extra fields such that all rows with Channel="A" are treated together and will get the same extra field values. ... View more

Here's another solution that avoids using a subsearch. sourcetype="System Logs" "Setting status of job" (JobStatus="RUNNING" OR JobStatus="FINISHED") | stats last(_time) as _time last(Project) as Project values(JobStatus) as JobStatus by Job_Number | search JobStatus!="Finished" How it works is that the stats clause rolls up the results so each row represents one Job_Number. For each row the values() clause makes a Multivalue field called JobStatus. Then the search clause at the end filters out any rows that had a second value of JobStatus="Finished". This will leave only the rows that had started but not finished. For smaller use cases, like if you know there are always less than 50,000 Jobs, or where the subsearch for just the finished events will always takes less than a minute, the solution posted by the_wolverine that uses a subsearch will be better and slightly faster. For cases where you might have more than 50,000 rows, you'll hit subsearch limits whereas this search will remain accurate. ... View more

Oddly, it sounds just like a longstanding bug in Splunk's SingleValue module, ie in the "advanced XML", (or a single element in the 5.x simple xml, which amounts to the same thing). That bug makes the element always display N/A if the main search results return no result rows, even if after being postprocessed, they return some rows. If that fits here, you might try replacing it with the sideview xml equivalents, which are either Link + Redirector, or the HTML module. Otherwise is postprocess involved here at all? If so, I would double check that the base search syntax plus the postprocess syntax, doesn't throw an error when combined manually into a single search run in the default search UI. ... View more

I would break this apart into a more explicit eval clause that creates a temporary field value, and then a simpler stats clause that operates on that field value. that way you have hte full breadth of the eval command rather than the (I think) more limited syntax supported in stats/chart/timechart | eval type=if(searchmatch("Error") OR searchmatch("Attempt 3...unsuccessful."),"succeeded","failed") | stats count by type` or for a different approach | eval isFailure=if(searchmatch("Error") OR searchmatch("Attempt 3...unsuccessful."),1,0) | stats sum(isFailure) as failures` ... View more

You can use the if() function or the case() function in the eval command. When used in conjunction with all the other functions available to the eval command, you can do a wide assortment of manipulations. For instance if you want to add a custom field to the events that reflects whether they occurred in the last 24 hours or merely in the last week or just in the last month, you could do | eval period=case(_time>relative_time(now(), "-24h"),"last 24 hours",_time>relative_time(now(),"-7d"), "last 7 days",_time>relative_time(now(),"-30d"),"last 30 days") http://docs.splunk.com/Documentation/Splunk/6.1.3/SearchReference/CommonEvalFunctions Effectively this gives you powerful tools to filter, transform and change the key value pairs in your result rows. Trying to conditionally present those results however, takes you into a different realm. There you can use the Sideview modules ResultsValueSetter to pull dynamic field values down to the UI, and other modules to affect presentation or to present them entirely different ways. A pretty different topic though. ... View more

oh goodness. That's quite different. I'll update my actual answer. ... View more

Well, unless I'm misunderstanding, if you want to end up with one channel per line, it's the first search I suggested in my answer, and it's MUCH simpler. index=Main Channel=* StartTime=* EndTime=* | eval Duration = EndTime-StartTime | stats avg(Duration) as AvgDuration by Channel | eval AvgDuration = strftime(AvgDuration/1000 , "00:%M/:%S:%3Q") but of course then there's no "difference from average" cause each line just has the average. ... View more

index=Main Channel=* StartTime=* EndTime=* | eval Duration = EndTime-StartTime | streamstats avg(Duration) as AvgDuration by Channel | eval Difference = (Duration - AvgDuration)/1000 | eval AvgDuration = strftime(AvgDuration/1000 , "00:%M/:%S:%3Q") | eval Duration = strftime(Duration/1000 , "00:%M/:%S:%3Q") Will give you the difference as an integer number of seconds. You can't strftime it quite as easily as these others, since strftime wont accept negative integers as input. So we have to be more clever. index=Main Channel=* StartTime=* EndTime=* | eval Duration = EndTime-StartTime | streamstats avg(Duration) as AvgDuration by Channel | eval Difference = (Duration - AvgDuration)/1000 | eval AvgDuration = strftime(AvgDuration/1000 , "00:%M/:%S:%3Q") | eval Duration = strftime(Duration/1000 , "00:%M/:%S:%3Q") | eval differenceParity=if(Difference>=0,"+","-") | eval Difference=abs(Difference) | eval Difference=differenceParity + strftime(Difference/1000, "00:%M:%S:%3Q") ... View more

I think you just need to set charting.legend.placement to "bottom" In Sideview Utils XML, <module name="ValueSetter"> <param name="arg.charting.legend.placement">bottom</param> In Advanced XML: <module name="HiddenChartFormatter"> <param name="charting.legend.placement">bottom</param> And in simple XML, I believe you would add this to your `` <option name="name">charting.legend.placement</option> ... View more

This is actually caused by a minor bug in the Radio module, in that the module makes no effort to make a $foo.label$ key available for downstream modules. A fix is already in place and it will ship in the next release (3.3.1) . Sorry I was initially confused because I misread your question reading Pulldown for Radio, and this bug doesn't exist in the Pulldown module. For completeness, there are 5 modules that share extremely similar conventions and params. Of these the most commonly used and the most extensively documented is "Pulldown". In practice if you get familiar with the Pulldown and the various pages of Pulldown docs and examples, the same conventions and params exist over in the other 4 modules, although these other modules have less verbose docs and fewer explicit examples. These 5 cousins are Pulldown, CheckboxPulldown, Tabs, Radio and the Checkboxes module. Of these 5, Radio and Checkboxes were both by mistake were given no $foo.label$ feature, and both will be fixed in 3.3.1. ... View more