[NOTE - Operational Insights is now a part of Operations Management Suite. Learn more at microsoft.com/OMS ]
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 Type=Event 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:
- EventSource will be derived from the syslog Facility (not just the number but string representation/mapping defined in the script)
- EventLog is hardcoded to Syslog
- EventID is the numeric value for Facility
- EventLevelName (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).
The Data Source in the rule also has a configuration parameter 'MinSeverity' 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).
The Write Action in the rule tells the Management Server not to store this data in the onprem databases, but to send to OpInsights. Note - 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 .
<Rule ID="Microsoft.IntelligencePacks.LogManagement.Sample.Syslog.CollectSyslogs" Enabled="false" Target="SC!Microsoft.SystemCenter.HealthService" ConfirmDelivery="false" Remotable="true" Priority="Normal" DiscardLevel="100">
<Category>EventCollection</Category>
<DataSources>
<DataSource ID="CustomSyslogDS" TypeID="Microsoft.IntelligencePacks.LogManagement.Sample.Syslog.CustomSyslogDS">
<MinSeverity>5</MinSeverity> <!-- what is the minimum level to be accepted and sent up to OpInsights -->
</DataSource>
</DataSources>
<WriteActions>
<WriteAction ID="HttpWA" TypeID="IPTypes!Microsoft.SystemCenter.CollectCloudGenericEvent" />
</WriteActions>
</Rule>
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).
Note - 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.
The full XML file for this sample management pack can be downloaded from here .
Important - 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.