WARNING: Version 5.0 of Metricbeat 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.
Processors Configuration
editProcessors Configuration
editYou 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 Metricbeat 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 Metricbeat examples.
Condition
editEach 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
editWith 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
editThe 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
editThe 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
editThe 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
editThe 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
editThe 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
editThe not
operator receives the condition to negate.
not: <condition>
For example the condition NOT status = OK
translates to:
not: equals: status: OK
Actions
editThe supported filter actions are:
See Exported Fields for the full list of possible fields.
include_fields
editThe 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
editThe 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
editThe 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