写之前这里先打个广告，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官方测试方案做的性能对比：
 




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有什么区别，这里就不做说明了，有兴趣的同学可以看看这两个的源码就知道区别了。