Collecting Windows OS Logs

Windows hosts produce two distinct kinds of logs, and each needs a different OpenTelemetry receiver:

Windows Event Log — platform and service diagnostics written to the event log (visible in Event Viewer), collected with the windowseventlog receiver.
File-based logs — IIS access logs, SQL Server error logs, and custom application files on disk, collected with the filelog receiver.

The otel/opentelemetry-collector-contrib image and the Windows Collector binary include both receivers, so the same Collector you run for Linux workloads can collect Windows logs. Once the data reaches Bronto over OTLP it is ingested the same way regardless of the source OS. This applies to any Windows host you run a Collector on. On Azure that includes VMs and VM Scale Sets, App Service on Windows plans, and Windows node pools on AKS (where the Collector runs as a DaemonSet on the Windows nodes).

These examples show only the receivers and how to wire them into a logs pipeline. They assume you already run an OpenTelemetry Collector with a Bronto exporter configured — see OpenTelemetry on Azure or the OpenTelemetry Collector guide for the base setup, endpoints, and service.name / service.namespace routing.

The windowseventlog receiver is Windows-only — it must run on a Windows host or in a Windows container. The filelog receiver works on any OS.

Windows Event Log

Most Windows platform and service diagnostics are written to the Windows Event Log, not to files on disk. Collect these with the windowseventlog receiver, one receiver per channel:

receivers:
  windowseventlog/application:
    channel: Application
  windowseventlog/system:
    channel: System
  windowseventlog/security:
    channel: Security

channel accepts any event channel name, so you can scope collection to exactly the sources you care about. Channels commonly worth collecting on Windows hosts:

Channel	Captures
`Application`	Events from installed applications and services
`System`	Events from Windows system components and drivers
`Security`	Audit events — logon, privilege use, object access (high volume)
`Setup`	Application install and servicing events
`ForwardedEvents`	Events collected from other hosts via Windows Event Forwarding (WEF)
`Microsoft-Windows-PowerShell/Operational`	PowerShell script-block and pipeline execution
`Microsoft-Windows-Sysmon/Operational`	Sysmon process / network / file telemetry (if Sysmon is installed)
`Microsoft-Windows-Windows Defender/Operational`	Microsoft Defender detections and scan results

On domain controllers, also collect the Directory Service and DNS Server channels alongside Security for Active Directory audit events.

Filtering noisy channels

High-volume channels — Security in particular — can dominate ingestion. Use the receiver’s query option to collect only the events you need via an XPath expression, keeping volume and cost down before data leaves the host. Filter Security by Event ID:

receivers:
  windowseventlog/security:
    channel: Security
    query: |
      <QueryList>
        <Query Id="0" Path="Security">
          <Select Path="Security">*[System[(EventID=4624 or EventID=4625 or EventID=4672)]]</Select>
        </Query>
      </QueryList>

(4624 successful logon, 4625 failed logon, 4672 special privileges assigned.) For Application and System, filtering by severity is often more useful — *[System[(Level=1 or Level=2 or Level=3)]] keeps only Critical, Error, and Warning events.

File-based logs

Logs written to disk — IIS access logs, SQL Server error logs, custom application log files — are collected with the standard filelog receiver. On Windows, write include paths with forward slashes (or escaped backslashes):

receivers:
  filelog/app:
    include:
      - C:/logs/*.log
    # Some Windows apps and PowerShell transcripts write UTF-16, not UTF-8
    encoding: utf-16le
    # Keep multi-line .NET exception stack traces together as one event
    multiline:
      line_start_pattern: '^\d{4}-\d{2}-\d{2}'
  filelog/iis:
    include:
      - C:/inetpub/logs/LogFiles/W3SVC*/*.log       # IIS access logs (W3C)
      - C:/Windows/System32/LogFiles/HTTPERR/*.log  # HTTP.sys connection errors
  filelog/sqlserver:
    include:
      - C:/Program Files/Microsoft SQL Server/MSSQL*/MSSQL/Log/ERRORLOG*

Two Windows-specific points to watch:

Encoding — IIS logs are UTF-8, but many Windows tools (PowerShell transcripts, some application logs) write UTF-16. Set encoding: utf-16le on those receivers or the text will be garbled.
Multi-line events — .NET exception stack traces span many lines. Without a multiline.line_start_pattern, each line is ingested as a separate event; the pattern above keeps a full stack trace as a single record.

IIS writes access logs in W3C extended log format (space-delimited fields with a #Fields: header). Pair the filelog receiver with a parsing operator or the transform processor if you want those fields broken out into structured attributes — or ship the raw lines and use the Bronto Custom Parser, which has built-in IIS support.

The filelog receiver only reads files on disk — it will not pick up Windows Event Log entries. If logs you expect are missing, confirm whether they are written to a file or to the Event Log (Event Viewer): the former needs filelog, the latter needs windowseventlog. Pointing filelog at logs that actually live in the Event Log is the most common cause of missing Windows logs.

Wiring into the pipeline

Add the Windows receivers to the Collector’s logs pipeline alongside your existing sources, exporting to your configured Bronto exporter:

service:
  pipelines:
    logs:
      receivers: [otlp, windowseventlog/application, windowseventlog/system, filelog/iis]
      processors: [batch]
      exporters: [otlphttp/bronto]

Installing the Collector on Windows

Install the Collector from the opentelemetry-collector-contrib Windows MSI — which registers it as a Windows service automatically — or from the zip release. With the zip, register the service yourself so it starts on boot:

New-Service -Name otelcol-contrib `
  -BinaryPathName '"C:\Program Files\otelcol-contrib\otelcol-contrib.exe" --config "C:\otel\config.yaml"' `
  -StartupType Automatic
Start-Service otelcol-contrib

For VM Scale Sets, install and register the service through a custom-script extension or in your image build so every instance starts the Collector on boot.

For assistance or questions, contact support@bronto.io.

Overview

Ingest with agents

Ingest from AWS

Ingest from Azure

Ingest from CDN and edge

Ingest from apps and platforms

Ingest from infrastructure and databases

Ingest OpenTelemetry data

Collecting Windows OS Logs

Windows Event Log

Filtering noisy channels

File-based logs

Wiring into the pipeline

Installing the Collector on Windows

​Windows Event Log

​Filtering noisy channels

​File-based logs

​Wiring into the pipeline

​Installing the Collector on Windows

Windows Event Log

Filtering noisy channels

File-based logs

Wiring into the pipeline

Installing the Collector on Windows