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






 

Elasticsearch 5.2.2

• 修复request熔断器没有正确处理当前运行请求数的bug，当请求返回前却被客户端关闭时没有对计数减一，会造成节点慢慢的不能处理任何请求，除非重启节点，所有的用户都应该升级 #23317
• 修复cgroup正则解析的bug，造成节点的不能正常启动 #23219
• 被shard锁暂缓执行的请求可能会别其他线程启动，并且该请求丢失了上下文，会造成该请求被当做非法请求而拒绝
• 恢复terms agg的include/exclude参数的支持

 
下载：https://www.elastic.co/downloads/elasticsearch
完整的Release notes：https://www.elastic.co/guide/e ... .html
XPack release notes：https://www.elastic.co/guide/e ... 5.2.2
 
Logstash 5.2.2

• 修复持久化队列在windows启用造成的崩溃
• 修复多实例公用相同的数据目录造成的数据损坏
• 修复JVM性能指标收集造成的吞吐影响

 
下载：https://www.elastic.co/downloads/logstash
Release notes:https://www.elastic.co/guide/e ... .html
 
Kibana 5.2.2

•  之前的版本kibana的visualization依赖一个旧的Elasticsearch的include/exclude特性，但是该功能在Elasticsearch5.2.1被突然移除了，引起了kibana的visualization的错误，现在Kibana对新创建的visualization使用正确的结构，并且能在查询时自动转换遗留的旧结构到新的结构
• 从5.2.0开始，包含sub-bucket的垂直条形图（vertical bar）配置为分组没有合适的缩减y轴，造成相当小甚至某些情况下不可用，这次回归将再次对y轴进行必要的扩展而不管其条形图的模式

 
下载：https://www.elastic.co/downloads/kibana
完整Release notes https://www.elastic.co/guide/e ... .html
 
Beats 5.2.2

• Metricbeat修复当docker容器被kill掉造成的docker 模块挂起的bug
• Metricbeat修复超时时间设置而不是默认值

 
Release notes：https://www.elastic.co/guide/e ... .html
下载：https://www.elastic.co/downloads/beats/

问卷调查直达链接：https://www.surveymonkey.com/r/elastic-china17 
 
同学们，乡亲们：
    想要今年的Elastic线下活动来到您身边么，快参加我们的问卷调查吧，如果您的城市不在下拉列表，记得添加进去，问卷调查比较简单啦，大概只需要花费您几分钟时间，快来吧：https://www.surveymonkey.com/r/elastic-china17 。
 
   另外Elastic也在寻找各个城市的演讲者、场地赞助、协办方、志愿者。如果您有项目用到了任何Elasticsearch、Kibana、Logstash或Beats，并且有兴趣分享您的经验故事（不管是5分钟还是50分钟）请让我们知道，我们非常愿意与我们的社区一起分享您的故事。不管是哪种参与方式都欢迎，请在问卷内留下联系方式或联系我：medcl123（添加注明来意）。

我们感谢您参与本次问卷调查！问题集中在您想参加的线下活动类型，调查结果将被用来使组织者更好地安排活动计划。本调查预计需要花费2 - 5分钟才能完成。我们将与所有参与调查的人分享任何有趣的发现。所有收集的信息将保持匿名。为了鼓励大家花费这一天中的几分钟时间，将随机抽取五个人赢得 $50 美元的亚马逊礼品卡和十五个人将赢得 Elastic Stack 特别版T恤。为了进行抽奖活动，我们会在调查结束时要求您提供电子邮件，但只会用它来让您知道如果您中奖了。

 
除了这个问卷调查，我们在也同时更新了 Elastic 用户组的行为准则（Code of Conduct）。参加我们的活动意味着您同意我们的准则。完整的准则可以访问：https://www.elastic.co/community/codeofconduct。所有的细节可以这个链接页找到。如果您还要其他问题，也欢迎告知我们：） — 我们会一直在这里提供帮助!  :)