用logstash导入ES且自定义mapping时踩的坑

问题发生背景:

1.本来我是使用logstash的默认配置向ES导入日志的。然后很嗨皮,发现一切OK,后来我开始对日志进行聚合统计,发现terms聚合时的key很奇怪,后来查询这奇怪的key,发现这些关键字都是源字符串的一段,而且全部复现场景都是出现"xxxx-xxxxxx"时就会截断,感觉像是分词器搞的鬼。所以想自己定制mapping。下面是原来的logstash配置
output{
elasticsearch{
action => "index"
hosts => ["xxxxxx:9200"]
index => "xxxxx"
document_type => "haha"
}
}



说干就干:

开始四处查阅文档,发现可以定制mapping,很开心。
output{
elasticsearch{
action => "index"
hosts => ["xxx"]
index => "logstashlog"
template => "xx/http-logstash.json"
template_name => "http-log-logstash"
template_overwrite => true
}
stdout{
codec => rubydebug
}

}没有什么一帆风顺:
问题1:
但是我发现我已经上传了自定义的template,但是就是不能生效。
这时知道了,这个要设置order才能覆盖,默认的order是0,必须更大才行,参考
http://elasticsearch.cn/article/21
问题2:
我看到自己上传的template的order已经是1了,怎么还是不生效呢?
原来自己的索引名称不匹配自己的template的名称,所以不能使用,就又用了默认的template。
改成下面后OK,终于生效了。(注意index名称变化)output{
elasticsearch{
action => "index"
hosts => ["xxx"]
index => "http-log-logstash"
document_type => "haha"
template => "xxx/http-logstash.json"
template_name => "http-log-logstash"
template_overwrite => true
}
stdout{
codec => rubydebug
}

}问题3:
发现导入失败,原来自己的时间字符串不能用默认的date的format匹配,
如2017-04-11 00:07:25   不能用 { "type" : "date"} 的默认format匹配,
改成:"format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"}, 
这样就能解析了。
一切OK,谢谢社区,谢谢Google(你是我见过的除了书籍和老师之后最提升生产力的工具)

