> ## Documentation Index
> Fetch the complete documentation index at: https://docs.bronto.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Collecting Windows OS Logs

> Collect Windows Event Log channels and file-based logs (IIS, SQL Server) from Windows hosts and ship them to Bronto with the OpenTelemetry Collector.

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).

<Note>
  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](./azure-otel) or the [OpenTelemetry Collector guide](/agent-setup/open-telemetry) for the base setup, endpoints, and `service.name` / `service.namespace` routing.
</Note>

<Info>
  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.
</Info>

## 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](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/windowseventlogreceiver), one receiver per channel:

```yaml theme={"dark"}
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:

```yaml theme={"dark"}
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):

```yaml theme={"dark"}
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](/core-features/custom-parser), which has built-in IIS support.

<Warning>
  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.
</Warning>

## Wiring into the pipeline

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

```yaml theme={"dark"}
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:

```powershell theme={"dark"}
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](mailto:support@bronto.io).