临沂小学网站建设,黄埔商城网站建设,9377烈焰传奇手游官网,网站优化排名哪家性价比高有时 Logstash Grok 没有我们需要的模式。 幸运的是我们有正则表达式库#xff1a;Oniguruma。在很多时候#xff0c;如果 Logstash 所提供的正则表达不能满足我们的需求#xff0c;我们选用定制自己的表达式。 定义
Logstash 是一种服务器端数据处理管道#xff0c;可同时…
有时 Logstash Grok 没有我们需要的模式。 幸运的是我们有正则表达式库Oniguruma。在很多时候如果 Logstash 所提供的正则表达不能满足我们的需求我们选用定制自己的表达式。 定义
Logstash 是一种服务器端数据处理管道可同时从多个来源获取数据对其进行转换然后将其发送到 “存储”如 Elasticsearch。Grok 是 Logstash 中的过滤器用于将非结构化数据解析为结构化和可查询的内容。Regular expression 是定义搜索模式的字符序列。
如果你已经在运行 Logstash则无需安装额外的正则表达式库因为 Grok 位于正则表达式之上因此任何正则表达式在 grok 中也有效 —— Elastic 文档。 语法
Grok
Grok 语法如下
%{SYNTAX:SEMANTIC}
SYNTAX 是默认的 grok 模式SEMANTIC 是 keyOniguruma
oniguruma 语法如下
(?field_namethe pattern here) Grok Oniguruma
你可以像下面这样组合 Grok 和 Oniguruma
%{SYNTAX:SEMANTIC} (?field_namethe pattern here) 让我们开始吧 样本数据
为了演示我们如何将 Oniguruma 与 Grok 结合使用我们将在示例中使用下面的日志数据。 production GET /v2/blacklist/ 200 24ms 5ba9e948801d34906b96e0c20 Panya/1.6.3 (com.sn.panya.host; build:1; iOS 10.3.3) Alamofire/4.66.0 {\user_id\:\5bd4c2f4569f470016bd8d55\,\reason\:\SPAMMER\} 日志数据结构
production environment
GET method
/v2/blacklist url
200 response_status
24ms response_time
5bc6e716b5d6cb35fc9687c0 user_id
Panya/1.6.3 (com.sn.panya.host; build:1; iOS 10.3.3) Alamofire/4.66.0 user_agent
{\user_id\:\5bd4c2f4569f470016bd8d55\,\reason\:\SPAMMER\} req.body
目的
目标是找到一种模式来构造非结构化日志数据。为此我们将使用 Kibana 里的 Grok Debugger 来进行测试 其中我们的 Grok pattern 定义如下
%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}
如上所示上面的 Grok pattern 产生如下的结果
{environment: production,method: GET,response_status: 200,user_id: 5ba9e948801d34906b96e0c20,response_time: 24ms,url: /v2/blacklist/
}
这是一个不错的开始但还不完整。 没有 user_agent 和 req.body 的映射。要提取 user_agent 和 req.body我们需要仔细检查其结构。 空格分隔符
值 production GET /v2/blacklist/ 200 24ms 5ba9e948801d34906b96e0c20 由空格分隔这很容易使用。
但是对于 user_agent可以有动态数量的空格具体取决于发送请求的硬件类型。
Panya/1.6.3 (com.sn.panya.host; build:1; iOS 10.3.3) Alamofire/4.66.0
我们如何解释这种持续变化 提示看一下 req.body 的结构。 {\”user_id\”:\”5bd4c2f4569f470016bd8d55\”,\”reason\”:\”SPAMMER\”}
我们可以看到 req.body 是由花括号 {} 组成的。
利用这些知识我们可以构建一个自定义正则表达式模式来查找第一个左括号之前的所有内容然后获取之后的所有内容。 在上面我们使用 Grok pattern
(?user_agent[^{]*) %{GREEDYDATA:body}
你可在这个链接中找到 “regex match everything until character”。 把所有的都放在一起
将其应用于 grok 调试器中的自定义正则表达式模式我们得到了我们想要的结果 我们的 Grok pattern 为
%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id} (?user_agent[^{]*) %{GREEDYDATA:body}创建 logstash.conf
为了能够测试我们的 Grok pattern 是否正确我们创建如下的一个 logstash.conf 文件。我们可以参考之前的文章 “Logstash在实施之前测试 Logstash 管道/过滤器”。
logstash.conf
input {generator {message production GET /v2/blacklist/ 200 24ms 5ba9e948801d34906b96e0c20 Panya/1.6.3 (com.sn.panya.host; build:1; iOS 10.3.3) Alamofire/4.66.0 {user_id:5bd4c2f4569f470016bd8d55,reason:SPAMMER}count 1}
}filter {grok {match { message %{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id1} (?user_agent[^{]*) %{GREEDYDATA:body}}}mutate {remove_field [message, event, host, version]}
} output {stdout {codec rubydebug}
}
我们使用如下的命令来启动 Logstash pipeline
./bin/logstash -f logstash.conf 从上面的输出中我们可以看出来原始的数据已经变为结构化的数据了。我们可以看到美中不足的是 body 这个数据是一个 JSON 格式的数据还没有被结构化。我们进一步修改我们的 logstash.conf 配置文件
logstash.conf
input {generator {message production GET /v2/blacklist/ 200 24ms 5ba9e948801d34906b96e0c20 Panya/1.6.3 (com.sn.panya.host; build:1; iOS 10.3.3) Alamofire/4.66.0 {user_id:5bd4c2f4569f470016bd8d55,reason:SPAMMER}count 1}
}filter {grok {match { message %{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id1} (?user_agent[^{]*) %{GREEDYDATA:body}}}json {source body}mutate {remove_field [message, event, host, version, body]}} output {stdout {codec rubydebug}
}
在上面我们添加了 json 过滤器来处理 body从而更进一步结构化数据。我们再次运行 Logstash。我们可以看到如下的结果 从上面我们可以看到 body 也被结果化了。我们可以看到 user_id 及 reason 两个字段。
