Ingesting Windows Event Logs
Last updated on 26 January, 2023Although 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, you can use a DataSource.. This retrieves the logs using Windows Management Instrumentation (WMI) and pushes them to LM Logs.
The Windows_Events_LM_Logs_v2 DataSource is available in LM Exchange. The following describes how to apply Windows_Events_LM_Logs_v2, how it works, and available filtering options.
Prerequisites
- LogicMonitor API tokens to authenticate all requests to the log ingestion API.
- Minimum permissions for the API key to ingest logs is “Manage”. See Roles.
- 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.
Enabling Windows Events DataSource
In your LM portal, navigate to Modules and select Exchange in the upper right corner. In LM Exchange, search for the Windows_Events_LM_Logs_v2 DataSource under Community and filter on DataSource. Import the DataSource to your repository following the steps outlined in Importing New LogicModules.
Note: For more information about support limitations for community modules, see LM Exchange.
To enable the DataSource, configure the following properties:
| Property | Description |
lmaccess.id | (Required) LogicMonitor logs ingestion API access ID. |
lmaccess.key | (Required) LogicMonitor logs ingestion API access key. |
lmlogs.winevent.channels | (Required) The list of log files that you want to send to LM Logs. |
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.
Filtering Windows Events
Use the following properties to filter the Windows Events that you want to send to LM Logs.
| Property | Description |
lmlogs.winevent.eventTypes | (Optional) Send only logs that match the specified comma-separated list of event types (levels). Level values may be: Error, Warning, Information, Security Audit Success, and Security Audit Failure. If you don’t include this property, all log levels will be allowed. |
lmlogs.winevent.eventids.exclude | (Optional) Define a comma-separated list of the specific Event ID’s that you don’t want to send. |
lmlogs.winevent.message_strings.exclude | (Optional) Specify a comma-separated list of strings to exclude any Windows Events whose message contains a string in the list. |
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. Navigate to Resources to see the Channels listed as discovered instances under Windows_Events_LM_Logs_v2.
When reviewing the graphs for the instances, the LM Logs API response codes will only return data on the instance corresponding 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 is because the DataSource makes one API request for all instances together instead of 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.
Retrieving 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, 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 1If no events are returned, this means that events from this log file are not available. You need to add these events into the WMI class in Windows Registry.