If you have ever tried to create a Syslog collection rule in the SCOM Authoring Console, this is the module sequence that it creates this:
This technically works, but your SYSLOG events are not very searchable. The Logging Computer shows up as blank, the Event ID is always zero, and the Rendered Description is blank. The full data item is stored in the EventData column of the Event.vEventDetail view as XML. Searching XML in TSQL isn’t as easy as a character column, and sorting out duplicate events is made harder by the inclusion of the time stamp in the EventData column.
The solution is to include a System.Event.GenericDataMapper as a Condition Detection Module. This allows us to select how individual elements of the System.ApplicationLog.SysLogData item output by the Data Source Module are mapped into the System.EventData of the Write Action module
You may note that I almost always remove the Write Action from my collection rules that writes to the Operations Database. Here is the configuration that I used:
There is not an easy way to directly map the eight severity levels of a SYSLOG to the levels of a Windows event. So I just hard-coded a value of “2” for Warning. Since the severity is used for the event ID, that met my needs for easy searching. If you wanted to, you could create three separate collection rules and filter SYSLOG severities 0-3, 4-5, and 6-7 into three separate collection rules where you hard-code the event levels to Error, Warning, and Informational.