Skip to main content

Monitoring the Windows Event Log

Every Windows host the agent runs on gets two definitions the moment it registers. One counts errors, warnings and events per channel over the last hour; the other ships the entries themselves as log lines, ready for search and for the incidents that reference them. Both talk to the Windows Event Log API directly. No PowerShell, no forwarding subscription, nothing to set up in Event Viewer.

How the Event Log is recognised​

The windows-eventlog and logs-windows definitions match the Dhcp service unit (the DHCP Client, present on every Windows installation), which makes them a match for any Windows host rather than for one product. Both run every minute and read the System and Application channels through the native event log API, read-only.

What is collected​

Counts per channel, over the last hour. Errors (event level critical and error), warnings (level warning), and all events regardless of level. The window slides, so a burst stays visible in the count for an hour and then falls out.

The latest errors. When a channel has errors in the window, the three most recent are kept as a fact (lastErrors.System, lastErrors.Application): provider, event ID, time and the first 240 characters of the message. The count tells you how many, the fact tells you what.

SignalMetric
Errors in the last hoursvc.windows.errors tagged by channel
Warnings in the last hoursvc.windows.warnings tagged by channel
All events in the last hoursvc.windows.events tagged by channel

Names, tags and units are in the metrics reference.

Logs. The logs-windows definition ships the entries of System and Application as lines of the form Provider#EventID: message, each carrying the event's own timestamp. The event level becomes the line level: critical and error events are errors, warning events are warnings, information is info and verbose is debug. Only notice and above ships by default, so errors and warnings flow and informational entries stay on the host until you switch the service to full depth in the console. The first read only marks the current position; no backlog is shipped. Message text comes from the provider's own message resources, and when those are missing on the host the raw event data fields are shipped instead. The Hyper-V channels ride the same mechanism through the Hyper-V definition, see Monitoring Hyper-V. Redaction, level filtering and the volume caps are described on Logs.

Alerts out of the box​

There is no rule dedicated to the Event Log counters. The shipped error lines do count toward the generic "service floods error logs" rule, which opens a warning when one service ships 50 or more error lines in 15 minutes and arms itself as soon as lines flow. Any metric above can drive a custom rule in the console; svc.windows.errors with the tag channel opens one incident per channel. The generic rule is listed in the rules catalog.

Limitations​

  • Only the System and Application channels are read. Security, Setup and application-specific channels are not; the Hyper-V channels come with the Hyper-V definition.
  • The counts describe a one-hour window sampled every minute, so they measure recent history, not the rate at this second.
  • Counting stops at 20,000 events per channel and query; a channel busier than that in an hour reads as 20,000.
  • Line shipping takes the newest 300 entries per channel per cycle. A burst larger than that within a minute is trimmed to the newest 300.
  • Event messages are as good as the provider's message resources on the host. A provider whose resources are missing ships its raw data fields, which is exactly what Event Viewer shows in that case.