Elasticsearch:Dissect 和 Grok 处理器之间的区别

Elastic 专栏收录该内容
494 篇文章 87 订阅

针对很多情况我们可以直接使用 Dissect 处理器来对非结构化化的日志进行结构化。在我之前的文章 “Elasticsearch:深入理解 Dissect ingest processor” 有做笔记深入的讲解。在很多的情况下,我们也可以使用 Grok  处理器来进行结构化。那么这两者之间有什么区别呢?在实际的使用中,我们到底首先哪一个呢?

一般来说,我们需要首先 Dissect 处理器,这是因为它的速度比 Grok 要快很多。Grok 是基于正则匹配,执行速度比 Dissect 要蛮很多。当然 Grok 也有自己的独到之处。它可以同时使用多个 patterns 来对日志来进行匹配。这个是 Dissect 不具备的能力。

下面,我们使用一些简单的例子来进行展示。

展示

我们可以使用 Dissect 处理器来对如下的日志来进行格式化。我们知道 Dissect 处理器对空格非常敏感。如果匹配不对,就会解析失败。

POST _ingest/pipeline/_simulate
{
  "pipeline": {
    "processors": [
      {
        "dissect": {
          "field": "message",
          "pattern": "%{@timestamp->} %{status}"
        }
      }
    ]
  },
  "docs": [
    {
      "_source": {
        "message": "2019-09-29 STATUS_OK"
      }
    },
    {
      "_source": {
        "message": "2019-09-29       STATUS_OK"
      }
    }
  ]
}

在上面,尽管两个 message 的格式有所不同,但是我们使用了 -> 来避免错误的解析。上面命令显示的结果为:

{
  "docs" : [
    {
      "doc" : {
        "_index" : "_index",
        "_type" : "_doc",
        "_id" : "_id",
        "_source" : {
          "@timestamp" : "2019-09-29",
          "message" : "2019-09-29 STATUS_OK",
          "status" : "STATUS_OK"
        },
        "_ingest" : {
          "timestamp" : "2021-07-20T01:29:27.141784Z"
        }
      }
    },
    {
      "doc" : {
        "_index" : "_index",
        "_type" : "_doc",
        "_id" : "_id",
        "_source" : {
          "@timestamp" : "2019-09-29",
          "message" : "2019-09-29       STATUS_OK",
          "status" : "STATUS_OK"
        },
        "_ingest" : {
          "timestamp" : "2021-07-20T01:29:27.14179Z"
        }
      }
    }
  ]
}

上面的解析,我们也可以使用 Grok 处理器来进行解析:

POST _ingest/pipeline/_simulate
{
  "pipeline": {
    "processors": [
      {
        "grok": {
          "field": "message",
          "patterns": [
            "%{EVENTDATE:@timestamp} %{WORD:status}"
          ],
          "pattern_definitions": {
            "EVENTDATE": "%{YEAR}-%{MONTHNUM}-%{MONTHDAY}"
          }
        }
      }
    ]
  },
  "docs": [
    {
      "_source": {
        "message": "2019-09-29 STATUS_OK"
      }
    }
  ]
}

在上面,我们使用了定制的 pattern 来完成对 @timestamp 的解析。你可以进一步阅读 “Elastic:在 Grok 中运用 custom pattern 来定义 pattern”。上面运行的结果为:

{
  "docs" : [
    {
      "doc" : {
        "_index" : "_index",
        "_type" : "_doc",
        "_id" : "_id",
        "_source" : {
          "@timestamp" : "2019-09-29",
          "message" : "2019-09-29 STATUS_OK",
          "status" : "STATUS_OK"
        },
        "_ingest" : {
          "timestamp" : "2021-07-20T01:31:22.028392Z"
        }
      }
    }
  ]
}

就像我之前所说的,尽管 Dissect 和 Grok 都可以满足要求,我们首选 Dissect,毕竟它的效率要高很多。正则匹配是一个比较慢的运算。

在 Grok 使用多个 patterns 进行匹配

在上面,我们展示了 Dissect 和 Grok。在许多的情况下,它们都可以派上用场,但是有一种情况是 Grok 独有的。Grok 它可以同时使用多个 patterns 来对日志的文件进行匹配。比如,我们有如下的两种日志:

{
    "message": "55.3.244.1 OK"
}

