Grok
Last updated
Last updated
processor_grok
插件可以通过 Grok 语法匹配的模式,实现文本日志的字段提取。
Type
String,无默认值(必填)
插件类型,固定为processor_grok
CustomPatternDir
Array,其中 value 为 String,[]
自定义的GROK模式所在的文件夹地址,会读取文件夹内的所有文件。需要重启生效。
CustomPatterns
Map,其中 key 和 value 为 String,{}
自定义的GROK模式,key 为规则名,value 为 grok 表达式。
SourceKey
String,content
需要匹配的目标字段。
Match
Array,其中 value 为 String,[]
TimeoutMilliSeconds
Long,0
解析 grok 表达式的最大尝试时间,单位为毫秒,设置为 0 禁用超时。
IgnoreParseFailure
Boolean,true
指定解析失败后的操作,不配置表示放弃解析,直接填充所返回的 content 字段。配置为 false ,表示解析失败时丢弃日志。
KeepSource
Boolean,true
是否保留原字段。
NoKeyError
Boolean,false
无匹配的原始字段时是否报错。
NoMatchError
Boolean,false
Match 中的表达式全不匹配时是否报错。
TimeoutError
Boolean,false
匹配超时是否返回错误。
采集/home/test-ilogtail/test-log/
路径下的processor-grok.log
文件,根据指定的配置选项提取日志信息。
采集配置
输入1
输出1
输入2
输出2
输入3
输出3
输入4
输出4
输出说明
在样例一中,processor_grok 插件首先使用 Match 中的第一个表达式 '%{HTTP}' 匹配日志,失败后进行下一个尝试。然后匹配 Match 中的第二个表达式 '%{WORD:word1} %{NUMBER:request_time} %{WORD:word2}' 成功,返回结果。由于 KeepSource 参数设置为 false,所以原日志的 content 的字段被丢弃了。 样例二、样例四与样例一类似,分别使用 Match 中的第三和第一个表达式成功匹配日志。 在样例三中,processor_grok 插件使用 Match 中的三个表达式均匹配失败,所以没有任何结果。又因为 IgnoreParseFailure 设置为了 false,所以匹配失败的样例输出三的 content 字段被丢弃了。
Grok 语法在匹配失败的情况下时间开销巨大。为了提高插件解析的效率,必须优化匹配失败的时间,这里给出几种可以优化匹配失败时间的思路。
表达式与数据尽量完全匹配
在 grok 表达式中添加锚点,例如^、$等,减少不必要的匹配尝试
设置超时时间,即配置参数中的 TimeoutMilliSeconds 参数
因此,在使用 processor_grok
插件时,最好尽量不使用多项匹配,或者 Match 中设置尽可能少的 Grok 表达式。也可以通过减少重复的匹配,来优化效率。下面是使用分层策略减少重复匹配的一个样例。
输入
输入共三条数据
常规配置
标准的多项匹配,一个一个匹配完整的表达式。
优化配置
先统一处理前半部分,然后统一处理后半部分
用来匹配的 Grok 表达式数组。Grok 插件会从上至下依次使用 Match 中的表达式对日志进行匹配,并返回第一个匹配成功的结果。配置多条会影响性能,可以参考
processor_grok
插件主要使用 SLS 的 。SLS数据加工提供了 70+ 常用的 GROK 模式,例如身份证号、邮箱、MAC 地址、IPV4、IPV6、时间解析、URL 解析等。此外,还整合了一些其他通用的 Grok 模式。
所有的 Grok 模式模版请见。
由于 Golang 原生的 regexp
库不支持一些高级的正则语法,故 processor_grok
的正则引擎使用第三方的 库。regexp2
库与 Golang 原生的 regexp
的简单性能对比可以参考源代码中的 。
processor_grok
插件支持多项匹配,即可以在 Match 中设置多个 Grok 表达式,依次对日志进行匹配尝试。但使用多项匹配时,由于需要一个个匹配合适的表达式,会经历很多匹配失败的情况。可以参考源代码中的 ,其对 Match 中有1、2、3、5条表达式的情况,分别做了简单的模拟匹配失败的性能测试,可以看出效率是成倍降低的。