WARNING: Version 5.0 of Winlogbeat has passed its EOL date.

This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.

« General Configuration Elasticsearch Output Configuration »
Elastic Docs ›Winlogbeat Reference [5.0] ›Configuring Winlogbeat ›Configuration Options (Reference)

Processors Configuration

edit

Processors Configuration

edit

You can define processors in your configuration to process events before they are sent to the configured output. The libbeat library provides processors for reducing the number of exported fields, and processors for enhancing events with additional metadata. Each processor receives an event, applies a defined action to the event, and returns the event. If you define a list of processors, they are executed in the order they are defined in the configuration file.

event -> processor 1 -> event1 -> processor 2 -> event2 ...

The processors are defined in the Winlogbeat configuration file.

Each processor has associated an action with a set of parameters and optionally a condition. If the condition is present, then the action is executed only if the condition is fulfilled. If no condition is passed then the action is always executed.

processors:
 - <action>:
     when:
        <condition>
     <parameters>
 - <action>:
     when:
        <condition>
     <parameters>
...

where <action> can be a way to select the fields that are exported or a way to add meta data to the event , <condition> contains the definition of the condition. and <parameters> is the list of parameters passed along the <action>.

See Filtering and Enhancing the Exported Data for specific Winlogbeat examples.

Condition

edit

Each condition receives a field to compare or multiple fields under the same condition and then AND is used between them. You can see a list of the exported fields.

For each field, you can specify a simple field name or a nested map, for example dns.question.name.

A condition can be:

equals

edit

With the equals condition, you can compare if a field has a certain value. The condition accepts only an integer or a string value.

For example, the following condition checks if the response code of the HTTP transaction is 200:

equals:
  http.response.code: 200

contains

edit

The contains condition checks if a value is part of a field. The field can be a string or an array of strings. The condition accepts only a string value.

For example, the following condition checks if an error is part of the transaction status:

contains:
  status: "Specific error"

regexp

edit

The regexp condition checks the field against a regular expression. The condition accepts only strings.

For example, the following condition checks if the process name starts with foo:

reqexp:
  system.process.name: "foo.*"

range

edit

The range condition checks if the field is in a certain range of values. The condition supports lt, lte, gt and gte. The condition accepts only integer or float values.

For example, the following condition checks for failed HTTP transaction by comparing the http.response.code field with 400.

range:
    http.response.code:
        gte: 400

that can be also translated to:

range:
    http.response.code.gte: 400

For example, the following condition checks if the CPU usage in percentage has a value between 0.5 and 0.8.

range:
    system.cpu.user.pct.gte: 0.5
    system.cpu.user.pct.lt: 0.8

OR

edit

The or operator receives a list of conditions.

or:
  - <condition1>
  - <condition2>
  - <condition3>
  ...

For example the condition http.response.code = 304 OR http.response.code = 404 translates to:

or:
  - equals:
      http.response.code: 304
  - equals:
      http.response.code: 404

AND

edit

The and operator receives a list of conditions.

and:
  - <condition1>
  - <condition2>
  - <condition3>
  ...

For example the condition http.response.code = 200 AND status = OK translates to:

and:
  - equals:
      http.response.code: 200
  - equals:
      status: OK

To configure a condition like <condition1> OR <condition2> AND <condition3>:

or:
 - <condition1>
 - and:
    - <condition2>
    - <condition3>

NOT

edit

The not operator receives the condition to negate.

not:
  <condition>

For example the condition NOT status = OK translates to:

not:
  equals:
    status: OK

Actions

edit

The supported filter actions are:

See Exported Fields for the full list of possible fields.

include_fields

edit

The include_fields action specifies what fields to export if a certain condition is fulfilled. The condition is optional and if it’s missing then the defined fields are always exported. The @timestamp and type fields are always exported, even if they are not defined in the include_fields list.

processors:
 - include_fields:
     when:
        condition
     fields: ["field1", "field2", ...]

You can specify multiple include_fields actions under the processors section.

If you define an empty list of fields under include_fields, then only the required fields, @timestamp and type, are exported.

drop_fields

edit

The drop_fields action specifies what fields to drop if a certain condition is fulfilled. The condition is optional and if it’s missing then the defined fields are always dropped. The @timestamp and type fields cannot be dropped, even if they show up in the drop_fields list.

processors:
 - drop_fields:
     when:
        condition
     fields: ["field1", "field2", ...]

If you define an empty list of fields under drop_fields, then no fields are dropped.

drop_event

edit

The drop_event action drops the entire event if the associated condition is fulfilled. The condition is mandatory, as without one all the events are dropped.

processors:
 - drop_event:
     when:
        condition
« General Configuration Elasticsearch Output Configuration »