Wish Granted!!! In Splunk 6.6 - Search command supports IN operator sourcetype=xyz status IN (100, 102, 103) Eval and where commands support in function | where in(status,"222","333","444","555") ... View more

The number of searches that you run does affect the disk space on a search head. The results of searches are stored in $SPLUNK_HOME/var/run/splunk/dispatch You could look at your existing servers to see how much disk space this requires. It is probably tiny compared to your indexes... On a search head, I usually set up a dedicated drive or mount point for the $SPLUNK_HOME/var directory tree. That way it is easy to monitor. The var subdirectory contains all of the "dynamic" files that are created: log files, search results, etc. In addition, do NOT store the summary indexes on the search head. The best practice is to forward summary indexes to the indexers. While you don't have to follow this best practice now, perhaps, you should. Here is how: Best Practice: Forward search head data to indexing layer ... View more

tl;dr YES Any Splunk instance can use any management port that you like - they don't need to be all the same. However, if you want to connect to the cluster master node or the deployment server, etc., you will need to know what management port to use for that instance. DO NOT USE THE MGMT PORT FOR FORWARDING. Indexers must be set up with a receiving port. The Splunk-to-Splunk forwarding of data uses that port, not the mgmt port. In outputs.conf, you can give a fixed list of servers that includes the receiving port, eg. server=indexer1.myco.com:9997,10.2.15.201:9998 OR you can use indexer discovery if you are using indexer clustering. When the forwarder talks to the cluster master node, it is not sending data. Instead it is querying the master node for the server list. So the forwarder must contact the master node on its management port. For example, if the cluster master node is 10.2.15.200 and its mgmt port is 8089, then outputs.conf on the forwarder should contain master_uri = https://10.2.15.200:8089 HTH ... View more

I think you will be much better off if you use tokens for this. In the following sample, I did most of the work with tokens - the actual search is quite simple and fast <form> <label>Sample</label> <fieldset submitButton="true"> <!-- Create inputs for user here too--> <input type="dropdown" token="period_tok"> <label>Comparison:</label> <choice value="week">This Week vs Last Week</choice> <choice value="month">This Month vs Last Month</choice> <default>This Week vs Last Week</default> <change> <condition value="week"> <set token="date_label">This Week vs Last Week</set> <set token="earliest_tok">-2w@w</set> <set token="latest_tok">@w</set> <set token="split_tok">-1w@w</set> </condition> <condition value="month"> <set token="date_label">This Month vs Last Month</set> <set token="earliest_tok">-2m@m</set> <set token="latest_tok">@m</set> <set token="split_tok">-1m@m</set> </condition> </change> </input> </fieldset> <row> <panel> <title>Comparison of $date_label$</title> <chart> <search> <query><![CDATA[index=x user=$user|s$ | eval reportKey=if(_time < relative_time(now(),$split_tok|s$),"Last ","This ") . $period_tok|s$ | timechart span=1d avg(duration) by reportKey]]> </query> <earliest>$earliest_tok$</earliest> <latest>$latest_tok$</latest> </search> <option name="charting.axisTitleX.text"></option> <option name="charting.axisTitleY.text">Average duration</option> </chart> </panel> </row> </form> ... View more

The syntax in line 22 is wrong. If you have selected "hostA" and "hostB" in the first multiselect, the query in line 22 becomes index=temptesting_007 host= hostA , hostB | stats count by sourcetype | sort limit=100 sourcetype Starting with Splunk 6.6, you can use the following syntax: index=temptesting_007 host IN ( $selected_host$ ) | stats count by sourcetype | sort limit=100 sourcetype ... View more

Try this: (index=mensa_exchange-prod sourcetype=iis cs_uri_stem="/owa/auth.owa" NOT LogoffReason=* OriginalIP=*) OR (index=mensa_radius-prod acct_status_type=1 acct_delay_time=0 vendor=Reserved NOT Wireless) | append [ search index=mensa_radius-prod vendor=Microsoft NOT Wireless | transaction user, Client_Friendly_Name maxspan=1 startswith=acct_session_id=* endswith=action=success ] | eval clientIP=if(index="mensa_exchange-prod",OriginalIP,tunnel_client_endpoint) | iplocation clientIP | search Country=* NOT Country="United States" | rex field=user "\w{3}\\\(?<user>\S+)" | eval User=lower(user) | stats values(Country) as country dc(Country) as Count by User But you do need to check the rex command - something got munged when you posted it, and I made an assumption. But it still seems weird to me. ... View more

Try this. I dropped the appendcols, as it will slow the search and it makes it harder to do the "fallback" that you want. This may not be exactly what you wanted, but I did this: I retrieved the the past 30 minutes of data and then broke it into 3 categories: the most recent 10 minutes (current), from 10-20 minutes ago (previous) and from 20-30 minutes ago (earliest). After counting the events in each category, I then checked to see if there were any events in the "previous" category. If there were none, I used the "earliest" category for the final comparison. index=circuit basequery1 earliest=-30m@m latest=@m | eval timeSlot=case(_time < relative_time(now(),"-20m"),"Earliest", _time < relative_time(now(),"-10m"),"Previous", true(),"Current") | stats count(eval(timeSlot=="Previous")) as previousMinuteCount, count(eval(timeSlot=="Current")) as currentMinuteCount, count(eval(timeSlot=="Earliest")) as earliestMinuteCount | eval compareWith = if(previousMinuteCount>0,previousMinuteCount,earliestMinuteCount) | where currentMinuteCount < 0.5*compareWith HTH ... View more

Try this NOT [ search source="my_source" users="*" Access="X" | stats count by users | fields users ] (source=B OR source=C) ... View more