IMPORTANT: No additional bug fixes or documentation updates will be released for this version. For the latest information, see the current release documentation.
« de_dot dns »
Elastic Docs ›Logstash Reference [5.0] ›Filter plugins

dissect

edit

dissect

edit

This plugin does not ship with Logstash by default, but it is easy to install by running bin/logstash-plugin install logstash-filter-dissect.

The Dissect filter can be used to extract fields from unstructured data. Dissect is different from the Grok filter.

Dissect does not use regexes and it is not designed to be a Grok replacement, but rather an alternative approach for certain types of data. Dissect can also be complementary to Grok — you can use Dissect as a pre-step before sending the remaining unstructured blob to a Grok filter. The Dissect filter is a kind of split operation. Unlike a regular split operation where one delimiter is applied to the whole string, this operation applies a set of delimiters # to a string value.

However, if the structure of your text varies from line to line then Grok is more suitable. There is a hybrid case where Dissect can be used to de-structure the section of the line that is reliably repeated and then Grok can be used on the remaining field values with # more regex predictability and less overall work to do.

A set of fields and delimiters is called a dissection.

The dissection is described using a set of %{} sections:

%{a} - %{b} - %{c}

A field is the text from % to } inclusive.

A delimiter is the text between } and % characters.

delimiters can’t contain these }{% characters.

The config might look like this:

  filter {
    dissect {
      mapping => {
        "message" => "%{ts} %{+ts} %{+ts} %{src} %{} %{prog}[%{pid}]: %{msg}"
      }
    }
  }

When dissecting a string from left to right, text is captured upto the first delimiter - this captured text is stored in the first field. This is repeated for each field/# delimiter pair thereafter until the last delimiter is reached, then the remaining text is stored in the last field.

The Key: The key is the text between the %{ and }, exclusive of the ?, +, & prefixes and the ordinal suffix.

%{?aaa} - key is aaa
%{+bbb/3} - key is bbb
%{&ccc} - key is ccc

Normal field notation:
The found value is added to the Event using the key.
%{some_field} - a normal field has no prefix or suffix

Skip field notation:
The found value is stored internally but not added to the Event.
The key, if supplied, is prefixed with a ?.

%{} is an empty skip field.

%{?foo} is a named skip field.

Append field notation:
The value is appended to another value or stored if its the first field seen.
The key is prefixed with a +.
The final value is stored in the Event using the key.

The delimiter found before the field is appended with the value.
If no delimiter is found before the field, a single space character is used.

%{+some_field} is an append field.
%{+some_field/2} is an append field with an order modifier.

An order modifier, /digits, allows one to reorder the append sequence.
e.g. for a text of 1 2 3 go, this %{+a/2} %{+a/1} %{+a/4} %{+a/3} will build a key/value of a => 2 1 go 3
Append fields without an order modifier will append in declared order.
e.g. for a text of 1 2 3 go, this %{a} %{b} %{+a} will build two key/values of a => 1 3 go, b => 2

Indirect field notation:
The found value is added to the Event using the found value of another field as the key.
The key is prefixed with a &.
%{&some_field} - an indirect field where the key is indirectly sourced from the value of some_field.
e.g. for a text of error: some_error, some_description, this error: %{?err}, %{&err} will build a key/value of some_error => description.

for append and indirect field the key can refer to a field that already exists in the event before dissection.

use a Skip field if you do not want the indirection key/value stored.

e.g. for a text of google: 77.98, this %{?a}: %{&a} will build a key/value of google => 77.98.

append and indirect cannot be combined and will fail validation.
%{+&something} - will add a value to the &something key, probably not the intended outcome.
%{&+something} will add a value to the +something key, again probably unintended.

Delimiter repetition:
In the source text if a field has variable width padded with delimiters, the padding will be ignored.
e.g. for texts of:

00000043 ViewReceiver  I
000000b3 Peer          I

with a dissection of %{a} %{b} %{c}; the padding is ignored, event.get([c]) -> "I"

You probably want to use this filter inside an if block.
This ensures that the event contains a field value with a suitable structure for the dissection.

For example:

filter {
  if [type] == "syslog" or "syslog" in [tags] {
    dissect {
      mapping => {
        "message" => "%{ts} %{+ts} %{+ts} %{src} %{} %{prog}[%{pid}]: %{msg}"
      }
    }
  }
}

 

Synopsis

edit

This plugin supports the following configuration options:

Required configuration options:

dissect {
}

Available configuration options:

Setting Input type Required Default value

add_field

hash

No

{}

add_tag

array

No

[]

convert_datatype

hash

No

{}

enable_metric

boolean

No

true

id

string

No

mapping

hash

No

{}

periodic_flush

boolean

No

false

remove_field

array

No

[]

remove_tag

array

No

[]

tag_on_failure

array

No

["_dissectfailure"]

Details

edit

 

add_field

edit
  • Value type is hash
  • Default value is {}

If this filter is successful, add any arbitrary fields to this event. Field names can be dynamic and include parts of the event using the %{field}.

Example:

    filter {
      dissect {
        add_field => { "foo_%{somefield}" => "Hello world, from %{host}" }
      }
    }
[source,ruby]
    # You can also add multiple fields at once:
    filter {
      dissect {
        add_field => {
          "foo_%{somefield}" => "Hello world, from %{host}"
          "new_field" => "new_static_value"
        }
      }
    }

If the event has field "somefield" == "hello" this filter, on success, would add field foo_hello if it is present, with the value above and the %{host} piece replaced with that value from the event. The second example would also add a hardcoded field.

add_tag

edit
  • Value type is array
  • Default value is []

If this filter is successful, add arbitrary tags to the event. Tags can be dynamic and include parts of the event using the %{field} syntax.

Example:

    filter {
      dissect {
        add_tag => [ "foo_%{somefield}" ]
      }
    }
[source,ruby]
    # You can also add multiple tags at once:
    filter {
      dissect {
        add_tag => [ "foo_%{somefield}", "taggedy_tag"]
      }
    }

If the event has field "somefield" == "hello" this filter, on success, would add a tag foo_hello (and the second example would of course add a taggedy_tag tag).

convert_datatype

edit
  • Value type is hash
  • Default value is {}

With this setting int and float datatype conversions can be specified.
These will be done after all mapping dissections have taken place.
Feel free to use this setting on its own without a mapping section.

For example

filter {
  dissect {
    convert_datatype => {
      cpu => "float"
      code => "int"
    }
  }
}

enable_metric

edit
  • Value type is boolean
  • Default value is true

Disable or enable metric logging for this specific plugin instance by default we record all the metrics we can, but you can disable metrics collection for a specific plugin.

id

edit
  • Value type is string
  • There is no default value for this setting.

Add a unique ID to the plugin instance, this ID is used for tracking information for a specific configuration of the plugin.

output {
 stdout {
   id => "ABC"
 }
}

If you don’t explicitely set this variable Logstash will generate a unique name.

mapping

edit
  • Value type is hash
  • Default value is {}

A hash of dissections of field => value
A later dissection can be done on values from a previous dissection or they can be independent.

For example

filter {
  dissect {
    mapping => {
      "message" => "%{field1} %{field2} %{description}"
      "description" => "%{field3} %{field4} %{field5}"
    }
  }
}

This is useful if you want to keep the field description but also dissect it some more.

periodic_flush

edit
  • Value type is boolean
  • Default value is false

Call the filter flush method at regular interval. Optional.

remove_field

edit
  • Value type is array
  • Default value is []

If this filter is successful, remove arbitrary fields from this event. Fields names can be dynamic and include parts of the event using the %{field} Example:

    filter {
      dissect {
        remove_field => [ "foo_%{somefield}" ]
      }
    }
[source,ruby]
    # You can also remove multiple fields at once:
    filter {
      dissect {
        remove_field => [ "foo_%{somefield}", "my_extraneous_field" ]
      }
    }

If the event has field "somefield" == "hello" this filter, on success, would remove the field with name foo_hello if it is present. The second example would remove an additional, non-dynamic field.

remove_tag

edit
  • Value type is array
  • Default value is []

If this filter is successful, remove arbitrary tags from the event. Tags can be dynamic and include parts of the event using the %{field} syntax.

Example:

    filter {
      dissect {
        remove_tag => [ "foo_%{somefield}" ]
      }
    }
[source,ruby]
    # You can also remove multiple tags at once:
    filter {
      dissect {
        remove_tag => [ "foo_%{somefield}", "sad_unwanted_tag"]
      }
    }

If the event has field "somefield" == "hello" this filter, on success, would remove the tag foo_hello if it is present. The second example would remove a sad, unwanted tag as well.

tag_on_failure

edit
  • Value type is array
  • Default value is ["_dissectfailure"]

Append values to the tags field when dissection fails

« de_dot dns »