I plan to take it out in the next release, probably before mid-month, Feb 2015. ... View more

Would it be possible to change that one host to a full Splunk (heavy forwarder) instance? Admittedly, I haven't had much luck trying to tweak the included Python, or to provide a replacement for it as you describe. ... View more

You can create a DELIMS based extraction (transforms.conf) to extract the subfields: [your\_transform\_rule] SOURCE\_KEY = PARAMS DELIMS = "|" FIELDS = mysubfield1, mysubfield2, ..., mysubfieldN Then, you'd call that rule from the props of your sourcetype, like this: [your\_sourcetype] REPORT-subfields = your\_transform\_rule ... View more

Typically there's one monolithic splunkd process, then two for each running search (a helper and the actual searcher). These may show "rt" in the search name if they are real time searches. Additionally, as @jeremiahc4 points out, other maintenance processes may start up additional copies of splunkd. ... View more

Yeah, no worries, I was just in process typing up the search idea. ... View more

I would approach this with a subsearch. The subsearch (when filtering) is evaluated first, and its results are passed to the outer search, similar to "here documents" in a shell. It looks to me like you want "find thing one, then go back up to a day and find thing two"? To make the search a bit easier, I'd actually turn the two around, maybe something like this. source2 [ search source1 | stats earliest(_time) AS earliest, latest(_time) AS latest | eval earliest=earliest-86400 | return earliest, latest ] | join dest_ip [ search source1 ... ] | dedup dest_ip | sort - _time My thinking here is that the time range picker will apply to the subsearch in the join, but our time math will govern the time range of the search on source2. ... View more

A day is 86400 seconds. ... View more

The problem you're having is that a wildcard in the path specification of a monitor: stanza is implemented on the backend of a monitor: of the longest fixed path, and a whitelist = * regex to match the specific entries according to the original monitor: stanza. This means that the monitor stanza for "/pack/jboss/server/staging_xxx/log/server.log" is a descendent of the (implicit) rule: "/pack/jboss/server" (with whitelist...). If the list of edu_ subdirs is not large, you could iterate each. You could also try this. Explicitly monitor the top-level directory, and include a whitelist to match the subpaths. [monitor:///pack/jboss/server] whitelist = (edu_.*|staging_xxx)/log/server.log sourcetype = server_log OMIT the sourcetype, but add a props.conf to include a source-based rule: [source::///pack/jboss/server/staging_xxx/log/server.log] index = foo [source::///pack/jboss/server/edu_.*/log/server.log] index = bar (I haven't tested this particular example, but I've done things like this in the past.) ... View more

Interesting. I don't see any issue with your rules, when I attempt to parallel them on my local instance. I stopped Splunk, created an entry for the sourcetype in my etc/apps/search/local/props.conf (to call the REPORT rules), and then transforms.conf (to define the regexes). Once I started Splunk and did a oneshot to add the data, I got field extractions without issue. Did you use the UI to write those rules (Settings -> Fields)? I wonder whether they're in user scope, rather than app scope. The method I described to create those settings puts them automatically in app scope (and the search app shares globally). What do you see for the permissions on those extraction rules? ... View more

Sounds like Splunk doesn't like the rule definition for secUploadExtract. I'll try to simulate it on my local box. ... View more

With DELIMS you'd have to provide a field name to contain either UPLOAD or DELETE, and then provide fields for the full possible with of how many fields may appear. Then, you could do an EVAL-based field keying upon the value of that "action" field (UPLOAD or DELETE, etc). This is admittedly messy. Let's see if we can't figure out what's wrong with your regexes. ... View more

Data preview may be wrong in this case. The other setting you could use is "SHOULD_LINEMERGE = false", since this data appears to be single-event-per-line. ... View more

You just need a TIME_FORMAT. The time stamp is occurring about 90 chars in, which is below the default MAX_TIMESTAMP_LOOKAHEAD of 128 chars. A suggested format reads as "%m/%d/%Y %H:%M:%S.%3N". Splunk is probably confused by the epoch time in milliseconds (with 7 more sigfigs of sub-millisecond appended) occurring in second position. Set the TIME_FORMAT explicitly and you should be in good shape. ... View more

I'd just have the Test1 rule look like this: [Test1] REGEX = %ASA-4-106023 DEST_KEY = queue FORMAT = nullQueue Wildcards aren't necessary for this particular filtration, and in fact, the bare * is confusing, it's intended to "repeat 0 or more of the prior character". ... View more

Is this output coming from a command being run on some schedule? Could Splunk be tasked with running the command to retrieve the results directly? ... View more

My reading of the settings in the props.conf documentation is that FIELD_NAMES are only used if the file doesn't seem to have a header, which it does. When I've seen this implemented for other data sources, FIELD_ALIAS is the most common means of mapping the "native" fields to the Common Information Model. You could also use DELIMS and FIELDS to capture space-separated fields in with the right names the first time, but then these are no longer indexed extractions, they are done at search time. ... View more

Did you use the literal string "CIM_FIELDS" in your FIELD_NAMES configuration attribute, or was that simply to represent a list? ... View more

Make that an answer and I'll upvote it. ... View more

Just don't give it any visualization, nor a layoutPanel attribute. ... View more