Sending Windows Event Logs

Last updated on 13 June, 2023

Although Windows Event Logs can be collected using agents such as Fluentd or using Windows Event Forwarding, the process may be cumbersome. The most convenient way to configure Windows Event Logs for ingestion is to use LogSource. Alternatively, you can enable logs using a DataSource. 

Recommendation: LogSource is the recommended method to enable LM Logs, and there is a LogSource for Windows Event Logs. However, for the time being the recommended method for enabling LM Logs for Windows Events is the method described in the following.

Requirements

  • LogicMonitor API tokens to authenticate all requests to the log ingestion API.
  • Minimum permissions for the API key to ingest logs is “Manage”. For more information, see Roles.
  • The Windows_Events_LMLogs DataSource. This is available as a LogicModule in your LogicMonitor portal. Navigate to Modules and search for the Windows_Events_LMLogs DataSource. To add the DataSource to your repository, see Module Installation.
  • 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

The Windows_Events_LMLogs DataSource retrieves the logs using Windows Management Instrumentation (WMI) and pushes them to LM Logs.

To enable the Windows_Events_LMLogs DataSource, configure the properties described in the following.

PropertyDescription
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 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.

PropertyDescription
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.

Viewing 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_LMLogs.

When viewing 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. For more information, see this Microsoft documentation.

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 events from this log file are not available. You need to add these events into the WMI class in Windows Registry.

In This Article