Thanks For Downloading!Review the documentation below and follow any custom installation steps. If no install steps are listed, most Splunk Apps and Add-ons can be installed as follows: Windows: Decompress the downloaded file using a tool like 7-Zip and place the resulting folder into Unix/Linux: Decompress the downloaded file using a tool like DescriptionThe System Center Operations Manager (SCOM) integration accelerator automates the process of fetching events and alerts from SCOM and forwarding that data into Splunk. It makes it easy to use Splunk to search and report on SCOM-originated event and alert data, and enables correlation of SCOM data with data from other sources. RequirementsSplunk versions: Splunk 4.0 and higher Platforms: Windows Vista, 7, 2008 with Powershell 1.0 installed SCOM versions: Tested on SCOM 2007 R2 and later. The add-on has no known dependencies on R2, so it should work with R1. The legacy MOM environment is not supported. We recommend that the add-on be installed on the SCOM root server. Powershell requirementsPowershell 1.0 must be installed and the SCOM Powershell snap-in must be registered. Registration happens automatically when the SCOM operations console is installed. NOTE: By default Powershell has a security policy enabled that restricts execution of user scripts from the command line. To overcome this, we change the execution policy to the less restricted SupportThis add-on is community suported. This means that there's no formal support from Splunk available for this add-on, but free support is available on Splunk Answers and questions, bug reports, and feature requests will be addressed on a best-effort basis by the add-on's author or other community members.
Installation
ConfigurationThe add-on provides a setup page to configure SCOM-specific settings like SCOM hostname, polling interval, and inputs. This info is then written to bin\scom_client.xml. The powershell scripted input reads its configuration from this file each time it starts up. You can select whether to enable or disable forwarding for all events and/or alerts from the SCOM database. If the checkbox is selected, the script will request all events/alerts starting with the very first event/alert and forward those to Splunk. When the script reaches the most recent event/alert, it will switch to polling mode; in polling mode, the script waits for new events/alerts and forwards them as soon as they become available. No events/alerts filtering is available through the setup screen-- you can either get all events/alerts or none. How it works
PerformanceOur tests showed a throughput of about 3,000 events/min on a Xeon 3Ghz/4Gb Win2008 with full SCOM and Splunk installed at the same machine. The Powershell client process consumed around 3Gb of RAM while 800,000 events were being forwarded; the average CPU usage was 25%. Remote executionAs mentioned above, we recommend that the add-on be executed on the same box as the SCOM root server. If you do need to run it remotely:
Field namesMapping of SCOM field names to Splunk field names is hardcoded in the scom_client.ps1 script, but can be easily modified as needed in that script. Below is the full field mapping for alerts: SCOM Splunk ---------------------------------------------------- -------------------- TimeRaised _time MonitoringObjectDisplayName ComputerName Severity Severity Priority Priority Category Category ResolutionState ResolutionState Id Id ProblemId ProblemId Owner Owner LastModifiedBy LastModifiedBy Description Message Events also have their fields mapped: SCOM Splunk ---------------------------------------------------- -------------------- TimeGenerated _time Channel LogName PublisherName SourceName Number EventCode CategoryId EventType LevelId Type MonitoringObjectDisplayName ComputerName User User CategoryId TaskCategory Id Id Description Message Versions and Release Notes
Version 1.0 (current version - updated May 20, 2010)
|
One more improvement:
$scomdate = ($event.TimeGenerated).ToLocalTime();
$scomdate = $scomdate -replace("p.m","pm")
$scomdate = $scomdate -replace("a.m","am")
write-host $scomdate;
without this change above, all my times were not recognised and therefore they all got logged as AM.
EDIT: Scratch that - got it to work now - I edited the app file Splunketcappsscombinscom_client.ps1 and changed the following lines:
#write-host $alert.TimeRaised;
$scomdate = ($alert.TimeRaised).ToLocalTime();
write-host $scomdate;
and
#write-host $event.TimeGenerated;
$scomdate = ($event.TimeGenerated).ToLocalTime();
write-host $scomdate;
Turns out that Scom only talks in UTC - so altered the output as above and it works. Thanks for this great App - means we can now track if Scom dies easily (we had all it's subscriptions automatically disable themselves a few weeks ago (with no warning) due to a Domain Account issue).
Original message: Well - it works out the box - but seems to be using universal time stamps rather than the correct timezone. Something to do with the ps1 script?
I switched on debugging and this shows it well:
09/09/2011 11:53:27 DEBUG Get-Alert -criteria "TimeRaised > '09/09/2011 10:52:31'"
09/09/2011 11:53:57 DEBUG Get-Alert -criteria "TimeRaised > '09/09/2011 10:52:31'"
The TimeRaised is an hour before the log. Therefore the data is coming into Splunk an hour late (and Splunk believes that).
I know that using timezones with monitoring systems is silly but I'm still trying to get approval to change that. Meanwhile can anyone let me know how to get it to come into Splunk based on the TZ?
this is a good example of SCOM integration. With this integration you can make very quick dashboards and drill down into your SCOM data with ease.
Are you still working on the script? Would it be reasonable to poll SCOM for collected performance data?
