I believe that the documented procedure to write to the meta file using a transforms to do so is here: http://docs.splunk.com/Documentation/Splunk/latest/Data/Configureindex-timefieldextraction While it may be undocumented to use the _meta field in the inputs.conf file on a forwarder, this is currently still a valid method for adding metadata to your fields. Take a look at the following answer post: http://splunk-base.splunk.com/answers/1453/how-do-i-add-metadata-to-events-coming-from-a-splunk-forwarder as it mentions this method as well. So you may want to move the _meta field from the forwarders inputs.conf file to the transforms.conf file on the indexer. This might be easier to maintain in the future as well. ... View more

Could you please try changing your original regex character class so that it is similar to the following: EXTRACT-switch_port = (?i)\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}\s(?<switch_port>[\w:\/.]+) ...and see if that will work better for you? The PCRE library was updated with 4.3 and it has become slightly stricter with how it is used. Alternatively, you may want to try the following regex: EXTRACT-switch_port = (?i)(?:\d{1,3}\.){3}\d{1,3}\s+(?< switch_port>\S+)\s+ ... View more

Splunk bug SPL-55476 was created to address this issue. Thanks everyone that continues to reference this answer post. ... View more

Hi Kinkdotcom, There are a couple of different workarounds we can use that mostly deal with re-formatting the _si field. For example you can include the following in the scheduled search to change _si="hostname\r\nindexname" to _si="hostname, indexname": | rex field=_si "(?<siHostName>.*?)[\r\n](?<siIndexName>.*?)" | eval _si=if(siIndexName!='', siHostName.", ".siIndexName, siHostName) Unfortunately, there is not really a good way to do this using props and transforms as we can not concatenate fields at that point. However, if you wanted to you could run the regex extracts with a props.conf line in the appropriate stanza and only use one eval in your search to provide the concatenation. This would look sort of like this; #in props.conf [<source|sourcetype|host>] EXTRACT-myNew_si = (?<siHostName>.*?)[\r\n](?<siIndexName>.*?) in _si then your search just needs to include the following eval; | eval _si=if(siIndexName!='', siHostName.", ".siIndexName, siHostName) This will help to shorten your search string a bit while maintaining the same fundamental extractions. Finally, the reason for using the eval if() is to make sure not to add the comma separation when we have a blank index name value as this gets saved back to the _si field which is contained within $SPLUNK_ARG_8. ... View more

Thanks for that dwaddle! I like it, its sort of temporarily replacing the null value with an empty value and concatenating for a new field. ... View more

Nice tight regex and great additional details! ... View more

Very nicely put. +1 ... View more

Pretty sure that there is no way to do this when the outputcsv command is called to generate the csv file with events from your search results. I would recommend using a script to clean up the CSV file after its been generated for which SED would be useful or using batch/cmd/powershell on Win systems. ... View more

To make this a permanent change edit your /etc/security/limits.conf file and append the line splunk - as 1572864 to the config file. This will set both the hard and soft limit for the splunk user. ... View more

Yep, you can still do that on the indexer using your inputs.conf to redirect to different indexes for all your sources. The Cisco devices dont need to have a forwarder in between the devices for the info to get parsed. You simply need to create a stanza for each source that you receive on the indexer using the inputs.conf file and specify the index. ... View more

Ok, I take it you are using a Universal Forwarder. Is it possible for you to add the stanza's you want to the indexer? You would need to put your props and transforms there as well if you wanted to use those to redirect events to another index. That will definitely work. ... View more

In that case put that on your main forwarder, but you may want to test everything with a test index first to be sure you are getting the data you are looking for 🙂 ... View more

Sorry, this would be on the indexer. As long as your syslog source is pointed at the indexer then the indexer will listen on that port for event data and then put it in the index defined above. If you need a full directory path as to where this goes, it should be in $SPLUNK_HOME/etc/system/local/ or $SPLUNK_HOME/etc/apps/customApp/local/. ... View more

Actually I think you can do this a bit easier with editing the inputs.conf file for each source/index on the indexer. [udp://hostnameommitted.com:514] index = MyForcedIndex Additionally, this can set the host field with different values as well using the connection_host = [ip|dns|none] config under the desired stanza. You might wish to take a look at the inputs.conf.spec file for some additional info for setting this up. Here is a link to an example on Splunk docs.. http://docs.splunk.com/Documentation/Splunk/latest/admin/inputsconf ... View more

This can be done using a scheduled search in conjunction with altering your search to use the index time rather than the indexed event time to create the CSV file you are looking. So you will want to use something like... sourcetype="Symantec" | eval myTime=now()-60 | where _indextime>myTime | outputcsv myFile.csv To break down the important pieces of this search, the | eval myTime=now()-60 portion uses eval to create a field which contains the epoch time stamp value of when the search is run and subtracts 60 seconds from that value. We then use the | where _indextime>myTime statement to get all the events from the last minute by comparing an events index time against the myTime value. If you run your scheduled search for every minute then the search will only contain events logged within the last minute. This should prevent most cases of duplication for the events that are put in to your CSV file. Depending on how often you run the scheduled search, you will want to change the myTime value to correspond to the time frame of your scheduled search. In doing so, remember that all the values are in epoch time using seconds. ... View more

What _d_ mentioned looks good and I would say that you might want to double check the path and permissions for the files to be monitored as well as the access rights for the Splunk user when running your search, including making sure that the Splunk user has access to the index you are sending these events to. So using: [monitor:///usr/sap/IXD/SYS/profile] disabled = false index = erp crcSalt = <SOURCE> Followed by making sure that when you search that you specify search index="erp" * Should be fine as long as all the requirements are met for monitoring all the files. One last thing to consider. Is there any sort of file lock that might be on those files that would prevent Splunk from opening them to index? ... View more