Since SQL Server Trace logs (*.trc files) are not plain text, it will not be readable once it's indexed within Splunk.
However, if you want to develop an input solution themselves, there are some .NET classes for reading them here:
http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.trace.tracefile_members.aspx
From what I can tell, they’re pretty straightforward, and even has an event that gets called when the file is added, which means you could write your own SQLTraceFile log tailing class.
Now if you wrote a script that called this class and scheduled it via Splunk Scripted Inputs, your script would have to account for and handle the rolled over files, or there might be issues over-indexing or duplicate events, etc.
However, if you don’t need the info in real time, then it’s probably easier to write a script that waits for a file to roll, moves it away, THEN processes it into text with SQLTraceFile API call (above), and finally let Splunk index that resulting text version of the events. Alternatively, you could write a preprocessor that works on a whole file and call it by setting the unarchive_cmd
option in props.conf
, though you'll still have to wait for a complete file to roll to use this option.
ExtraHop now has a Splunkbase app for database monitoring. Databases supported are Oracle, Microsoft SQL, Informix, DB2, Sybase and Sybase IQ, Postgres, and MySql.
http://splunk-base.splunk.com/apps/53757/extrahop.
Disclaimer: the Splunk App does require the ExtraHop APM platform to be installed which acts as non-invasive forwarder for Splunk.
Since SQL Server Trace logs (*.trc files) are not plain text, it will not be readable once it's indexed within Splunk.
However, if you want to develop an input solution themselves, there are some .NET classes for reading them here:
http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.trace.tracefile_members.aspx
From what I can tell, they’re pretty straightforward, and even has an event that gets called when the file is added, which means you could write your own SQLTraceFile log tailing class.
Now if you wrote a script that called this class and scheduled it via Splunk Scripted Inputs, your script would have to account for and handle the rolled over files, or there might be issues over-indexing or duplicate events, etc.
However, if you don’t need the info in real time, then it’s probably easier to write a script that waits for a file to roll, moves it away, THEN processes it into text with SQLTraceFile API call (above), and finally let Splunk index that resulting text version of the events. Alternatively, you could write a preprocessor that works on a whole file and call it by setting the unarchive_cmd
option in props.conf
, though you'll still have to wait for a complete file to roll to use this option.
If anyone had actually tried this and got it to work, please post any helpful hints or code logic, etc. It would be greatly appreciated.