marksedam, There's no way to turn off the too_small behavior it seems, so we can deal with it at index time then. This won't be the cheapest possible way (in terms of CPU) to do so, but it should work for you. props.conf: [(?::){0}*-too_small] TRANSFORMS-remove_too_small = remove_too_small transforms.conf: [remove_too_small] SOURCE_KEY = MetaData:Sourcetype DEST_KEY = MetaData:Sourcetype REGEX = sourcetype::(.*)-too_small FORMAT = sourcetype::$1 ... View more

Esky73, You can accomplish this through the use of props / transforms. The general idea of what needs to be done is: props.conf: Create a TRANSFORMS- entry under the stanza "[syslog]" that calls a transforms.conf entry that contains a regex to re-sourcetype your events. transforms.conf: Create a stanza that's refrenced in props.conf containing a REGEX to match your events, DEST_KEY to set the destination of "FORMAT" to MetaData:Sourcetype and a FORMAT that sets the sourcetype to the desired new sourcetype. See example below. For this data, my best guess would be something like this: props.conf: [syslog] TRANSFORMS-rewrite_wireless_controller_st = rewrite_wireless_controller_st transforms.conf: [rewrite_wireless_controller_st] REGEX = \S+\s+stm[\d+]:\s+ DEST_KEY = MetaData:Sourcetype FORMAT = sourcetype::my_new_st This should re-sourcetype your logs to "my_new_st". Obliviously change that to whatever makes sense for your environment. The last thing to consider is that these configurations need to exist on the first full Splunk instance that sees this data. In a lot of environments this is the indexer but if you have Heavy Forwarders, then this configuration needs to be there. Lastly, if you need to further split this, you have the technique, just use additional transforms entries with regular expressions that fit the specific subset of data. Hope this helps! ... View more

Craig, You have the option to modify the output mode with your rest request by adding "?output_mode=json". You have a few options there and may like the field extractions better. That said, here's what I'd do for this data: Props.conf: [xml:data] KV_MODE = xml SHOULD_LINEMERGE=false NO_BINARY_CHECK=true CHARSET=UTF-8 disabled=false LINE_BREAKER=([\r\n\s]+)\ TIME_PREFIX=\ TIME_FORMAT=%FT%T%:z MAX_TIMESTAMP_LOOKAHEAD=30 TRUNCATE = 99999 TRANSFORMS-remove_header = remove_header Transforms.conf: [remove_header] REGEX = This\sis\sto\soverride\sbrowser\sformatting DEST_KEY=queue FORMAT=nullQueue To explain this a bit - We set critical props settings to ensure data is broken correctly and timestamped correctly. Next we remove the extra data from the event (that top piece) and nullQueue it with the transforms.conf. Lastly, we use "KV_MODE = xml" to get some field extracts working. The end result in Splunk - Automatically extracting fields on the XML data (granted the field names kinda stink). See the screenshot. ... View more

You're probably best doing everything in MB, then you can convert to GB when you'd prefer to display that way. Best of both worlds, so you don't lose resolution. You could accomplish this in Splunk with existing data dealing with both cases by the use of eval too (In this case, converting all to MB): |eval MEMTOT=case(like(MEMTOT, "%G"), (substr(MEMTOT, 1, len(MEMTOT)-1)*1024), like(MEMTOT, "%M"), substr(MEMTOT, 1, len(MEMTOT)-1), 1==1, MEMTOT) And the other direction (Converting to GB): |eval MEMTOT=case(like(MEMTOT, "%G"), (substr(MEMTOT, 1, len(MEMTOT)-1), like(MEMTOT, "%M"), (substr(MEMTOT, 1, len(MEMTOT)-1)/1024), 1==1, MEMTOT) The use of 1==1 in the case statement serves as a catch all (A nice trick for case statements) - In the event that there's no "M" or "G" we just keep the value un-altered. You could apply this method to as many fields as needed. ... View more

kiran331, You'll want convert to running as the Splunk user in a specific order: 1. Stop Splunk 2. chown -R splunk: /opt/splunk 3. splunk enable boot-start -user splunk 4. chown root:splunk /opt/splunk/etc/splunk-launch.conf (We want to ensure the Splunk user cannot tell itself to run as root, see: https://github.com/MattUebel/splunk_UF_hardening) The issue you have is Splunk was potentially writing out files after your chown as root still and the pidfile not readable by Splunk. ... View more

There are two situtions that snapshots could be run: A running host Splunk is constantly writing to hot buckets on the indexers. Taking a snapshot could cause corruption in any hotbuckets upon restoration. A stopped host This could work, if all hot buckets have been rolled to warm first. See https://wiki.splunk.com/Community:BestPracticesForBackingUp Something to keep in mind is the extra overhead of having a snapshot on a very busy host such as an indexer. A snapshot causes all changes to be tracked against a prior snapshot(s). This can get very expensive quickly. I'd recommend following Splunk's advice and not snapshotting the hosts. You'll be better served with a file level approach of backing up configurations and data. ... View more

jgcsco, It looks like the "csv" sourcetype utilizes "INDEXED_EXTRACTIONS" by default. This causes much of the props work to happen at the very first splunk instance the data hits, including Universal forwarders. If that's the case, you'd want to put your props there and utilize a few other config settings. Namely: [csv] FIELD_DELIMITER = , FIELD_NAMES = transactionId, hostIp, time, fqdn, MsgType, Severity MAX_TIMESTAMP_LOOKAHEAD = 10 TIME_FORMAT = %s TIMESTAMP_FIELDS = time INDEXED_EXTRACTIONS = csv Note the "TIMESTAMP_FIELDS" and "INDEXED_EXTRACTIONS". I'm setting "INDEXED_EXTRACTIONS" to be verbose and avoid confusion in the future. Additionally you do not need a timeprefix as you're specifying the specific field for Splunk to look at for a time stamp. You can check with btool what's being set on your sourcetype: splunk btool props list csv --debug This will show all the props settings for that stanza and where they're set. ... View more

Field-aliases can be a bigger determent to performance. Martin_mueller (https://answers.splunk.com/users/134323/martin_mueller.html) could probably answer this better than I can with his fantastic .conf talk on the subject: http://conf.splunk.com/session/2015/conf2015_MMueller_Consist_Deploying_OptimizingSplunkKnowledge.pdf My take-away is - I wouldn't spend a whole lot of time fixing existing sourcetypes, but if you're doing it for a new sourcetype then i'd utilize a regex. ... View more

This sounds like a use case for fields.conf. [myfield] TOKENIZER = ([^\|]+)\|? ... View more

TheFrunkster, I suspect you have to do your filtering at the syslog sourcetype, before the sourcetype rename. I'd recommend making the regex for [removeDNS] a bit more specific to the ASA logs then migrate the TRANSFORMS to [syslog]. ... View more

timmy13, I'd check your JRE path in the settings and ensure that's pointing to the version you'd like it to. Also, make sure you're using Oracle JRE, not openJDK/JRE You could try pulling down a version of Oracle JRE and extracting it to a specific path and pointing DB Connect to that version to ensure you're utilizing the correct version. If that fixes the problem i'd recommend installing it properly to /usr/lib and updating the path. ... View more