honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/docs/reference/ingest/processors/grok.asciidoc

350 lines
12 KiB
Plaintext
Raw Normal View History

Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
[[grok-processor]]
[DOCS] Fix case of ingest processor titles (#61024) (#61039) Converts page headings to sentence case. Adds a title abbreviation.
2020-08-12 11:49:54 -04:00
=== Grok processor
++++
<titleabbrev>Grok</titleabbrev>
++++
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
Extracts structured fields out of a single text field within a document. You choose which field to
extract matched fields from, as well as the grok pattern you expect will match. A grok pattern is like a regular
expression that supports aliased expressions that can be reused.
This tool is perfect for syslog logs, apache and other webserver logs, mysql logs, and in general, any log format
that is generally written for humans and not computer consumption.
This processor comes packaged with many
https://github.com/elastic/elasticsearch/blob/{branch}/libs/grok/src/main/resources/patterns[reusable patterns].
[DOCS] http -> https, remove outdated plugin docs (#60380) (#60545) Plugin discovery documentation contained information about installing Elasticsearch 2.0 and installing an oracle JDK, both of which is no longer valid. While noticing that the instructions used cleartext HTTP to install packages, this commit replaces HTTPs links instead of HTTP where possible. In addition a few community links have been removed, as they do not seem to exist anymore. Co-authored-by: Alexander Reelsen <alexander@reelsen.net>
2020-07-31 16:16:31 -04:00
If you need help building patterns to match your logs, you will find the {kibana-ref}/xpack-grokdebugger.html[Grok Debugger] tool quite useful! The Grok Debugger is an {xpack} feature under the Basic License and is therefore *free to use*. The https://grokconstructor.appspot.com[Grok Constructor] is also a useful tool.
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
[[grok-basics]]
==== Grok Basics
Grok sits on top of regular expressions, so any regular expressions are valid in grok as well.
The regular expression library is Oniguruma, and you can see the full supported regexp syntax
[DOCS] Various spelling corrections (#37046)
2019-01-07 08:44:12 -05:00
https://github.com/kkos/oniguruma/blob/master/doc/RE[on the Oniguruma site].
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
Grok works by leveraging this regular expression language to allow naming existing patterns and combining them into more
complex patterns that match your fields.
The syntax for reusing a grok pattern comes in three forms: `%{SYNTAX:SEMANTIC}`, `%{SYNTAX}`, `%{SYNTAX:SEMANTIC:TYPE}`.
The `SYNTAX` is the name of the pattern that will match your text. For example, `3.44` will be matched by the `NUMBER`
pattern and `55.3.244.1` will be matched by the `IP` pattern. The syntax is how you match. `NUMBER` and `IP` are both
patterns that are provided within the default patterns set.
The `SEMANTIC` is the identifier you give to the piece of text being matched. For example, `3.44` could be the
duration of an event, so you could call it simply `duration`. Further, a string `55.3.244.1` might identify
the `client` making a request.
The `TYPE` is the type you wish to cast your named field. `int`, `long`, `double`, `float` and `boolean` are supported types for coercion.
For example, you might want to match the following text:
[source,txt]
--------------------------------------------------
3.44 55.3.244.1
--------------------------------------------------
You may know that the message in the example is a number followed by an IP address. You can match this text by using the following
Grok expression.
[source,txt]
--------------------------------------------------
%{NUMBER:duration} %{IP:client}
--------------------------------------------------
[[using-grok]]
==== Using the Grok Processor in a Pipeline
[[grok-options]]
.Grok Options
[options="header"]
|======
| Name | Required | Default | Description
| `field` | yes | - | The field to use for grok expression parsing
| `patterns` | yes | - | An ordered list of grok expression to match and extract named captures with. Returns on the first expression in the list that matches.
| `pattern_definitions` | no | - | A map of pattern-name and pattern tuples defining custom patterns to be used by the current processor. Patterns matching existing names will override the pre-existing definition.
| `trace_match` | no | false | when true, `_ingest._grok_match_index` will be inserted into your matched document's metadata with the index into the pattern found in `patterns` that matched.
| `ignore_missing` | no | false | If `true` and `field` does not exist or is `null`, the processor quietly exits without modifying the document
include::common-options.asciidoc[]
|======
Here is an example of using the provided patterns to extract out and name structured fields from a string field in
a document.
Docs: Fix & test more grok processor documentation (#49447) The documentation contained a small error, as bytes and duration was not properly converted to a number and thus remained a string. The documentation is now also properly tested by providing a full blown simulate pipeline example.
2019-12-03 05:47:27 -05:00
[source,console]
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
--------------------------------------------------
Docs: Fix & test more grok processor documentation (#49447) The documentation contained a small error, as bytes and duration was not properly converted to a number and thus remained a string. The documentation is now also properly tested by providing a full blown simulate pipeline example.
2019-12-03 05:47:27 -05:00
POST _ingest/pipeline/_simulate
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
{
Docs: Fix & test more grok processor documentation (#49447) The documentation contained a small error, as bytes and duration was not properly converted to a number and thus remained a string. The documentation is now also properly tested by providing a full blown simulate pipeline example.
2019-12-03 05:47:27 -05:00
"pipeline": {
"description" : "...",
"processors": [
{
"grok": {
"field": "message",
"patterns": ["%{IP:client} %{WORD:method} %{URIPATHPARAM:request} %{NUMBER:bytes:int} %{NUMBER:duration:double}"]
}
}
]
},
"docs":[
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
{
Docs: Fix & test more grok processor documentation (#49447) The documentation contained a small error, as bytes and duration was not properly converted to a number and thus remained a string. The documentation is now also properly tested by providing a full blown simulate pipeline example.
2019-12-03 05:47:27 -05:00
"_source": {
"message": "55.3.244.1 GET /index.html 15824 0.043"
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
}
}
]
}
--------------------------------------------------
This pipeline will insert these named captures as new fields within the document, like so:
Docs: Fix & test more grok processor documentation (#49447) The documentation contained a small error, as bytes and duration was not properly converted to a number and thus remained a string. The documentation is now also properly tested by providing a full blown simulate pipeline example.
2019-12-03 05:47:27 -05:00
[source,console-result]
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
--------------------------------------------------
{
Docs: Fix & test more grok processor documentation (#49447) The documentation contained a small error, as bytes and duration was not properly converted to a number and thus remained a string. The documentation is now also properly tested by providing a full blown simulate pipeline example.
2019-12-03 05:47:27 -05:00
"docs": [
{
"doc": {
"_index": "_index",
"_type": "_doc",
"_id": "_id",
"_source" : {
"duration" : 0.043,
"request" : "/index.html",
"method" : "GET",
"bytes" : 15824,
"client" : "55.3.244.1",
"message" : "55.3.244.1 GET /index.html 15824 0.043"
},
"_ingest": {
"timestamp": "2016-11-08T19:43:03.850+0000"
}
}
}
]
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
}
--------------------------------------------------
Docs: Fix & test more grok processor documentation (#49447) The documentation contained a small error, as bytes and duration was not properly converted to a number and thus remained a string. The documentation is now also properly tested by providing a full blown simulate pipeline example.
2019-12-03 05:47:27 -05:00
// TESTRESPONSE[s/2016-11-08T19:43:03.850\+0000/$body.docs.0.doc._ingest.timestamp/]
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
[[custom-patterns]]
==== Custom Patterns
[Docs] Update ingest-node.asciidoc (#37116)
2019-01-04 13:20:32 -05:00
The Grok processor comes pre-packaged with a base set of patterns. These patterns may not always have
what you are looking for. Patterns have a very basic format. Each entry has a name and the pattern itself.
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
You can add your own patterns to a processor definition under the `pattern_definitions` option.
Here is an example of a pipeline specifying custom pattern definitions:
[source,js]
--------------------------------------------------
{
"description" : "...",
"processors": [
{
"grok": {
"field": "message",
"patterns": ["my %{FAVORITE_DOG:dog} is colored %{RGB:color}"],
"pattern_definitions" : {
"FAVORITE_DOG" : "beagle",
"RGB" : "RED|GREEN|BLUE"
}
}
}
]
}
--------------------------------------------------
// NOTCONSOLE
[[trace-match]]
==== Providing Multiple Match Patterns
Sometimes one pattern is not enough to capture the potential structure of a field. Let's assume we
want to match all messages that contain your favorite pet breeds of either cats or dogs. One way to accomplish
this is to provide two distinct patterns that can be matched, instead of one really complicated expression capturing
the same `or` behavior.
Here is an example of such a configuration executed against the simulate API:
[DOCS] Change // CONSOLE comments to [source,console] (#46441) (#46451)
2019-09-06 11:31:13 -04:00
[source,console]
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
--------------------------------------------------
POST _ingest/pipeline/_simulate
{
"pipeline": {
"description" : "parse multiple patterns",
"processors": [
{
"grok": {
"field": "message",
"patterns": ["%{FAVORITE_DOG:pet}", "%{FAVORITE_CAT:pet}"],
"pattern_definitions" : {
"FAVORITE_DOG" : "beagle",
"FAVORITE_CAT" : "burmese"
}
}
}
]
},
"docs":[
{
"_source": {
"message": "I love burmese cats!"
}
}
]
}
--------------------------------------------------
response:
[DOCS] [5 of 5] Change // TESTRESPONSE comments to [source,console-results] (#46449) (#46459)
2019-09-06 16:09:09 -04:00
[source,console-result]
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
--------------------------------------------------
{
"docs": [
{
"doc": {
Deprecate `_type` in simulate pipeline requests (#37949) As mapping types are being removed throughout Elasticsearch, the use of `_type` in pipeline simulation requests is deprecated. Additionally, the default `_type` used if one is not supplied has been changed to `_doc` for consistency with the rest of Elasticsearch.
2019-02-04 18:11:44 -05:00
"_type": "_doc",
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
"_index": "_index",
"_id": "_id",
"_source": {
"message": "I love burmese cats!",
"pet": "burmese"
},
"_ingest": {
"timestamp": "2016-11-08T19:43:03.850+0000"
}
}
}
]
}
--------------------------------------------------
// TESTRESPONSE[s/2016-11-08T19:43:03.850\+0000/$body.docs.0.doc._ingest.timestamp/]
Both patterns will set the field `pet` with the appropriate match, but what if we want to trace which of our
patterns matched and populated our fields? We can do this with the `trace_match` parameter. Here is the output of
that same pipeline, but with `"trace_match": true` configured:
////
Hidden setup for example:
[DOCS] Change // CONSOLE comments to [source,console] (#46441) (#46451)
2019-09-06 11:31:13 -04:00
[source,console]
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
--------------------------------------------------
POST _ingest/pipeline/_simulate
{
"pipeline": {
"description" : "parse multiple patterns",
"processors": [
{
"grok": {
"field": "message",
"patterns": ["%{FAVORITE_DOG:pet}", "%{FAVORITE_CAT:pet}"],
"trace_match": true,
"pattern_definitions" : {
"FAVORITE_DOG" : "beagle",
"FAVORITE_CAT" : "burmese"
}
}
}
]
},
"docs":[
{
"_source": {
"message": "I love burmese cats!"
}
}
]
}
--------------------------------------------------
////
[DOCS] [5 of 5] Change // TESTRESPONSE comments to [source,console-results] (#46449) (#46459)
2019-09-06 16:09:09 -04:00
[source,console-result]
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
--------------------------------------------------
{
"docs": [
{
"doc": {
Deprecate `_type` in simulate pipeline requests (#37949) As mapping types are being removed throughout Elasticsearch, the use of `_type` in pipeline simulation requests is deprecated. Additionally, the default `_type` used if one is not supplied has been changed to `_doc` for consistency with the rest of Elasticsearch.
2019-02-04 18:11:44 -05:00
"_type": "_doc",
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
"_index": "_index",
"_id": "_id",
"_source": {
"message": "I love burmese cats!",
"pet": "burmese"
},
"_ingest": {
"_grok_match_index": "1",
"timestamp": "2016-11-08T19:43:03.850+0000"
}
}
}
]
}
--------------------------------------------------
// TESTRESPONSE[s/2016-11-08T19:43:03.850\+0000/$body.docs.0.doc._ingest.timestamp/]
In the above response, you can see that the index of the pattern that matched was `"1"`. This is to say that it was the
second (index starts at zero) pattern in `patterns` to match.
This trace metadata enables debugging which of the patterns matched. This information is stored in the ingest
metadata and will not be indexed.
[[grok-processor-rest-get]]
==== Retrieving patterns from REST endpoint
The Grok Processor comes packaged with its own REST endpoint for retrieving which patterns the processor is packaged with.
[DOCS] Change // CONSOLE comments to [source,console] (#46441) (#46451)
2019-09-06 11:31:13 -04:00
[source,console]
Split the ingest processor docs into multiple files (#36887) This commit breaks the single ingest docs file into multiple files, factoring out the processor docs into a documentation file per processor. This will help make this content easier to maintain.
2018-12-20 08:04:54 -05:00
--------------------------------------------------
GET _ingest/processor/grok
--------------------------------------------------
The above request will return a response body containing a key-value representation of the built-in patterns dictionary.
[source,js]
--------------------------------------------------
{
"patterns" : {
"BACULA_CAPACITY" : "%{INT}{1,3}(,%{INT}{3})*",
"PATH" : "(?:%{UNIXPATH}|%{WINPATH})",
...
}
--------------------------------------------------
// NOTCONSOLE
This can be useful to reference as the built-in patterns change across versions.
[[grok-watchdog]]
==== Grok watchdog
Grok expressions that take too long to execute are interrupted and
the grok processor then fails with an exception. The grok
processor has a watchdog thread that determines when evaluation of
a grok expression takes too long and is controlled by the following
settings:
[[grok-watchdog-options]]
.Grok watchdog settings
[options="header"]
|======
| Name | Default | Description
| `ingest.grok.watchdog.interval` | 1s | How often to check whether there are grok evaluations that take longer than the maximum allowed execution time.
| `ingest.grok.watchdog.max_execution_time` | 1s | The maximum allowed execution of a grok expression evaluation.
|======
[7.x] Ensure Joni warning are logged at debug (#57302) (#57897) When Joni, the regex engine that powers grok emits a warning it does so by default to System.err. System.err logs are all bucketed together in the server log at WARN level. When Joni emits a warning, it can be extremely verbose, logging a message for each execution again that pattern. For ingest node that means for every document that is run that through Grok. Fortunately, Joni provides a call back hook to push these warnings to a custom location. This commit implements Joni's callback hook to push the Joni warning to the Elasticsearch server logger (logger.org.elasticsearch.ingest.common.GrokProcessor) at debug level. Generally these warning indicate a possible issue with the regular expression and upon creation of the Grok processor will do a "test run" of the expression and log the result (if any) at WARN level. This WARN level log should only occur on pipeline creation which is a much lower frequency then every document. Additionally, the documentation is updated with instructions for how to set the logger to debug level.
2020-06-09 18:06:29 -04:00
[[grok-debugging]]
==== Grok debugging
It is advised to use the {kibana-ref}/xpack-grokdebugger.html[Grok Debugger] to debug grok patterns. From there you can test one or more
patterns in the UI against sample data. Under the covers it uses the same engine as ingest node processor.
Additionally, it is recommended to enable debug logging for Grok so that any additional messages may also be seen in the Elasticsearch
server log.
[source,js]
--------------------------------------------------
PUT _cluster/settings
{
"transient": {
"logger.org.elasticsearch.ingest.common.GrokProcessor": "debug"
}
}
--------------------------------------------------
// NOTCONSOLE