All Apps and Add-ons

Windows Event Log collection via Microsoft SCOM 2007?

matthewhaswell
Path Finder

In connection to my question at the end of here: (http://answers.splunk.com/questions/1636/windows-event-log-collection-on-11000-devices/4739#4739)...

I thought I should split this off as a new question.

Basically we have a set of Windows platforms with custom software logging to the Application Event Log.

SCOM is going to be taking over from MOM and will be monitoring the systems. I am interested in Splunk getting a feed of all the logs in the Application Event Log too - I know that SCOM stores the event logs into a database - does anyone know how to either bend Splunk so it can read them from SCOM or to bend SCOM so it can produce logs that Splunk can read?

I am trying to avoid the hassle of putting Snare out onto the Windows servers as added resource load - but is this the only way? Also it is mentioned (in passing) on a few webpages that Snare converts Event Logs into text and loses a bit of the detail - are there any guides or examples of the differences between a Snare'd event and the full event using the Event Log Viewer?

Any help appreciated!

Matt

1 Solution

ftk
Motivator

In addition to attempting to pull data out of SCOM and using snare, there is another way to achieve your objective: use lightweight or regular forwarders.

A forwarder installs on your servers and can access and forward all your event logs (and other data you choose to monitor) to your indexer(s). This may be easier (and likely more efficient) than attempting to integrate with SCOM's database. In addition you benefit from buffering and SSL tunnels, as well as resuming forwarding of data after a network outage -- all things that you cannot get with SNMP.

Lightweight forwarders use only a small amount of resources and are easy to deploy.

For more information have a look at this: http://www.splunk.com/base/Documentation/latest/Admin/Aboutforwardingandreceiving

View solution in original post

Leo
Splunk Employee
Splunk Employee

matthewhaswell
Path Finder

Yes - I had looked at that but unfortunately it only forwards alerts (or events) depending on the rules set. So in order to get all the Application events I would have to get SCOM to look at all the events (instead of just the ones I am interested in).

It looks like SCOM prefers to use remote access to the events and doesn't pull them all to the central server - which I can understand but it's annoying to have to deploy another forwarder!

0 Karma

ftk
Motivator

In addition to attempting to pull data out of SCOM and using snare, there is another way to achieve your objective: use lightweight or regular forwarders.

A forwarder installs on your servers and can access and forward all your event logs (and other data you choose to monitor) to your indexer(s). This may be easier (and likely more efficient) than attempting to integrate with SCOM's database. In addition you benefit from buffering and SSL tunnels, as well as resuming forwarding of data after a network outage -- all things that you cannot get with SNMP.

Lightweight forwarders use only a small amount of resources and are easy to deploy.

For more information have a look at this: http://www.splunk.com/base/Documentation/latest/Admin/Aboutforwardingandreceiving

View solution in original post

matthewhaswell
Path Finder

I agree if we switch to syslog then that would have kept us independent but the splunk feed includes failover, buffering in case of network disconnect and fast reconfig of the agents with the deployment host. Depends if you can make a case for your IT budget and management priorities really. I could have set syslogs to forward direct to zenoss but we're hoping for a budget for something better later on.

0 Karma

matthewhaswell
Path Finder

Forward another year and a half - we have Splunk Universal agents out everywhere and are about to phase out Scom. We now have an eventtype.conf,tags.conf and lookup table solution that allows us to specify which events we are interested in and then launch a script to raise a relevant alert in our Zenoss monitoring system based on severity and event description in the lookup file. Someday I might document this up here if there is any interest - let me know.

0 Karma

FRoth
Contributor

The problem with the splunk forwarder is that you are fixed to splunk by using a proprietary protocol.
Using syslog to retrieve all log data to a single syslog server keeps all doors open.
You can process the syslog-messages with splunk and other tools at the same time. You can run analyzers on this data and archive it as you like. Using splunk forwarders the analysis and archiving is managed in splunk.

0 Karma

matthewhaswell
Path Finder

Forward about a year - we have deployed Lightweight forwarders to all our systems - and are consistently more stable than the Scom agents. Now upgrading them all to Universal Forwarders.

It's all working well - they are forwarding from each host to 2 "hot" Splunk heads. We have visability and graphs of windows events from our entire infrastructure and can quickly set up emergency alerts if we need to.

It doesn't directly compete with Scom - we have hundreds of rule sets on Scom that would mean hundreds of Searches on Splunk that which would be unweildy. Great for debugging and views though.

ftk
Motivator

Lightweight forwarders use very little resources and basically guarantee delivery of the events, remote WMI is works on a best effort basis and doesn't guarantee to complete all requests.

0 Karma

matthewhaswell
Path Finder

Hmmmm - have tried a test splunk forwarder - will probably convert to a light forwarder when I have finished configuration testing...

This is certainly useful - probably more than using Snare.

It does appear to be the only way unless anyone else knows better. Looks like I will just have to have the hassle of a remote forwarder. I assume the remote WMI event log access is even more of an event hog and I like the idea of the buffering after failure.

Many thanks!

0 Karma
.conf21 CFS Extended through 5/20!

Don't miss your chance
to share your Splunk
wisdom in-person or
virtually at .conf21!

Call for Speakers has
been extended through
Thursday, 5/20!