The maximum number of consecutively indexed events from a single source with identical timestamps to the second is 100,000 (per unique combination of indexer/index/host/source/sourcetype). At that point, Splunk will increment the seconds clock. You can not raise that limit. It is possible to have more events than this indexed by indexing other events from the same source with a different timestamp in between each batch of 100,000 or less. However, if there are more than 200,000 events indexed within the same second, those events will not be searchable or returnable in results (at least not in any reliable way), so you should not attempt to do this. It would be possible to work around this limit by modifying any one of the host, source, or sourcetypes to keep the number of events with the identical combination below 200,000. Doing this allows the events to be within the same second, and keeps them searchable. Having different millisecond (or finer) counters for events does not affect these limits, i.e., even if you have different subseconds for every one of the 200,000 events, you will still have this limit. ... View more

As far as I can see, and testing in Splunk 4.0.8 using rex , EXTRACT in props.conf, and a REPORT clause, there appears to be nothing wrong with it (assuming it correctly captures your fields). Where are you seeing this error? Update: in the IFE, as GpMidi says, you can use only named captures, i.e., implicit captures like (...) are not accepted. If you just wish to group (without an implicit capture), use (?:...) instead. So your regex in this case would have to be: (?P<AUTH_PIN_TYPE>[^ ]+)(?: [^ ]+){2}$ ... View more

It is possible to run an outer search the way you want with the map command, one time over each inner search result. However, this is extremely inefficient in Splunk, and it is likely that there is a much better way to do it using a subsearch as described by hulahoop. The difference is that you'll have to execute n+1 searches (where N is the number of inner search results) instead of 2 searches. To a first approximation, this will take (n+1)/2 times as long. ... View more

To be honest, I don't know why the error shows up. Possibly it's just because the message is at too high an alert level. You can fix this however by editing the savedsearches.conf file and removing the vsid property on the saved search. This will lose the viewstate properties, but viewstate should be considered transient anyway. (You should explicitly say how you want results to be rendered when you define your dashboard and modules and not rely on viewstate.) ... View more

I would alert on the search (over all time): sourcetype=mystatusevents foo=* | head 2 | dedup consecutive=true foo and alert if the number of results is more than 1. If you need to be alerted, you should schedule to search to run more frequently than these status events get logged, or you can increase the "head" parameter, e.g., if you make it "| head 20" you need to run the search more frequently than it takes for 19 events to be logged. ... View more

There's probably a better way this could be built into Splunk, but here's how I would go about it. First, let's assume that every config is just a file, and it's all on one known host. Then I would set up fschange monitoring on all the relevant files on the "good" server, and have it generate a hash (set hashMaxSize large enough to include all your files). Next, we schedule and run a search to generate a lookup table: host=goodhost sourcetype=fs_notification | rename hash as goodhash | dedup path | fields path,goodhash | outputlookup goodconfig.csv On the clients, we also fschange the relevant files. Then we could do: host!=goodhost sourcetype=fs_notification | dedup host,path | lookup goodconfig.csv path OUTPUT goodhash | where hash!=goodhash This assumes the file paths are the same, though you could use "eval" to appropriately do string transformations as needed. Now this could be extended to other sorts of objects other than files, as long as we had a way to create a listing of object IDs, corresponding to the file path in the case of files, that match between the "good" source and the "questionable" source, and a way to generate a key on the object contents (such as the fschange input or a custom scripted input). And I suppose in general, if you used consistent field names (e.g., objectPath, goodHash) when writing out the "check" results, and just a limited number of sourcetypes, then it should be easy to keep the lookup table generation and search quite simple. ... View more

Ah, yes. Quoting of double-quote characters and backslashes inside of rex strings is going to be confusing and problematic. I'd advise you if you're doing this to put the regexes into props.conf/transforms.conf and use the "extract" command to call them. If they're in the file, you can use plain PCRE syntax without worrying about how they might get transformed and passed inside the string. ... View more

Distributed search is always configured one way at a time, from a search head node to an index node. If you configure A to be allowed to search B, server B will not be able to search A (unless you specifically perform the configuration steps to do so). If server B is already able to search server A, then in addition to removing A from server B's distsearch.conf file, you should also remove server B's authorized key from server A's $SPLUNK_HOME/etc/auth/distSearchKeys/ folder. If you do not do so, then an administrator of B (who is not an administrator of A) can regain access to A simply by adding A back to the distsearch.conf file. ... View more

What Vi Ly replied is right. It may also help you to use the "format" command. When a subsearch is used as an argument to a "search" command, its output is implicitly passed through "format" (unless it has already been explicitly sent through format) to convert it into a single string value (called either "search" or "query"). That string is then expanded into arguments to the original search command. So for example: | stats count | eval latest="-18d" | fields + latest | format yields a string: ( ( lastest="-18d" ) ) or something like that. That string would then be made part of your original search command in place of the subsearch. The "format" command take take an entire table and format it, so if your subsearch returned the table: field1 field2 field3 ------ ------ ------ red 14 cow black 7 wolf "format" would return: ( ( field1=red AND field2=14 AND field3=cow ) OR ( field1=black AND field2=7 AND field3=cow ) ) by default. If used in a subsearch in a "search" command, then, that query would be part of your search. Note that arguments to "format" can change the "AND", "OR" and parentheses to other characters (e.g., it is sometimes useful to generate a string like the above, but where "AND" is replaced with "OR"). ... View more

You can pipe the events through | dedup consecutive=true fieldname sourcetype=mydupeylog | dedup consecutive=true mydupeyfield ... View more

If the incoming events have time stamps already on them, or the time stamp is in the file name, you can configure Splunk to parse the time stamp and apply it to the events. Many time formats will be automatically recognized, or you can specify one explicity with settings available in props.conf. When you view them, you can ask for any time range of events, or use reporting commands to group them by any span of time, e.g. sourcetype=mydate earliest=-60d latest=-1d | timechart span=1d count If the events are not stamped with a time, and you want to indicate their time using the current time, you can configure Splunk to stamp them the current time by using DATETIME_CONFIG = CURRENT for the incoming data's sourcetype (or source or host) in props.conf ... View more

The high-level answer is that props.conf says what rules are applied to any event and when they are applied, and transforms.conf actually defines those rules. So in props.conf, you say "events with the sourcetype XXX has the extraction YYY applied to it at parse time" or "events from host HHH has lookup JJJ applied at search time". transforms.conf would specify exactly how extraction XXX worked, or where lookup JJJ comes from. This is generally true, though it's a little muddied because some of the rules are specified directly in props.conf. Some of these (e.g., rules for parsing timestamps or line breaks) are only specified in props.conf, while others (search time field extractions) can be either directly defined in props.conf, or referenced back to transforms.conf ... View more

There are two easy ways to make everything in an app globally available: Conf file: Place the following into the file SPLUNK_HOME/etc/apps/my_app/metadata/local.meta, creating the file if necessary: [] export = system GUI: Go into Manager, Apps, select the "Permissions" link for the app, and set "Sharing for config file objects" to "all apps". This generates the same file in the same place as the conf file method. ... View more