This page is not yet available in Spanish. We are working on its translation. If you have any questions or feedback about our current translation project, feel free to reach out to us!
Overview
This integration watches for Windows Event Logs and forwards them to Datadog.
Enable this integration to:
Track system and application events in Datadog.
Correlate system and application events with the rest of your application.
The value under the column LogName is the name of the channel. In the example above, the channel name is Security.
Windows Event Viewer
To find the channel name for an Event Log in the Windows Event Viewer, open the Event Log Properties window and refer to the Full Name field. In the following example, the channel name is Microsoft-Windows-Windows Defender/Operational.
Log collection
Available for Agent versions 6.0 or later
Log collection is disabled by default in the Datadog Agent. To collect Windows Event Logs as Datadog logs, activate log collection by setting logs_enabled: true in your datadog.yaml file.
To collect Windows Event Logs as Datadog logs, configure channels under the logs: section of your win32_event_log.d/conf.yaml configuration file. This example shows entries for the Security and <CHANNEL_2> channels:
Event collection using the Event Log API (Recommended)
The Datadog Agent can be configured to collect Windows Event Logs as Datadog events using the Event Log API. Datadog recommends using the Event Log API because it has better performance than the legacy method below. Note, each method has its own configuration syntax for channels and for filters. For more information, see Filtering Events.
To collect Windows Event Logs as Datadog events, configure channels under the instances: section of your win32_event_log.d/conf.yaml configuration file.
Set legacy_mode: false in each instance. If legacy_mode: false is set, the path is required to be set in the \win32_event_log.d\conf.yaml file.
This example shows entries for the Security and <CHANNEL_2> channels:
init_config:instances:- # Event Log API path:Securitylegacy_mode:falsefilters:{}- path:"<CHANNEL_2>"legacy_mode:falsefilters:{}
Agent versions 7.49 and later support setting legacy_mode in the shared init_config section. This sets the default for all instances and no longer requires you to set legacy_mode individually for each instance. However, the option can still be set on a per-instance basis.
The legacy method uses WMI (Windows Management Instrumentation) and was deprecated in Agent version 7.20.
To collect Windows Event Logs as Datadog events, configure channels under the instances: section of your win32_event_log.d/conf.yaml configuration file.
To use Legacy Mode, set legacy_mode to true. Then, set at least one of the following filters: source_name, event_id, message_filters, log_file, or type.
This example shows entries for the Security and <CHANNEL_2> channels:
Note: For the Security logs channel, add your Datadog Agent user to the Event Log Readers user group.
Filtering events
Configure one or more filters for the event log. A filter allows you to choose what log events you want to get into Datadog.
You can use the query, as well as the log_processing_rules regex option, to filter event logs. Datadog recommends using the query option which is faster at high rates of Windows Event Log generation and requires less CPU and memory than the log_processing_rules filters. When using the log_processing_rules filters, the Agent is forced to process and format each event, even if it will be excluded by log_processing_rules regex. With the query option, these events are not reported to the Agent.
You can use the query option to filter events with an XPATH or structured XML query. The query option can reduce the number of events that are processed by log_processing_rules and improve performance. There is an expression limit on the syntax of XPath and XML queries. For additional filtering, use log_processing_rules filters.
Datadog recommends creating and testing the query in Event Viewer’s filter editor until the events shown in Event Viewer match what you want the Agent to collect.
Then, copy and paste the query into the Agent configuration.
# collect Critical, Warning, and Error events- type:windows_eventchannel_path:Applicationsource:windows.eventsservice:Windows query:'*[System[(Level=1 or Level=2 or Level=3)]]'- type:windows_eventchannel_path:Applicationsource:windows.eventsservice:Windows query:| <QueryList>
<Query Id="0" Path="Application">
<Select Path="Application">*[System[(Level=1 or Level=2 or Level=3)]]</Select>
</Query>
</QueryList>
In addition to the query option, events can be further filtered with log processing rules.
Legacy Provider EventIDs have a Qualifiers attribute that changes the format of the log, as seen in the Windows Event Schema. These events have the following XML format, visible in Windows Event Viewer:
<EventIDQualifiers="16384">3</EventID>
The following regex must be used to match these EventIDs:
Agent versions 7.41 or later normalize the EventID field. This removes the need for the substring, (?:{"value":)?, from legacy pattern as it is no longer applicable. A shorter regex pattern can be used from versions 7.41 or later as seen below:
The values listed in the output of the command can be set in win32_event_log.d/conf.yaml to capture the same kind of events.
The information given by the Get-EventLog PowerShell command or the Windows Event ViewerGUI may slightly differ from Get-WmiObject. Double check your filters' values with Get-WmiObject if the integration does not capture the events you set up.
Filtering events using the Event Log API (Recommended)
The configuration option using the Event Log API includes the following filters:
instances:- legacy_mode:falsepath:Systemfilters:source:- Microsoft-Windows-Ntfs- Service Control Managertype:- Error- Warning- Information- Success Audit- Failure Auditid:- 7036
You can use the query option to filter events with an XPATH or structured XML query. Datadog recommends creating the query in Event Viewer’s filter editor until the events shown in Event Viewer match what you want the Datadog Agent to collect. The filters option is ignored when the query option is used.
init_config:instances:# collect Critical, Warning, and Error events- path:Applicationlegacy_mode:falsequery:'*[System[(Level=1 or Level=2 or Level=3)]]'- path:Applicationlegacy_mode:falsequery:| <QueryList>
<Query Id="0" Path="Application">
<Select Path="Application">*[System[(Level=1 or Level=2 or Level=3)]]</Select>
</Query>
</QueryList>
Filtering events using Legacy Mode (Deprecated)
The configuration option using the Legacy Mode includes the following filters:
instances:# Legacy# The following captures errors and warnings from SQL Server which# puts all events under the MSSQLSERVER source and tag them with #sqlserver.- tags:- sqlservertype:- Warning- Errorlog_file:- Applicationsource_name:- MSSQLSERVER# This instance captures all system errors and tags them with #system.- tags:- systemtype:- Errorlog_file:- System
The legacy method does not support the query option. Only the Event Log API method (setting legacy_mode: false) and the Logs Tailer supports the query option.
When you’re done setting up filters, restart the Agent using the Agent Manager, or restart the service.
Validation
Check the information page in the Datadog Agent Manager or run the Agent’s status subcommand and look for win32_event_log under the Logs Agent section.
It should display a section similar to the following:
Logs Agent==========[...] win32_event_log
---------------
- Type: windows_event
ChannelPath: System
Status: OK
Check the information page in the Datadog Agent Manager or run the Agent’s status subcommand and look for win32_event_log under the Checks section.
It should display a section similar to the following:
Starting with Agent 7.54, you can automatically send Security Events to Datadog as logs by using the dd_security_events flag. These logs can be used with Datadog’s Cloud SIEM to automatically detect threats and suspicious activity in real-time. These default security events are compatible with Datadog’s out-of-the-box Windows detection rules to create security signals when a user clears the Security logs, disables the Windows firewall, changes the Directory Services Restore Mode (DSRM) password, and more.
Enable collecting logs in your datadog.yaml file. It is disabled by default in the Datadog Agent.
logs_enabled:true
In the integration configuration file, (win32_event_log.d/conf.yaml) set the dd_security_events flag to low or high to start sending Security Events to Datadog.
low: sends only the most important and critical Security events, including Audit log cleared (1102), Replay attack detected (4649), and System audit policy was changed (4719). For a full list of events collected on the low setting, see here.
high: sends a higher volume of Security events, including Encrypted data recovery policy was changed (4714), Domain policy was changed (4739), and Security-disabled group was deleted (4764). For a full list of events collected on the high setting, see here.
Teams can change which event IDs are associated with low or high settings by editing these profiles.
If you are using log processing rules to filter out logs, verify that the raw logs match the regular expression (regex) pattern you configured. In the configuration below, log levels must be either warning or error. Any other value is excluded.
Remove or comment out the log_processing_rules stanza.
Restart the Agent.
Send a test log that includes the values you’re attempting to catch. If the log appears in Datadog, there is probably an issue with your regex. Compare your regex against the log file to make sure you’re capturing the right phrases.
Further Reading
Additional helpful documentation, links, and articles:
