Ingesting Windows Event Logs

Although Windows Event Logs can be collected using agents such as Fluentd or using Windows Event Forwarding, the process may be cumbersome. To simplify Windows Event Logs ingestion, we provide a DataSource which retrieves the logs using Windows Management Instrumentation (WMI) and then pushes them to LM Logs.

The Windows Events LM Logs DataSource is available in LM Exchange. This topic will discuss how to apply the Windows Events LM Logs DataSource, how it works, and what filtering options are available.

You can also configure the LM Collector to send collect and forward Windows Event Logs to LogicMonitor. See Collecting and Forwarding Windows Event Logs.

Prerequisites

• LogicMonitor API tokens to authenticate all requests to the log ingestion API.
• Log names for the log files you want to send to LogicMonitor. Certain event logs may not be available to LogicMonitor, and you will need to create them in Windows Registry.

Enable the Windows Events DataSource

In LM Exchange, search for the Windows Events LM Logs DataSource. It should be located under the “Community” section. Import the DataSource to your repository following the steps outlined in the LM Exchange article under Importing New LogicModules. 

To enable the DataSource, configure the following properties:

Note: The name of the Channel can be found in the Windows Event Viewer for the log file, under its Properties > Full Name. If the log file is in a subdirectory, the full name should include the path to the subdirectory. For example, if the log file is in OpenSSH/Operational, include the forward slash in the Channel name.

Filter Windows Events

Use the following properties to filter the Windows Events that you want to send to LM Logs.

Reviewing Logs and Alerts

Once the properties are applied for the DataSource, the Windows Events for each of the specified Channels are pushed to LM Logs. You can navigate to Resources and see the Channels listed as discovered instances under Windows Events LM Logs.

When reviewing the graphs for the instances, the LM Logs API response codes will only return data on the instance that corresponds to the first channel listed in the device property.

• This ensures that response codes trigger a single alert, rather than one for each datasource instance.
• This happens because the DataSource makes one API request for all the instances together, not individually.

The DataSource will is configured to trigger a Warning alert if the Response Code is greater than 207.

Event Limits and Batching

The DataSource pulls for events every 60 seconds. If the WMI request returns more than 5000 events, the DataSource will send the events to LM Logs in batches of 5000 events.

Note: Batching the events should not alter the timestamps of the events when they are received. The timestamps viewed in LM Logs will be the Windows Event Timestamp.

Retrieve Application Events via WMI

Not all Windows Events are retrievable via WMI.  Since the LM Logs module for Windows Events relies on the Win32_NTLogEvent call to pull events, any logs that are not retrievable via this class will not show up in LM Logs.

You can confirm whether the log file can be accessed through the Win32_NTLogEvent by running the following query via Powershell on the Windows device you want to monitor:

Get-WmiObject -Query "Select TimeGenerated,Message,Logfile from Win32_NTLogEvent WHERE ( LogFile = '<LogFileName>' )" | select -First 1

If no events are returned, this means that the events from this log file are not available and you will need to add the events into the WMI class in Windows Registry.