Collecting Windows OS Logs and Metrics

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 same Collector can also send metrics — see Metrics for Windows performance counters and the dedicated IIS and SQL Server receivers. 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.

Metrics

Bronto ingests OTLP metrics, so the same Collector can carry Windows metrics alongside the logs above.

Host and OS metrics

For CPU, memory, disk, filesystem, and network metrics, use the cross-platform hostmetrics receiver — it supports Windows as well as Linux and macOS. See Host metrics with OpenTelemetry for the scraper list and full configuration.

Windows performance counters

For counters that hostmetrics does not expose — .NET CLR, ASP.NET, Microsoft Exchange, or any custom application counter — use the windows_perf_counters receiver. You declare the metric to emit and the counters that feed it:

receivers:
  windows_perf_counters:
    collection_interval: 30s
    metrics:
      process.cpu.utilization:
        description: Percentage of processor time consumed by the process.
        unit: "%"
        gauge:
    perfcounters:
      - object: Process
        instances: ["*"]
        counters:
          - name: "% Processor Time"
            metric: process.cpu.utilization

The receiver type is windows_perf_counters. The older windowsperfcounters spelling is deprecated. The receiver is Windows-only and reads counters through the PDH interface, so a counter that is not installed on the host is skipped with a warning rather than failing startup.

IIS metrics

For IIS request rates, connections, queue depth, and uptime, use the dedicated iis receiver rather than hand-rolling counters. It reads the IIS performance counters for you:

receivers:
  iis:
    collection_interval: 30s

The iis receiver is Windows-only and is not available on Windows arm64.

SQL Server metrics

The sqlserver receiver works two ways. On Windows it can read the SQL Server performance counters with no connection details — the Collector must run as administrator to see them all:

receivers:
  sqlserver:
    collection_interval: 30s

Or connect directly to the instance, which also works when the Collector runs off-host (for example against Azure SQL):

receivers:
  sqlserver:
    collection_interval: 30s
    server: sqlserver.internal
    port: 1433
    username: <SQL_USERNAME>
    password: <SQL_PASSWORD>

Direct connection requires VIEW SERVER STATE on SQL Server before 2022, or VIEW SERVER PERFORMANCE STATE on 2022 and later. All four of server, port, username, and password must be set to enable this mode.

Bronto supports OTLP sums, gauges, summaries, and explicit histograms. Exponential histograms are not currently supported. For Sum, Summary, and Histogram metrics, the Metric Explorer provides per-second rate functions.

Wiring into the pipeline

Add the Windows receivers to the Collector’s pipelines 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]
    metrics:
      receivers: [otlp, hostmetrics, windows_perf_counters, iis, sqlserver]
      processors: [batch]
      exporters: [otlphttp/bronto]

Include only the receivers you configured — iis and sqlserver are relevant only on hosts running those workloads. If your Bronto exporter is signal-specific (for example otlphttp/brontologs and otlphttp/brontometrics), reference the matching exporter in each pipeline.

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 and Metrics

Windows Event Log

Filtering noisy channels

File-based logs

Metrics

Host and OS metrics

Windows performance counters

IIS metrics

SQL Server metrics

Wiring into the pipeline

Installing the Collector on Windows

​Windows Event Log

​Filtering noisy channels

​File-based logs

​Metrics

​Host and OS metrics

​Windows performance counters

​IIS metrics

​SQL Server metrics

​Wiring into the pipeline

​Installing the Collector on Windows

Windows Event Log

Filtering noisy channels

File-based logs

Metrics

Host and OS metrics

Windows performance counters

IIS metrics

SQL Server metrics

Wiring into the pipeline

Installing the Collector on Windows