Windows event logs are important for security, troubleshooting, and compliance. When you analyze your logs, you can monitor and report on file access, network connections, unauthorized activity, error messages, and unusual network and system behavior.
However, Windows servers produce tens of thousands of log entries every day. The sheer volume of data is almost impossible to go through manually—and a significant majority of these entries will simply be showing successful, problem-free interactions and transactions.
For Windows systems, there are three default types of event logs:
Beyond the initial 3 categories, there are typically additional Windows Event Log channels as you can see in this screenshot from a Windows 10 system.
The cool thing about Windows Event Logs is it is a treasure trove of data that can be used to detect issues with the Windows environment as well as provide an indication of potential problems. You just need to know what to look for. Windows Event Logs provide a blueprint of current conditions for the Windows systems. Applications and the built-in Windows Services use these event logs to record important hardware and software actions that the administrator can use to troubleshoot issues. The Windows operating system tracks specific events in its log files, such as application installations, system logins, network resource access, or errors.
Here are some examples of data typically available via Windows Event Logs.
|Event in a log entry||Definitions|
|Logged||The time the event occurred.|
|User||The username (actual or service user) associated with the event.|
|Computer||The name of the computer associated with the event. These may be the remote computer on your network accessing local resources.|
|Event ID||A Windows identification number that specifies the event type. This can be used to look up details on the event|
|Level||Severity of the event. These can range from Informational to Critical|
|Source||The program or component that caused the event.|
Windows Events can be viewed in Windows Event Viewer, which is built into every Windows installation (except for Windows Server Core). While Event Viewer is useful for viewing the local logs, it can also be used to connect to other Windows systems across your domain.
Generally, it is a good tool for troubleshooting single issues, but not ideal for looking at events from across your environment.
No, the Windows Event Log is set to overwrite old entries at a maximum of 16mb for each category. You don’t have to worry about the event’s data filling up too much storage.
This is configurable via the properties in the Event Viewer for the individual log.
In observIQ, you can add a Source to a deployed agent that will collect logs from the machine the agent is deployed on. Configuration information collected include the following as represented in the table below:
|System Events||Toggle check box to enable/disable collection of System Event logs.|
|Application Events||Toggle check box to enable/disable collection of Application Event logs.|
|Security Events||Toggle check box to enable/disable collection of Security Event logs.|
|Max Reads||Use this field to set the maximum number of records read into memory before beginning a new batch. The default is ‘100’.|
|Poll Interval||Use this field to set the interval at which the channel is checked for new log entries. This check begins after all new records have been read. The default is ‘1’.|
|Start At||Choose whether to start reading from the beginning or end of a file with “end” being the default.|
Assuming you already have an observIQ Log Agent deployed on a Windows machine (and we’d be remiss not to mention our log agent, Stanza, is the official log agent of the OpenTelemetry project), a first step will be to add the Windows Event Log source to the agent you want to use to collect Windows Event Logs with.
You are given the opportunity to collect system, application, and security logs. You also can also define your own list of additional Event channels. If questions about which category of logs you wish to collect, each option includes a summary description of the logs collected. You can elect to collect all categories of logs as well.
If you want to collect logs in a custom format and potentially attach custom metadata, the source configuration dialogue box provides an advanced option to invoke that.
Once configured you now will have logs flowing in the Kibana log visualization element of observIQ Cloud.