logstash配置文件写法踩坑

前言

踩坑

正文

坑点一:在 logstash 里会认定字母都是小写,不管你实际上是不是小写

例如有一个 MYSQL 表要配置 logstash 规则,其中一个字段名为 entranceSource 中间有一个大写字母
如果这样配置,不会生效

1
2
3
4
5
6
7
filter {
mutate {
rename => {
"entranceSource" => "enter_source"
}
}
}

因为 logstash 认为 entranceSource 这个字段名是不存在的,而存在的是 entrancesource (也就是名字中大写字母被认定为小写字母了)

所以,这样配置是可以的:

1
2
3
4
5
6
7
filter {
mutate {
rename => {
"entrancesource" => "enter_source"
}
}
}

坑点二:在将业务中的 日期类型数据 覆盖到 @timestamp 上时,需要先增加成临时字段

例如,在 MySQL 中有个 datetime 类型的字段 create_time 想要附加到 @timestamp 上,直接用

1
2
3
4
5
date {
match => ["create_time", "ISO8601"]
target => "@timestamp"
timezone => "Asia/Shanghai"
}

会报出日期格式不正确,而先将此字段 add_field 成一个临时字段,再做处理则不会存在问题

1
2
3
4
5
6
7
8
9
10
11
12
mutate {
add_field => {
"temp_ts" => "%{create_time}"
}
}

date {
match => ["temp_ts", "ISO8601"]
target => "@timestamp"
remove_field => ["temp_ts"]
timezone => "Asia/Shanghai"
}

坑点三:想重建整个索引时,要先停 logstash 进程再删运行游标文件

如果先删游标文件再停进程,则会造成游标文件很快又被写入了,删了也白删

坑点四:在以时间类型为跟踪字段时要用 >= 而不要用 >

之所以用 >= 是考虑到有可能跟踪字段只精确到秒,而不是毫秒,而在一秒内就可能会落入多条数据,这样下次继续时,这些数据就被忽略了

1
2
3
4
5
6
7
8
9
10
11
12
...代码片段...

record_last_run => "true"
use_column_value => "true"
tracking_column => "update_time"
tracking_column_type => "timestamp"

...代码片段...

statement => "SELECT * from t_some_table where update_time >= :sql_last_value"

...代码片段...