So i'm curious, I installed the Windows rsyslog agent on a windows box because I like the idea of being able to use SSL/TLS on a local machine without first having to stage the syslog information on a server. My environment dosen't lend itself to that.
I'm curious, is there a better way to make these log outputs readable? This seems like one heck of a regex undertaking.
I figure that it would be easier to use the Universal Forwarder for Windows Event Logs, and use the rsyslog for other "stuff". I was just curious to get someone's opinion on this. This seems like some really messy output, but that could also be lack of my knowledge. I'm pretty new to Splunk.
{"source": "mycomputer", "nteventlogtype": "Security", "sourceproc": "Microsoft-Windows-Security-Auditing", "id": "5156", "categoryid": "12810", "category": "12810", "keywordid": "0x8020000000000000", "user": "N\A", "Param0": "4084", "Param1": "\device\harddiskvolume1\windows\system32\svchost.exe", "Param2": "%%14592", "Param3": "239.255.255.250", "Param4": "1900", "Param5": "192.168.1.110", "Param6": "48860", "Param7": "17", "Param8": "0", "Param9": "%%14610", "Param10": "44", "Param11": "S-1-0-0", "Param12": "S-1-0-0", "ProcessID": "4084", "Application": "\device\harddiskvolume1\windows\system32\svchost.exe", "Direction": "%%14592", "SourceAddress": "239.255.255.250", "SourcePort": "1900", "DestAddress": "192.168.1.110", "DestPort": "48860", "Protocol": "17", "FilterRTID": "0", "LayerName": "%%14610", "LayerRTID": "44", "RemoteUserID": "S-1-0-0", "RemoteMachineID": "S-1-0-0", "catname": "Filtering Platform Connection", "keyword": "Audit Success", "level": "Information", "serviceguid": "{B5D98D32-1234-4A70-A754-9392A02E3111}"}
Best practice is to install the universal forwarder for anything related to Windows event logs. We went through a painful experience by not following this practice.
It has a really small footprint and should not affect sever performance.
The forwarder also brings with it numerous benefits as opposed to syslog. Metrics data being one that we leverage quite extensively. it allows you to monitor data sources in a uniform way to determine last event indexed, kbps thruput, eps, etc etc
It also allows you to use the deployment server to centrally manage forwarder configs which is very very handy. combined with the deployment monitor app and you've got a robust enterprise grade implementation.
So yes... use the forwarder wherever possible and syslog for other "stuff".
http://docs.splunk.com/Documentation/Splunk/latest/Data/MonitorWindowsdata
Best practice is to install the universal forwarder for anything related to Windows event logs. We went through a painful experience by not following this practice.
It has a really small footprint and should not affect sever performance.
The forwarder also brings with it numerous benefits as opposed to syslog. Metrics data being one that we leverage quite extensively. it allows you to monitor data sources in a uniform way to determine last event indexed, kbps thruput, eps, etc etc
It also allows you to use the deployment server to centrally manage forwarder configs which is very very handy. combined with the deployment monitor app and you've got a robust enterprise grade implementation.
So yes... use the forwarder wherever possible and syslog for other "stuff".
http://docs.splunk.com/Documentation/Splunk/latest/Data/MonitorWindowsdata
As messy as that is, the Splunk props and transforms can make easy work of it. This performs search-time extraction of the values.
[win_rsyslog_sourcetype]
REPORT-rsyslog-trans = rsyslog-values
[rsyslog-values]
DELIMS = ",", ":"
I'd put them on the Search Head, which may be on the same server as the indexer. /opt/splunk/etc/system/local should work for you. Make sure that your input defines the sourcetype to match the props.conf sourcetype.
Both of these on the receiver i'm assuming? Is it in /splunk/etc/system/local or /default?
So i made the changes on both the local and default, restarted the splunk server, and then ran this search as a test, but I didn't get any results:
sourcetype="syslog" |table Direction ProcessID RealSource source