{
    "message": "55.3.244.1 0.043"
}

 显然上面的两种日志的格式是完全不同的。第一种的情况是 IP 加上一个 status,而对于第二种情况来说说,它是 IP 加上一个浮点数。在这种情况下,我们使用 Dissect 是完全无能为力了。

我们可以使用 Grok 来完美地匹配这两种情况:

POST _ingest/pipeline/_simulate
{
  "pipeline": {
    "processors": [
      {
        "grok": {
          "field": "message",
          "patterns": [
            "%{IP:client} %{NUMBER:duration:float}",
            "%{IP:client} %{WORD:status}"
          ]
        }
      }
    ]
  },
  "docs": [
    {
      "_source": {
        "message": "55.3.244.1 OK"
      }
    },
    {
      "_source": {
        "message": "55.3.244.1 0.043"
      }
    }
  ]
}

在上面,我们在 Grok 的 pattern 里定义了如下的 patterns:

"patterns": [
    "%{IP:client} %{NUMBER:duration:float}",
    "%{IP:client} %{WORD:status}"
]

也就是说它可以同时匹配两个模式。其中的任何一个匹配,就可以完成文档的正确解析。运行上面的命令,我们可以看到如下的结果:

{
  "docs" : [
    {
      "doc" : {
        "_index" : "_index",
        "_type" : "_doc",
        "_id" : "_id",
        "_source" : {
          "client" : "55.3.244.1",
          "message" : "55.3.244.1 OK",
          "status" : "OK"
        },
        "_ingest" : {
          "timestamp" : "2021-07-20T01:39:44.282416Z"
        }
      }
    },
    {
      "doc" : {
        "_index" : "_index",
        "_type" : "_doc",
        "_id" : "_id",
        "_source" : {
          "duration" : 0.043,
          "client" : "55.3.244.1",
          "message" : "55.3.244.1 0.043"
        },
        "_ingest" : {
          "timestamp" : "2021-07-20T01:39:44.282424Z"
        }
      }
    }
  ]
}

从输出的结果中,我们可以清楚地看到结构化的输出。

我们甚至结合定制 pattern,让它生成更为复杂的匹配模式:

POST _ingest/pipeline/_simulate
{
  "pipeline": {
    "processors": [
      {
        "grok": {
          "field": "message",
          "patterns": [
            "%{IP:client} %{VERSION:version} %{NUMBER:num}",
            "%{IP:client} %{NUMBER:duration:float} %{NUMBER:num}",
            "%{IP:client} %{WORD:status} %{NUMBER:num}"
          ],
          "pattern_definitions": {
            "VERSION": """\d\.\d+\.\d"""
          }
        }
      }
    ]
  },
  "docs": [
    {
      "_source": {
        "message": "55.3.244.1 7.31.1 12"
      }
    },
    {
      "_source": {
        "message": "55.3.244.1 OK 14"
      }
    },
    {
      "_source": {
        "message": "55.3.244.1 0.043 15"
      }
    }
  ]
}

在上面,我们运用 custom pattterns 来定制一个 pattern。它被用来匹配 version。上面运行的结果是:

{
  "docs" : [
    {
      "doc" : {
        "_index" : "_index",
        "_type" : "_doc",
        "_id" : "_id",
        "_source" : {
          "num" : "12",
          "client" : "55.3.244.1",
          "message" : "55.3.244.1 7.31.1 12",
          "version" : "7.31.1"
        },
        "_ingest" : {
          "timestamp" : "2021-07-20T02:21:22.447666Z"
        }
      }
    },
    {
      "doc" : {
        "_index" : "_index",
        "_type" : "_doc",
        "_id" : "_id",
        "_source" : {
          "num" : "14",
          "client" : "55.3.244.1",
          "message" : "55.3.244.1 OK 14",
          "status" : "OK"
        },
        "_ingest" : {
          "timestamp" : "2021-07-20T02:21:22.447673Z"
        }
      }
    },
    {
      "doc" : {
        "_index" : "_index",
        "_type" : "_doc",
        "_id" : "_id",
        "_source" : {
          "duration" : 0.043,
          "num" : "15",
          "client" : "55.3.244.1",
          "message" : "55.3.244.1 0.043 15"
        },
        "_ingest" : {
          "timestamp" : "2021-07-20T02:21:22.447676Z"
        }
      }
    }
  ]
}
  • 0
    点赞
  • 0
    评论
  • 0
    收藏
  • 一键三连
    一键三连
  • 扫一扫,分享海报

相关推荐
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值