日志分析是ELK起家的最核心业务场景之一。
若是你正在使用Elastic Stack而且正尝试将自定义Logstash日志映射到Elasticsearch,那么这篇文章适合您。
Logstash写入ES以前的中间数据处理过程通常叫作:数据ETL或者数据清洗。
本文重点介绍数据清洗环节的非结构数据转化为结构化数据的——Grok实现。linux
老生常谈,夯实基础认知。
ELK Stack是三个开源项目的首字母缩写:Elasticsearch,Logstash和Kibana。 它们能够共同构成一个日志管理平台。
Elasticsearch:搜索和分析引擎。
Logstash:服务器端数据处理管道,它同时从多个源中提取数据,对其进行转换,而后将其发送到Elasticsearch存储。
Kibana:图表和图形来可视化数据ES中数据。
Beats后来出现,是一个轻量级的数据传输带(data shipper)。 Beats的引入将ELK Stack转换为Elastic Stack。
git
Grok是Logstash中的过滤器,用于将非结构化数据解析为结构化和可查询的数据。
它位于正则表达式之上,并使用文本模式匹配日志文件中的行。
下文分析你会看到,使用Grok在有效的日志管理方面大有裨益!github
一图胜千言。
若是没有Grok,当日志从Logstash发送到Elasticsearch并在Kibana中呈现时,它只会出如今消息值中。
在这种状况下,查询有意义的信息很困难,由于全部日志数据都存储在一个key中。
白话文——Grok的目的:
将如上一个key对应的一长串非结构的Value,转成多个结构化的Key对应多个结构化的Value。web
localhost GET / v2 / applink / 5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0
若是仔细查看原始数据,能够看到它实际上由不一样的部分组成,每一个部分用空格分隔符分隔。
对于更有经验的开发人员,您能够猜想每一个部分的含义,以及来自API调用的日志消息。
从数据分析的角度:非结构化数据不便于检索、统计、分析。正则表达式
localhost == environment (基础环境信息) GET == method (请求方式) /v2/applink/5c2f4bb3e9fda1234edc64d == url (URL地址) 400 == response_status (响应状态码) 46ms == response_time (响应时间) 5bc6e716b5d6cb35fc9687c0 == user_id (用户Id)
如上切分的中间转换正是借助grok实现。非结构化数据变成结构化数据后才凸显价值,检索、统计、分析等都变得很是简单了。apache
Logstash提供了超过100种内置模式,用于解析非结构化数据。
对于常见的系统日志,如apache,linux,haproxy,aws等,内置模式是刚需+标配。
可是,当您拥有自定义日志时会发生什么? 必须构建本身的自定义Grok模式。服务器
构建本身的自定义Grok模式须要反复试验。 推荐使用Grok Debugger和Grok Patterns作验证。
Grok Debugger地址:https://grokdebug.herokuapp.com/ ,注意:须要梯子。
Grok Patterns地址:https://github.com/elastic/logstash/blob/v1.4.2/patterns/grok-patternsapp
请注意,Grok模式的语法是:%{SYNTAX:SEMANTIC}
实践一把:
步骤1:进入Grok Debugger中的Discover选项卡。
指望这个工具能够自动生成Grok模式,但它没有太大帮助,由于它只发现了以下两个匹配。
elasticsearch
步骤2:借助Elastic的github上的语法在Grok Debugger上构建模式。
svg
步骤3:Grok Debugger实操验证。
如上截图:
输入待匹配的源非结构化数据:
localhost GET /v2/applink/5c2f4bb3e9fda1234edc64d 400 46ms 5bc6e716b5d6cb35fc9687c0
输入匹配模式:
%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}
输出结构化数据解析后匹配结果:
{ "environment": [ [ "localhost" ] ], "method": [ [ "GET" ] ], "url": [ [ "/v2/applink/5c2f4bb3e9fda1234edc64d" ] ], "response_status": [ [ "400" ] ], "BASE10NUM": [ [ "400" ] ], "response_time": [ [ "46ms" ] ], "user_id": [ [ "5bc6e716b5d6cb35fc9687c0" ] ] }
在使用不一样的语法后,终于可以以指望的方式构建日志数据。
步骤1:切换路径。
在安装ELK Stack的服务器上,切换到Logstash配置。
sudo vi /etc/logstash/conf.d/logstash.conf
步骤2:拷贝核心Grok配置, 更新Logstash.conf。
将验证后的grok部分贴过来。
注意:核心三段论结构。
一、输入:日志路径;
二、中间处理ETL:grok解析
三、输出:ES。
input { file { path => "/your_logs/*.log" } } filter{ grok { match => { "message" => "%{WORD:environment} %{WORD:method} %{URIPATH:url} %{NUMBER:response_status} %{WORD:response_time} %{USERNAME:user_id}"} } } output { elasticsearch { hosts => [ "localhost:9200" ] } }
步骤3:重启。
保存更改后,从新启动Logstash并检查其状态以确保它仍然有效。
sudo service logstash restart sudo service logstash status
最后,为了确保更改生效,请务必刷新Kibana中Logstash写入的Elasticsearch索引!
结论以下图所示:使用Grok,您的日志数据是结构化的!
Grok可以自动将日志数据映射到Elasticsearch。 这样能够更轻松地管理日志并快速实现查询、统计、分析操做。
这是一篇翻译文章。当近期在尝试写相似解析文章的时候,发现国外已经有讲解的很是透彻的文章。
所以,在原文基础上作了实践验证和通俗化的解读,但愿对你有帮助。
划重点:Grok Debugger和Grok Patterns工具的使用,会事半功倍,极大提升开发效率,避免没必要要的“黑暗中摸索”。
思考:若是内置的grok pattern和自定义的pattern都不能知足已有复杂日志的匹配?咱们该如何处理呢?
欢迎留言,写下你的思考。相信深度的思考,能提高你的技术认知!
原文地址:https://hackernoon.com/structuring-unstructured-data-with-grok-bcdbb240fcd1
推荐阅读:https://www.elastic.co/cn/blog/do-you-grok-grok
铭毅天下——Elasticsearch基础、进阶、实战第一公众号