I thing the pieces you need are: An outputlookup to append to the search that detects the false positives and capture whatever identifying fields you need in a lookup table. An inputlookup to "load" the elements stored in the lookup table as search terms in your main search... ...using a carefully crafted subsearch to ensure that the fields that identify false positives obtained from the lookup are formatted as search terms that exclude the pertinent events. Pay special attention to the bits that explain how the results of a subsearch are formatted. ... View more

You have a couple of options. One is to use a multi-line regular expression and define a capture group targeted at the second occurrence of "Account Name:". ... | rex "(?ms)Account Name:.*?Account Name:\s+(?<account_name>\S+)" A different, perhaps more flexible way is to define a negative lookahead that will cause the regular expression not to match when "Account Name:" is followed by a hyphen. ... | rex "Account Name:\s+(?!-)(?<account_name>\S+)" ... View more

Indeed there is a simpler way. Try: eval t=_time ... View more

If you want to fiddle with this limit, you'll have to set higher values than the default for base_max_searches or max_searches_per_cpu in $SPLUNK_HOME/etc/system/local/limits.conf . From limits.conf.spec: [search] base_max_searches = <int> * A constant to add to the maximum number of searches, computed as a multiplier of the CPUs. * Defaults to 4 max_searches_per_cpu = <int> * The maximum number of concurrent historical searches per CPU. The system-wide limit of historical searches is computed as: max_hist_searches = max_searches_per_cpu x number_of_cpus + base_max_searches * Note: the maximum number of real-time searches is computed as: max_rt_searches = max_rt_search_multiplier x max_hist_searches * Defaults to 4 Do note, however, that 55 concurrent searches is already a pretty high number. If CPU is not a bottleneck (it seems that you have 16 cores on this machine), it's quite possible that I/O throughput and IOPS on the device hosting the indexes will be. ... View more

How about: REGEX = \.\w+(\.\w+)(?:$|/|:\d+) ... View more

I would suggest that you try the steps described in this Splunk Answer on your forwarder against the specific files you want to re-index. ... View more

This is a known bug in the current implementation of checkpointing for the OPSEC LEA app. Its internal defect reference is APP-70. The checkpoint which determines the offset of the last event we received from the OPSEC API gets reset to 0 when a connection attempt to the API fails. We are working to resolve this problem in a future release of this app. ... View more

Try: ... ¦ rex "System\.Exception:(?<Message>.*?Name\))" It would also help to append an expression segment right aftert the capture group that would only match the string that follows what you want to extract. ... View more

Updating a lookup table file by external means should be no problem as long as the name of the file remains the same. Splunk will re-read the file every time it needs to be used if it's very small, or reload it from disk when a change is detected if it's large. ... View more

In order to keep users from creating non-existing lookup tables using outputlookup, the command would need to be defined in commands.conf, which would allow role-based permissions to be set. This doesn't seem to be the case, but keep in mind that outputlookup can only write to $SPLUNK_HOME/etc/system/lookups or to $SPLUNK_HOME/etc/apps/{app}/lookups As for overwriting other users lookup tables with it, you should be able to prevent this by denying write permissions (in Splunk) to the tables that you don't want anyone messing with. ... View more

Looking at your outputs.conf, you have configured this search-head to forward any events it gathers back to your indexers: OutputApp [tcpout:indexers] OutputApp autoLB = true OutputApp disabled = false OutputApp indexAndForward = false OutputApp server = server1:9997,server2:9997,server3:9997,server4:9997,server5:9997 This is a very good practice in general, particularly if the search-head is doing a lot of summarization jobs, as it will spread the resulting events across your indexers and you will leverage distributed search even when searching against your summary indexes. The reason why you cannot find any events usually destined to _internal for this search-head has to do with the forwardedindex default settings in $SPLUNK_HOME/etc/system/default/outputs.conf : OutputApp [tcpout] (...) system forwardedindex.0.whitelist = .* system forwardedindex.1.blacklist = _.* system forwardedindex.2.whitelist = _audit system forwardedindex.filter.disable = false (...) From outputs.conf.spec: #----Index Filter Settings. forwardedindex.<n>.whitelist = <regex> forwardedindex.<n>.blacklist = <regex> * These filters determine which events get forwarded, based on the indexes they belong to. * This is an ordered list of whitelists and blacklists, which together decide if events should be forwarded to an index. * The order is determined by <n>. <n> must start at 0 and continue with positive integers, in sequence. There cannot be any gaps in the sequence. (For example, forwardedindex.0.whitelist, forwardedindex.1.blacklist, forwardedindex.2.whitelist, ...). * The filters can start from either whitelist or blacklist. They are tested from forwardedindex.0 to forwardedindex.<max>. * You should not normally need to change these filters from their default settings in $SPLUNK_HOME/system/default/outputs.conf. forwardedindex.filter.disable = [true|false] * If true, disables index filtering. Events for all indexes are then forwarded. * Defaults to false. This explanation is actually somewhat incomplete (don't worry, we're getting the spec file fixed in a future release): When events destined to a given index are filtered away from forwarding by a forwardedindex directive they are neither forwarded nor indexed!. This is why you cannot find any _internal events recorded by your search-head anywhere. To correct this, add the following configuration to $SPLUNK_HOME/etc/system/local/outputs.conf: [tcpout] forwardedindex.3.whitelist = _internal Note that we are considering to change this default behavior in the future and whitelist _internal for forwarding just like _audit is today. ... View more

I would try the like() eval function instead: | eval RoadLane=case(like(source,"C:\Project\TIRTL\Destination\SHB_001_%") AND LANE=="1","17", like(source,"C:\Project\TIRTL\Destination\SHB_001_%") AND LANE=="2","18",like(source,"C:\Project\TIRTL\Destination\SHB_001_%") AND LANE=="3","19") ... View more