paint-brush
Collecting and Shipping Windows Events Logs with OpenTelemetryby@paulstefanski
1,063 reads
1,063 reads

Collecting and Shipping Windows Events Logs with OpenTelemetry

by Paul StefanskiMarch 14th, 2023
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow

Too Long; Didn't Read

The OpenTelemetry (OTel) Collector makes it much easier to monitor Windows Events with OpenTel. Windows Events logs record many different operating system processes, application activity, and account activity. We will be shipping Windows Event logs to a popular backend: Google Cloud Ops. Below are steps to get up and running quickly with the distribution.
featured image - Collecting and Shipping Windows Events Logs with OpenTelemetry
Paul Stefanski HackerNoon profile picture

If you use Windows, you will want to monitor Windows Events. The recent distribution of OpenTelemetry (OTel) Collector makes it much easier to monitor Windows Events with OpenTel. You can utilize this receiver either in conjunction with any OTel collector: including the OpenTelemetry Collector, but in this article we will be using observIQ’s distribution of the collector.


Below are steps to get up and running quickly with the distribution. We will be shipping Windows Event logs to a popular backend: Google Cloud Ops. You can find out more on the GitHub page.

What Signals Matter?

Windows Events logs record many different operating system processes, application activity, and account activity.


Some relevant log types you will want to monitor include:


  • Application Status
    • This contains information about applications installed or running on the system. If an application crashes, these logs may contain an explanation for the crash.


  • Security Logs
    • These logs contain information about the system’s audit and authentication processes. For example, if a user attempts to log into the system or use administrator privileges.


  • System Logs
    • These logs contain information about Windows-specific processes, such as driver activity. All of the above categories can be gathered with the Windows Events receiver – so let’s get started.

Before you Begin

If you don’t already have an OpenTelemetry collector built with the latest Windows Events receiver installed, you’ll need to do that first. The distribution of the OpenTelemetry Collector we’re using today includes the Windows Events receiver (and many others) and can be installed with the one-line installer here.

For Linux

To install using the installation script, you run:

sudo sh -c "$(curl -fsSlL https://github.com/observiq/observiq-otel-collector/releases/latest/download/install_unix.sh)" install_unix.sh

To install directly with the appropriate package manager, head to installing on Linux.

For Windows

To install the collector on Windows run the Powershell command below to install the MSI with no UI.

msiexec /i "https://github.com/observIQ/observiq-otel-collector/releases/latest/download/observiq-otel-collector.msi" /quiet


Alternatively, for an interactive installation download the latest MSI. After downloading the MSI, double-click the download to open the installation wizard and follow the instructions to configure and install the collector.


For more installation information see installing on Windows.

For macOS

To install using the installation script, you run:

sudo sh -c "$(curl -fsSlL https://github.com/observiq/observiq-otel-collector/releases/latest/download/install_macos.sh)" install_macos.sh


For more installation guidance, see installing on macOS.

For Kubernetes

To deploy the collector on Kubernetes, further documentation can be found at the observiq-otel-collector-k8s repository.

Configuring the Windows Events Receiver

Now the distribution is installed, let’s navigate to your OpenTelemetry configuration file.


If you’re using the observIQ Collector, you’ll find it at the following location: C:\Program Files\observIQ OpenTelemetry Collector\config.yaml (Windows)

Edit the configuration file to include the Windows Events receiver as shown below:

receivers:
    windowseventlog:
        channel: application


You can edit the specific output by adding/editing the following directly below the receiver name and channel:

{
    "channel": "Application",
    "computer": "computer name",
    "event_id":
    {
        "id": 10,
        "qualifiers": 0
    },
    "keywords": "[Classic]",
    "level": "Information",
    "message": "Test log",
    "opcode": "Info",
    "provider":
    {
        "event_source": "",
        "guid": "",
        "name": "otel"
    },
    "record_id": 12345,
    "system_time": "2022-04-15T15:28:08.898974100Z",
    "task": ""
}

Configuring the Log Fields

You can adjust the following fields in the configuration to adjust what types of logs you want to ship:

Field

Default

Description

channel

required

The windows event log channel to monitor

max_reads

100

On first startup, where to start reading logs from the API. Options are beginning or end

start_at

end

Number of client connections (excluding connections from replicas)

poll_interval

1s

The interval at which the channel is checked for new log entries. This check begins again after all new bodies have been read.

attributes

{}

A map of key: value pairs to add to the entry's attributes.

resource

{}

A map of key: value pairs to add to the entry's resource.

operators

[]

An array of operators. See below for more details

converter

{
max_flush_count: 100,
flush_interval: 100ms,
worker_count: max(1,runtime.NumCPU()/4)
}

A map of key: value pairs to configure the [entry.Entry][entry_link] to [pdata.LogRecord][pdata_logrecord_link] converter, more info can be found [here][converter_link]

Operators

Each operator performs a simple responsibility, such as parsing a timestamp or JSON. Chain together operators to process logs into the desired format.


  • Every operator has a type.
  • Every operator can be given a unique id. If you use the same type of operator more than once in a pipeline, you must specify an id. Otherwise, the id defaults to the value of type.
  • Operators will output to the next operator in the pipeline. The last operator in the pipeline will emit from the receiver. Optionally, the output parameter can be used to specify the id of another operator to which logs will be passed directly.
  • Only parsers and general-purpose operators should be used.


As you can see, this distribution makes it much simpler to work with OpenTelemetry collector— with a single-line installer, integrated receivers, exporter, and processor pool—and will help you implement OpenTelemetry standards wherever it is needed in your systems.



Also published here.

Lead image developed with stable diffusion.