[NOTE - Operational Insights is now a part of Operations Management Suite. Learn more at
We provide an example below that uses the Native Syslog Data Source in SCOM and combines it with a Powershell module that allows do parse out additional information out of the syslog event and place them in 'similar' fields in the
shape that was originally designed for Windows Events.
We decided some mapping in the sample as a starting point, but you can edit the script and change them as you like. You might need some Management Pack authoring skills if you want to customize this some more. We can't post the full XML in this page as it will be too verbose, but the full file is linked/can be downloaded at the end of the post. If you need to make tweaks, most of the logic is in the Powershell script, and there are a lot of comments in there. There are also similar examples of using syslog in SCOM out there on many blogs and communities.
In this sample implementation we mapped the following fields:
will be derived from the syslog Facility (not just the number but string representation/mapping defined in the script)
is hardcoded to
is the numeric value for
(severity into/warning/error) is calculated in the script mapping the many syslog severities in 'buckets'
Here's how our sample data looks like once in OpInsights search:
The MP contains a rule which uses this composite module as data source, and it then uses our HTTP write action to post to Advisor service like the 'Log Management' intelligence pack would do (this also means this traffic will count towards 'Log Management' in the 'Usage' chart in the Portal).
in the rule also has a configuration parameter
that can be used to determine the lowest severity level to accept. It defaults to 5 (which means severities 0-5 will be accepted, but not those >5).
in the rule tells the Management Server not to store this data in the onprem databases, but to send to OpInsights.
- If you want to learn more about the write action that allows sending events to Operational Insights, also read
this other blog post
. And if you want to learn more about collecting and mapping Syslog messages in Operations Manager (without employing a script), refer to
this great post by Michael
The rule will run (governed by an override, also in the MP) on the Management Servers.
You will still need to configure your syslog-enabled devices to send to the MS (how to do this varies on OS's and Devices types).
- if you are already using syslog receiving on your MS's, you might need to change the override and/or re-target this rule, as there can only be one instance of the syslog module listening on the syslog port (UDP 514) at any given time, and multiple rules using that module in OM will conflict with each other and fail to load. You know your existing rule set.
- If you notice that the script is too heavy – there’s a potential of losing events if too many events are passed thru a powershell module –
I posted an alternative implementation on GitHub
which only uses the native SCOM data mapper, which is a lot more faster and reliable, but only allows limited reshaping/mapping.
We recommend you do your own testing first in a pre-production or QA environment, and use at your discretion. Samples are provided "AS IS" without warranty of any kind, either expressed or implied, including but not limited to the implied warranties of merchantability and/or fitness for a particular purpose.