附上我的模板
{ 
"template" : "qmpsearchlog",
"order":1,
"settings" : { "index.refresh_interval" : "60s" },
"mappings" : {
"_default_" : {
"_all" : { "enabled" : false },
"dynamic_templates" : [{
"message_field" : {
"match" : "message",
"match_mapping_type" : "string",
"mapping" : { "type" : "string", "index" : "not_analyzed" }
}
}, {
"string_fields" : {
"match" : "*",
"match_mapping_type" : "string",
"mapping" : { "type" : "string", "index" : "not_analyzed" }
}
}],
"properties" : {
"@timestamp" : { "type" : "date"},
"@version" : { "type" : "integer", "index" : "not_analyzed" },
"path" : { "type" : "string", "index" : "not_analyzed" },
"host" : { "type" : "string", "index" : "not_analyzed" },
"record_time":{"type":"date","format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
"method":{"type":"string","index" : "not_analyzed"},
"unionid":{"type":"string","index" : "not_analyzed"},
"user_name":{"type":"string","index" : "not_analyzed"},
"query":{"type":"string","index" : "not_analyzed"},
"ip":{ "type" : "ip"},
"webbrower":{"type":"string","index" : "not_analyzed"},
"os":{"type":"string","index" : "not_analyzed"},
"device":{"type":"string","index" : "not_analyzed"},
"ptype":{"type":"string","index" : "not_analyzed"},
"serarch_time":{"type":"date","format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
"have_ok":{"type":"string","index" : "not_analyzed"},
"legal":{"type":"string","index" : "not_analyzed"}
}
}
}
}



 
继续阅读 »
问题发生背景:

1.本来我是使用logstash的默认配置向ES导入日志的。然后很嗨皮,发现一切OK,后来我开始对日志进行聚合统计,发现terms聚合时的key很奇怪,后来查询这奇怪的key,发现这些关键字都是源字符串的一段,而且全部复现场景都是出现"xxxx-xxxxxx"时就会截断,感觉像是分词器搞的鬼。所以想自己定制mapping。下面是原来的logstash配置
output{
elasticsearch{
action => "index"
hosts => ["xxxxxx:9200"]
index => "xxxxx"
document_type => "haha"
}
}



说干就干:

开始四处查阅文档,发现可以定制mapping,很开心。
output{
elasticsearch{
action => "index"
hosts => ["xxx"]
index => "logstashlog"
template => "xx/http-logstash.json"
template_name => "http-log-logstash"
template_overwrite => true
}
stdout{
codec => rubydebug
}

}没有什么一帆风顺:
问题1:
但是我发现我已经上传了自定义的template,但是就是不能生效。
这时知道了,这个要设置order才能覆盖,默认的order是0,必须更大才行,参考
http://elasticsearch.cn/article/21
问题2:
我看到自己上传的template的order已经是1了,怎么还是不生效呢?
原来自己的索引名称不匹配自己的template的名称,所以不能使用,就又用了默认的template。
改成下面后OK,终于生效了。(注意index名称变化)output{
elasticsearch{
action => "index"
hosts => ["xxx"]
index => "http-log-logstash"
document_type => "haha"
template => "xxx/http-logstash.json"
template_name => "http-log-logstash"
template_overwrite => true
}
stdout{
codec => rubydebug
}

}问题3:
发现导入失败,原来自己的时间字符串不能用默认的date的format匹配,
如2017-04-11 00:07:25   不能用 { "type" : "date"} 的默认format匹配,
改成:"format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"}, 
这样就能解析了。
一切OK,谢谢社区,谢谢Google(你是我见过的除了书籍和老师之后最提升生产力的工具)

附上我的模板
{ 
"template" : "qmpsearchlog",
"order":1,
"settings" : { "index.refresh_interval" : "60s" },
"mappings" : {
"_default_" : {
"_all" : { "enabled" : false },
"dynamic_templates" : [{
"message_field" : {
"match" : "message",
"match_mapping_type" : "string",
"mapping" : { "type" : "string", "index" : "not_analyzed" }
}
}, {
"string_fields" : {
"match" : "*",
"match_mapping_type" : "string",
"mapping" : { "type" : "string", "index" : "not_analyzed" }
}
}],
"properties" : {
"@timestamp" : { "type" : "date"},
"@version" : { "type" : "integer", "index" : "not_analyzed" },
"path" : { "type" : "string", "index" : "not_analyzed" },
"host" : { "type" : "string", "index" : "not_analyzed" },
"record_time":{"type":"date","format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
"method":{"type":"string","index" : "not_analyzed"},
"unionid":{"type":"string","index" : "not_analyzed"},
"user_name":{"type":"string","index" : "not_analyzed"},
"query":{"type":"string","index" : "not_analyzed"},
"ip":{ "type" : "ip"},
"webbrower":{"type":"string","index" : "not_analyzed"},
"os":{"type":"string","index" : "not_analyzed"},
"device":{"type":"string","index" : "not_analyzed"},
"ptype":{"type":"string","index" : "not_analyzed"},
"serarch_time":{"type":"date","format": "yyy-MM-dd HH:mm:ss||yyyy-MM-dd||epoch_millis"},
"have_ok":{"type":"string","index" : "not_analyzed"},
"legal":{"type":"string","index" : "not_analyzed"}
}
}
}
}



  收起阅读 »

logstash多时间(date)字段文档导入

我们都知道如果文档中有表示时间的字段时可以用如下方法将字段转化为date(timestamp)格式导入
date {
match => [ "submission_time", "yyyyMMdd" ]
}
但是如果一条记录中有多个字段需要使用date类型呢?有人遇到了 同样的问题How to parse multiple date fields?其实多次使用date{}语法就行了,例如:
date {
match => [ "submission_time", "UNIX_MS" ]
target => "@timestamp"
}
date {
match => [ "submission_time", "UNIX_MS" ]
target => "submission_time"
}
date {
match => [ "start_time", "UNIX_MS" ]
target => "start_time"
}
date {
match => [ "end_time", "UNIX_MS" ]
target => "end_time"
}
查看官方文档后, 发现一直使用的date是省去了参数target的,而target默认值为@timestamp。
继续阅读 »
我们都知道如果文档中有表示时间的字段时可以用如下方法将字段转化为date(timestamp)格式导入
date {
match => [ "submission_time", "yyyyMMdd" ]
}
但是如果一条记录中有多个字段需要使用date类型呢?有人遇到了 同样的问题How to parse multiple date fields?其实多次使用date{}语法就行了,例如:
date {
match => [ "submission_time", "UNIX_MS" ]
target => "@timestamp"
}
date {
match => [ "submission_time", "UNIX_MS" ]
target => "submission_time"
}
date {
match => [ "start_time", "UNIX_MS" ]
target => "start_time"
}
date {
match => [ "end_time", "UNIX_MS" ]
target => "end_time"
}
查看官方文档后, 发现一直使用的date是省去了参数target的,而target默认值为@timestamp。 收起阅读 »

为什么用java重写logstash


写之前这里先打个广告,java版本的logstash已经开源。git地址:https://github.com/dtstack,下面进入正题。


jlogstash性能:

当时袋鼠云的云日志系统的日志接收端是ruby版本的logstash,存储使用的是elasticsearch,前端的展示没有使用原生的kibana,而是自己写了一套前端。

本人是负责日志接收端的logstash开发人员,主要负责基于ruby版本的logstash编写一些公司业务需要的插件。

当时为了提升性能做了各种优化,比如用java重写了一些模块,再用ruby调用这些模块,比如ip的解析模块,但是最终优化的结果只是单机4core、4g的虚拟机每小时最多能处理800万的数据而已(我们的场景跟大部分人一样都是订阅kafka的消息,再经过一些filter(瓶颈主要是这里比较耗cpu)写入elasticsearch)。

因为logstash的核心代码是用ruby语言开发,虽然运行在jruby上,但是由于中间涉及到数据结构的转化,性能跟原生的class运行在jvm上肯定是有所差距的。

所以当时抱着尽可能最大程度上提升性能,更好地满足用户需求的目的,用java重写了logstash,并把需要用到的插件也进行了重写。在同样的4core、4g虚拟机环境下,每小时能处理4000万数据,性能有了近5倍的提升。


下面是java logstash 和 ruby logstash(2.3.2版本)按照logstash官方测试方案做的性能对比:
 

performance.png



git 地址(https://github.com/DTStack/jlo ... sting) 



以上三种场景的处理效率

java版本logstash性能分别是ruby版本logstash的2.99倍、4.15倍、3.49倍。


jlogstash尽可能保证数据不丢失:

ruby 版本的logstash,对保证数据防丢失这块没做太多的设计。


举个列子:数据从kafka消费再output到elasticsearch,一旦elasticsearch集群不可用,ruby logstash会自动重试几次,如果还不成功就会放弃继续消费kafka里的数据,而且重试的动作也是elasticsearch插件自身来完成的,logstash本身并没有对数据防丢失做设计。


而java 版本logstash 的BaseOutput 这个抽象类里面有个failedMsgQueue队列,每个output实例维护一个,output 插件需要自身判断哪些数据失败了,再调用addFailedMsg方法把失败的数据写入到failedMsgQueue队列里。java logstash一旦发现failedMsgQueue里面有数据就会调用sendFailedMsg这个方法来消费这里的数据,直到数据消费完成才会去消费input里的数据。这个逻辑是可以通过consistency这个属性来控制的。该属性默认是关闭的。

还有一点是input和output插件都提供了release方法,这个主要是为了jvm退出时要执行一些动作而设计的。

因为大部分的input和output插件在获取和发送数据时都会先放在一个集合里面,再去慢慢消耗集合里面的数据。这样jvm退出时,插件就可以各自实现自己的逻辑,从而保证jvm退出前,集合里面的数据彻底消耗完。当然如果你强制杀死该进程(kill -9)那就没法保证了。

现在我们的elasticsearch插件已经实现了数据防丢失逻辑,并且已经在我们的生产环境稳定的跑了很长时间了。


jlogstash可以是分布式应用,而不只是单机应用:

我们这边开发了kafkadistributed插件,通过zookeeper把jlogstash变成分布式应用,因为从客户端采集上来的数据分发到kafka集群中数据是无序的,比如要分析jvm1.8 gc日志,cms的gc日志分成5个步骤,这5个步骤是一个整体,中间有可能夹杂着yonggc的日志,这样数据采集到kafka的时候就会乱序,后端又有多台jlogstash去订阅kafka,这样多台单机版本的jlogstash是没法保证一个完整的cms日志进入到同一个jvm上进行统一分析,所以我们通过zookeeper把jlogstash变成分布式应用,会把同一个文件的日志分发到同一个jlogstash上,这样就能保证cms数据的完整性。

最后希望jlogstash能为一些开发者解决一些问题,也希望有更多的人参与到jlogstash的插件开发里来。

注释:有人问jlogstash跟hangout有什么区别,这里就不做说明了,有兴趣的同学可以看看这两个的源码就知道区别了。






 
继续阅读 »

写之前这里先打个广告,java版本的logstash已经开源。git地址:https://github.com/dtstack,下面进入正题。


jlogstash性能:

当时袋鼠云的云日志系统的日志接收端是ruby版本的logstash,存储使用的是elasticsearch,前端的展示没有使用原生的kibana,而是自己写了一套前端。

本人是负责日志接收端的logstash开发人员,主要负责基于ruby版本的logstash编写一些公司业务需要的插件。

当时为了提升性能做了各种优化,比如用java重写了一些模块,再用ruby调用这些模块,比如ip的解析模块,但是最终优化的结果只是单机4core、4g的虚拟机每小时最多能处理800万的数据而已(我们的场景跟大部分人一样都是订阅kafka的消息,再经过一些filter(瓶颈主要是这里比较耗cpu)写入elasticsearch)。

因为logstash的核心代码是用ruby语言开发,虽然运行在jruby上,但是由于中间涉及到数据结构的转化,性能跟原生的class运行在jvm上肯定是有所差距的。

所以当时抱着尽可能最大程度上提升性能,更好地满足用户需求的目的,用java重写了logstash,并把需要用到的插件也进行了重写。在同样的4core、4g虚拟机环境下,每小时能处理4000万数据,性能有了近5倍的提升。


下面是java logstash 和 ruby logstash(2.3.2版本)按照logstash官方测试方案做的性能对比:
 

performance.png



git 地址(https://github.com/DTStack/jlo ... sting) 



以上三种场景的处理效率

java版本logstash性能分别是ruby版本logstash的2.99倍、4.15倍、3.49倍。


jlogstash尽可能保证数据不丢失:

ruby 版本的logstash,对保证数据防丢失这块没做太多的设计。


举个列子:数据从kafka消费再output到elasticsearch,一旦elasticsearch集群不可用,ruby logstash会自动重试几次,如果还不成功就会放弃继续消费kafka里的数据,而且重试的动作也是elasticsearch插件自身来完成的,logstash本身并没有对数据防丢失做设计。


而java 版本logstash 的BaseOutput 这个抽象类里面有个failedMsgQueue队列,每个output实例维护一个,output 插件需要自身判断哪些数据失败了,再调用addFailedMsg方法把失败的数据写入到failedMsgQueue队列里。java logstash一旦发现failedMsgQueue里面有数据就会调用sendFailedMsg这个方法来消费这里的数据,直到数据消费完成才会去消费input里的数据。这个逻辑是可以通过consistency这个属性来控制的。该属性默认是关闭的。

还有一点是input和output插件都提供了release方法,这个主要是为了jvm退出时要执行一些动作而设计的。

因为大部分的input和output插件在获取和发送数据时都会先放在一个集合里面,再去慢慢消耗集合里面的数据。这样jvm退出时,插件就可以各自实现自己的逻辑,从而保证jvm退出前,集合里面的数据彻底消耗完。当然如果你强制杀死该进程(kill -9)那就没法保证了。

现在我们的elasticsearch插件已经实现了数据防丢失逻辑,并且已经在我们的生产环境稳定的跑了很长时间了。


jlogstash可以是分布式应用,而不只是单机应用:

我们这边开发了kafkadistributed插件,通过zookeeper把jlogstash变成分布式应用,因为从客户端采集上来的数据分发到kafka集群中数据是无序的,比如要分析jvm1.8 gc日志,cms的gc日志分成5个步骤,这5个步骤是一个整体,中间有可能夹杂着yonggc的日志,这样数据采集到kafka的时候就会乱序,后端又有多台jlogstash去订阅kafka,这样多台单机版本的jlogstash是没法保证一个完整的cms日志进入到同一个jvm上进行统一分析,所以我们通过zookeeper把jlogstash变成分布式应用,会把同一个文件的日志分发到同一个jlogstash上,这样就能保证cms数据的完整性。

最后希望jlogstash能为一些开发者解决一些问题,也希望有更多的人参与到jlogstash的插件开发里来。

注释:有人问jlogstash跟hangout有什么区别,这里就不做说明了,有兴趣的同学可以看看这两个的源码就知道区别了。






  收起阅读 »