2017 Elastic 官方及社区国内活动日程安排
【线上活动】
在线直播
直播工具Zoom：https://elastic.zoom.us/j/522710614，房间号：522710614（密码进群索取)
- 《Elastic{ON}17 Keynote 回顾》，QQ 群(190605846)，2017-3-17 21:00 PM，回放
- 《What's new in Elasticsearch 5》，QQ 群(190605846)，2017-3-20 21:00 PM，回放
- 《What's new in Logstash 5》，QQ 群(190605846)，2017-3-21 21:00 PM，回放
【线下活动】
Workshop
- Elastic Workshop，北京，2017-04-10【报名结束】
- Elastic Workshop，上海，2017-04-17【报名结束】
- Elastic Workshop，深圳，2017-04-20【报名结束】
- Elastic Workshop，上海，2017-06-29【报名结束】
- Elastic Workshop，广州，2017-07-04【报名结束】
- Elastic Workshop，深圳，2017-07-06【报名结束】
Meetup
- Elastic Meetup Shanghai ，上海，2017.5.14， 【报名结束】【日程】
- Elastic Meetup Beijing ，北京，2017.5.21 【报名结束】【日程】【直播回放】
- Elastic Meetup Nanjing，南京，2017.6.10 【报名结束】【日程】【直播回放】
- Elastic Meetup Hangzhou，杭州，2017.6.25 【报名结束】【日程】【直播回放】
- Elastic Meetup Changsha，长沙，2017.10.28 【报名结束】【日程】
- Elastic Meetup Wuhan，武汉，2017.11.4 【报名结束】【日程】
- Elastic Meetup Guangzhou，广州，2017.11.25 【报名结束】【日程】
- Elastic Meetup Shenzhen，深圳，2017.12.16 【报名结束】【日程】
【会议参展】
Elastic 今年继续赞助和支持各种开发者会议，欢迎届时来展台交流。
- Gopher China，上海，2017.04.15-2017.04.16
- OSC Shanghai ，上海，2017.5.13
- The China-R Conf，北京，2017.5.19-2017.5.21
- OSC Hangzhou，杭州，2017.6.24
- ArchSummit Shenzhen，深圳，2017.7.7-2017.7.8
- OSC Jinan，济南，2017.7.22
- OSC Zhuhai，珠海，2017.8.27
- RubyConf China，杭州，2017.9.16-17
- OSC Chengdu， 成都，2017.9.23
- OSC Chongqing，重庆，2017.9.24
- ArchSummit Beijing，2017.12.8-2017.12.9
上面是暂时确定的活动，部分活动报名链接晚点放出来，请关注本页面。
欢迎各个不同的城市的同学一起帮忙举办线下活动。
各个城市的线下活动欢迎报名分享，大家多交流，话题无论大小。
【线上活动】
在线直播
直播工具Zoom：https://elastic.zoom.us/j/522710614，房间号：522710614（密码进群索取)
- 《Elastic{ON}17 Keynote 回顾》，QQ 群(190605846)，2017-3-17 21:00 PM，回放
- 《What's new in Elasticsearch 5》，QQ 群(190605846)，2017-3-20 21:00 PM，回放
- 《What's new in Logstash 5》，QQ 群(190605846)，2017-3-21 21:00 PM，回放
【线下活动】
Workshop
- Elastic Workshop，北京，2017-04-10【报名结束】
- Elastic Workshop，上海，2017-04-17【报名结束】
- Elastic Workshop，深圳，2017-04-20【报名结束】
- Elastic Workshop，上海，2017-06-29【报名结束】
- Elastic Workshop，广州，2017-07-04【报名结束】
- Elastic Workshop，深圳，2017-07-06【报名结束】
Meetup
- Elastic Meetup Shanghai ，上海，2017.5.14， 【报名结束】【日程】
- Elastic Meetup Beijing ，北京，2017.5.21 【报名结束】【日程】【直播回放】
- Elastic Meetup Nanjing，南京，2017.6.10 【报名结束】【日程】【直播回放】
- Elastic Meetup Hangzhou，杭州，2017.6.25 【报名结束】【日程】【直播回放】
- Elastic Meetup Changsha，长沙，2017.10.28 【报名结束】【日程】
- Elastic Meetup Wuhan，武汉，2017.11.4 【报名结束】【日程】
- Elastic Meetup Guangzhou，广州，2017.11.25 【报名结束】【日程】
- Elastic Meetup Shenzhen，深圳，2017.12.16 【报名结束】【日程】
【会议参展】
Elastic 今年继续赞助和支持各种开发者会议，欢迎届时来展台交流。
- Gopher China，上海，2017.04.15-2017.04.16
- OSC Shanghai ，上海，2017.5.13
- The China-R Conf，北京，2017.5.19-2017.5.21
- OSC Hangzhou，杭州，2017.6.24
- ArchSummit Shenzhen，深圳，2017.7.7-2017.7.8
- OSC Jinan，济南，2017.7.22
- OSC Zhuhai，珠海，2017.8.27
- RubyConf China，杭州，2017.9.16-17
- OSC Chengdu， 成都，2017.9.23
- OSC Chongqing，重庆，2017.9.24
- ArchSummit Beijing，2017.12.8-2017.12.9
上面是暂时确定的活动，部分活动报名链接晚点放出来，请关注本页面。
欢迎各个不同的城市的同学一起帮忙举办线下活动。
各个城市的线下活动欢迎报名分享，大家多交流，话题无论大小。 收起阅读 »
用es的官方工具curator4来配置和管理和优化es索引
刚发在了github,给个链接就好了:
https://vastxiao.github.io/art ... ning/
https://vastxiao.github.io/art ... ning/
刚发在了github,给个链接就好了:
https://vastxiao.github.io/art ... ning/
https://vastxiao.github.io/art ... ning/
Max 发表于 : 2017-03-12 17:18
评论 (0)
Elastic{ON}17 见闻
Elastic 一年一度的用户大会 Elasitc{ON}17 昨日在旧金山举行了，与参人员达到了 2000 多位，这是第三届 Elastic{ON} 了，让我们一起来看看这次大会都要哪些亮点吧。
在进入主题之前，我们先参观看看会场及周边情况吧，这次会场是在旧金山的 48 号码头，和去年的场地很近，不过今年的场地为了容纳的更多的人数，比去年的场地要大很多，码头对面就是著名的AT&T棒球场，看图。
今年多了一个开场的舞蹈，跟别人不一样的事，芭蕾舞蹈演员身上佩戴着若干闪光的传感器，在大背景墙上面可以看到随着演员的舞蹈，有不断变化的各种传感器实时分析的 Kibana 界面，这一切都是实时的哦。
然后就进入 Keynote 了，Elastic 公司 CEO Shay Banon 宣布 Elastic 的产品下载次数达到小目标，已经累计一个亿了。
Elastic 的产品的一个重要原则就是简单，为了让简单的事情变简单，比如采集日志文件，现在的 Filebeat 引入了模块的概念，相应模块直接提供对应成套的配置文件，包括 Mapping、Ingest pipeline、Kibana Dashboard， 启动 filebeat 收集数据进入 es 之后，直接就能可视化分析了。
现在使用 elasticsearch 来做 metric 分析的场景和用户越来越多，而 Kibana 的 Timeseries visual builder 就是为了 metric 场景而产生的一个新的特性，支持非常灵活的自定义可视化，还支持 elasticsearch 的 pipeline aggregation。
接下来就是，Elasticsearch 机器学习了，去年收购的 Perlert，目前已经和 Elasticsearch 无缝集成，现场 demo 演示了通过机器学习模块来分析日志的完整过程，实时的进行异常预测，从众多 service 的日志中找到 root cause。
然后就是 ECE，即 ElasticCloud 的私有云，企业可以很方便的借助它来实现搭建 Elastic 的私有云，集群管理，集群升级都很简单。
然后前 CEO Steven Schuurman 为大家揭晓了今年的第一届 Elastic Cause Awards 获奖的结果，你知道吗，Elasticsearch 正被用于预防埃博拉病毒、拯救人口贩卖以及防止校园暴力等很多有意义的项目中。
然后 Costin Leau 为大家演示了 Elasticsearch-sql，新的和 Elasticsearch 交互的方式，jdbc 兼容，大家期盼已久的功能终于来了，你可以使用现有的支持 jdbc 协议的各种工具来使用 elasticsearch 了，当然不会是完整的 SQL 标准协议，但满足大部分常见的简单的场景。
接下来，Rashid Khan 为大家介绍了与社区相关的一些统计，到最后才跳出来，这些炫酷的 infographic 和 presentation 居然就是在 Kibana 上面，并且这些数据是实时变化的，从而引入了 Kibana 新的功能：Kibana Canvas，借助它，你可以灵活布局设计报表或是 presentation，与后端Elasticsearch数据实时连接，另外与大家通常熟知的静态的 infographic 不同，所有的这些可视化图形都是可以交互操作的，比如过滤与搜索，从此，数据的探索与分析又有了一种新的方式了。
Keynote 的内容主要就到这里了，下午还有很多其他的具体的演讲，都是各个产品的具体的新的特性，回头再补充。
现场还有很多各种类型的 Demo。
想知道 Elastic{ON}17 后续几天还有什么新鲜事么，欢迎关注我的微博：@medcl 和 Elastic 中文社区公众号。
继续阅读 »
在进入主题之前，我们先参观看看会场及周边情况吧，这次会场是在旧金山的 48 号码头，和去年的场地很近，不过今年的场地为了容纳的更多的人数，比去年的场地要大很多，码头对面就是著名的AT&T棒球场，看图。
今年多了一个开场的舞蹈，跟别人不一样的事，芭蕾舞蹈演员身上佩戴着若干闪光的传感器，在大背景墙上面可以看到随着演员的舞蹈，有不断变化的各种传感器实时分析的 Kibana 界面，这一切都是实时的哦。
然后就进入 Keynote 了，Elastic 公司 CEO Shay Banon 宣布 Elastic 的产品下载次数达到小目标，已经累计一个亿了。
Elastic 的产品的一个重要原则就是简单，为了让简单的事情变简单，比如采集日志文件，现在的 Filebeat 引入了模块的概念，相应模块直接提供对应成套的配置文件，包括 Mapping、Ingest pipeline、Kibana Dashboard， 启动 filebeat 收集数据进入 es 之后，直接就能可视化分析了。
现在使用 elasticsearch 来做 metric 分析的场景和用户越来越多，而 Kibana 的 Timeseries visual builder 就是为了 metric 场景而产生的一个新的特性，支持非常灵活的自定义可视化，还支持 elasticsearch 的 pipeline aggregation。
接下来就是，Elasticsearch 机器学习了，去年收购的 Perlert，目前已经和 Elasticsearch 无缝集成，现场 demo 演示了通过机器学习模块来分析日志的完整过程，实时的进行异常预测，从众多 service 的日志中找到 root cause。
然后就是 ECE，即 ElasticCloud 的私有云，企业可以很方便的借助它来实现搭建 Elastic 的私有云，集群管理，集群升级都很简单。
然后前 CEO Steven Schuurman 为大家揭晓了今年的第一届 Elastic Cause Awards 获奖的结果，你知道吗，Elasticsearch 正被用于预防埃博拉病毒、拯救人口贩卖以及防止校园暴力等很多有意义的项目中。
然后 Costin Leau 为大家演示了 Elasticsearch-sql，新的和 Elasticsearch 交互的方式，jdbc 兼容，大家期盼已久的功能终于来了，你可以使用现有的支持 jdbc 协议的各种工具来使用 elasticsearch 了，当然不会是完整的 SQL 标准协议，但满足大部分常见的简单的场景。
接下来，Rashid Khan 为大家介绍了与社区相关的一些统计，到最后才跳出来，这些炫酷的 infographic 和 presentation 居然就是在 Kibana 上面，并且这些数据是实时变化的，从而引入了 Kibana 新的功能：Kibana Canvas，借助它，你可以灵活布局设计报表或是 presentation，与后端Elasticsearch数据实时连接，另外与大家通常熟知的静态的 infographic 不同，所有的这些可视化图形都是可以交互操作的，比如过滤与搜索，从此，数据的探索与分析又有了一种新的方式了。
Keynote 的内容主要就到这里了，下午还有很多其他的具体的演讲，都是各个产品的具体的新的特性，回头再补充。
现场还有很多各种类型的 Demo。
想知道 Elastic{ON}17 后续几天还有什么新鲜事么，欢迎关注我的微博：@medcl 和 Elastic 中文社区公众号。
Elastic 一年一度的用户大会 Elasitc{ON}17 昨日在旧金山举行了，与参人员达到了 2000 多位，这是第三届 Elastic{ON} 了，让我们一起来看看这次大会都要哪些亮点吧。
在进入主题之前，我们先参观看看会场及周边情况吧，这次会场是在旧金山的 48 号码头，和去年的场地很近，不过今年的场地为了容纳的更多的人数，比去年的场地要大很多，码头对面就是著名的AT&T棒球场，看图。
今年多了一个开场的舞蹈，跟别人不一样的事，芭蕾舞蹈演员身上佩戴着若干闪光的传感器，在大背景墙上面可以看到随着演员的舞蹈，有不断变化的各种传感器实时分析的 Kibana 界面，这一切都是实时的哦。
然后就进入 Keynote 了，Elastic 公司 CEO Shay Banon 宣布 Elastic 的产品下载次数达到小目标，已经累计一个亿了。
Elastic 的产品的一个重要原则就是简单，为了让简单的事情变简单，比如采集日志文件，现在的 Filebeat 引入了模块的概念，相应模块直接提供对应成套的配置文件，包括 Mapping、Ingest pipeline、Kibana Dashboard， 启动 filebeat 收集数据进入 es 之后，直接就能可视化分析了。
现在使用 elasticsearch 来做 metric 分析的场景和用户越来越多，而 Kibana 的 Timeseries visual builder 就是为了 metric 场景而产生的一个新的特性，支持非常灵活的自定义可视化，还支持 elasticsearch 的 pipeline aggregation。
接下来就是，Elasticsearch 机器学习了，去年收购的 Perlert，目前已经和 Elasticsearch 无缝集成，现场 demo 演示了通过机器学习模块来分析日志的完整过程，实时的进行异常预测，从众多 service 的日志中找到 root cause。
然后就是 ECE，即 ElasticCloud 的私有云，企业可以很方便的借助它来实现搭建 Elastic 的私有云，集群管理，集群升级都很简单。
然后前 CEO Steven Schuurman 为大家揭晓了今年的第一届 Elastic Cause Awards 获奖的结果，你知道吗，Elasticsearch 正被用于预防埃博拉病毒、拯救人口贩卖以及防止校园暴力等很多有意义的项目中。
然后 Costin Leau 为大家演示了 Elasticsearch-sql，新的和 Elasticsearch 交互的方式，jdbc 兼容，大家期盼已久的功能终于来了，你可以使用现有的支持 jdbc 协议的各种工具来使用 elasticsearch 了，当然不会是完整的 SQL 标准协议，但满足大部分常见的简单的场景。
接下来，Rashid Khan 为大家介绍了与社区相关的一些统计，到最后才跳出来，这些炫酷的 infographic 和 presentation 居然就是在 Kibana 上面，并且这些数据是实时变化的，从而引入了 Kibana 新的功能：Kibana Canvas，借助它，你可以灵活布局设计报表或是 presentation，与后端Elasticsearch数据实时连接，另外与大家通常熟知的静态的 infographic 不同，所有的这些可视化图形都是可以交互操作的，比如过滤与搜索，从此，数据的探索与分析又有了一种新的方式了。
Keynote 的内容主要就到这里了，下午还有很多其他的具体的演讲，都是各个产品的具体的新的特性，回头再补充。
现场还有很多各种类型的 Demo。
想知道 Elastic{ON}17 后续几天还有什么新鲜事么，欢迎关注我的微博：@medcl 和 Elastic 中文社区公众号。
收起阅读 »
在进入主题之前，我们先参观看看会场及周边情况吧，这次会场是在旧金山的 48 号码头，和去年的场地很近，不过今年的场地为了容纳的更多的人数，比去年的场地要大很多，码头对面就是著名的AT&T棒球场，看图。
今年多了一个开场的舞蹈，跟别人不一样的事，芭蕾舞蹈演员身上佩戴着若干闪光的传感器，在大背景墙上面可以看到随着演员的舞蹈，有不断变化的各种传感器实时分析的 Kibana 界面，这一切都是实时的哦。
然后就进入 Keynote 了，Elastic 公司 CEO Shay Banon 宣布 Elastic 的产品下载次数达到小目标，已经累计一个亿了。
Elastic 的产品的一个重要原则就是简单，为了让简单的事情变简单，比如采集日志文件，现在的 Filebeat 引入了模块的概念，相应模块直接提供对应成套的配置文件，包括 Mapping、Ingest pipeline、Kibana Dashboard， 启动 filebeat 收集数据进入 es 之后，直接就能可视化分析了。
现在使用 elasticsearch 来做 metric 分析的场景和用户越来越多，而 Kibana 的 Timeseries visual builder 就是为了 metric 场景而产生的一个新的特性，支持非常灵活的自定义可视化，还支持 elasticsearch 的 pipeline aggregation。
接下来就是，Elasticsearch 机器学习了，去年收购的 Perlert，目前已经和 Elasticsearch 无缝集成，现场 demo 演示了通过机器学习模块来分析日志的完整过程，实时的进行异常预测，从众多 service 的日志中找到 root cause。
然后就是 ECE，即 ElasticCloud 的私有云，企业可以很方便的借助它来实现搭建 Elastic 的私有云，集群管理，集群升级都很简单。
然后前 CEO Steven Schuurman 为大家揭晓了今年的第一届 Elastic Cause Awards 获奖的结果，你知道吗，Elasticsearch 正被用于预防埃博拉病毒、拯救人口贩卖以及防止校园暴力等很多有意义的项目中。
然后 Costin Leau 为大家演示了 Elasticsearch-sql，新的和 Elasticsearch 交互的方式，jdbc 兼容，大家期盼已久的功能终于来了，你可以使用现有的支持 jdbc 协议的各种工具来使用 elasticsearch 了，当然不会是完整的 SQL 标准协议，但满足大部分常见的简单的场景。
接下来，Rashid Khan 为大家介绍了与社区相关的一些统计，到最后才跳出来，这些炫酷的 infographic 和 presentation 居然就是在 Kibana 上面，并且这些数据是实时变化的，从而引入了 Kibana 新的功能：Kibana Canvas，借助它，你可以灵活布局设计报表或是 presentation，与后端Elasticsearch数据实时连接，另外与大家通常熟知的静态的 infographic 不同，所有的这些可视化图形都是可以交互操作的，比如过滤与搜索，从此，数据的探索与分析又有了一种新的方式了。
Keynote 的内容主要就到这里了，下午还有很多其他的具体的演讲，都是各个产品的具体的新的特性，回头再补充。
现场还有很多各种类型的 Demo。
想知道 Elastic{ON}17 后续几天还有什么新鲜事么，欢迎关注我的微博：@medcl 和 Elastic 中文社区公众号。
收起阅读 »
medcl 发表于 : 2017-03-09 02:06
评论 (2)
使用 Elastic Stack 来监控和调优 Golang 应用程序
Golang 因为其语法简单，上手快且方便部署正被越来越多的开发者所青睐，一个 Golang 程序开发好了之后，势必要关心其运行情况，今天在这里就给大家介绍一下如果使用 Elastic Stack 来分析 Golang 程序的内存使用情况，方便对 Golang 程序做长期监控进而调优和诊断，甚至发现一些潜在的内存泄露等问题。
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：
OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.yml
现在启动 Metricbeat：
关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：
首先，启动的时候带上参数设置pprof监控的地址，如下：
现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：
重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：
从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。
继续阅读 »
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
- Apache Module
- Couchbase Module
- Docker Module
- HAProxy Module
- kafka Module
- MongoDB Module
- MySQL Module
- Nginx Module
- PostgreSQL Module
- Prometheus Module
- Redis Module
- System Module
- ZooKeeper Module
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：
import _ "expvar"func metricsHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
first := true
report := func(key string, value interface{}) {
if !first {
fmt.Fprintf(w, ",\n")
}
first = false
if str, ok := value.(string); ok {
fmt.Fprintf(w, "%q: %q", key, str)
} else {
fmt.Fprintf(w, "%q: %v", key, value)
}
}
fmt.Fprintf(w, "{\n")
expvar.Do(func(kv expvar.KeyValue) {
report(kv.Key, kv.Value)
})
fmt.Fprintf(w, "\n}\n")
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/debug/vars", metricsHandler)
endpoint := http.ListenAndServe("localhost:6060", mux)
}OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.yml
metricbeat.modules:
- module: golang
metricsets: ["heap"]
enabled: true
period: 10s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"output.elasticsearch:
hosts: ["localhost:9200"]现在启动 Metricbeat：
./metricbeat -e -v关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：
var inerInt int64 = 1024
pubInt := expvar.NewInt("your_metric_key")
pubInt.Set(inerInt)
pubInt.Add(2)首先，启动的时候带上参数设置pprof监控的地址，如下：
./metricbeat -httpprof="127.0.0.1:6060" -e -v{
"output.events.acked": 1088,
"output.write.bytes": 1027455,
"output.write.errors": 0,
"output.messages.dropped": 0,
"output.elasticsearch.publishEvents.call.count": 24,
"output.elasticsearch.read.bytes": 12215,
"output.elasticsearch.read.errors": 0,
"output.elasticsearch.write.bytes": 1027455,
"output.elasticsearch.write.errors": 0,
"output.elasticsearch.events.acked": 1088,
"output.elasticsearch.events.not_acked": 0,
"output.kafka.events.acked": 0,
"output.kafka.events.not_acked": 0,
"output.kafka.publishEvents.call.count": 0,
"output.logstash.write.errors": 0,
"output.logstash.write.bytes": 0,
"output.logstash.events.acked": 0,
"output.logstash.events.not_acked": 0,
"output.logstash.publishEvents.call.count": 0,
"output.logstash.read.bytes": 0,
"output.logstash.read.errors": 0,
"output.redis.events.acked": 0,
"output.redis.events.not_acked": 0,
"output.redis.read.bytes": 0,
"output.redis.read.errors": 0,
"output.redis.write.bytes": 0,
"output.redis.write.errors": 0,
"beat.memstats.memory_total": 155721720,
"beat.memstats.memory_alloc": 3632728,
"beat.memstats.gc_next": 6052800,
"cmdline": ["./metricbeat","-httpprof=127.0.0.1:6060","-e","-v"],
"fetches": {"system-cpu": {"events": 4, "failures": 0, "success": 4}, "system-filesystem": {"events": 20, "failures": 0, "success": 4}, "system-fsstat": {"events": 4, "failures": 0, "success": 4}, "system-load": {"events": 4, "failures": 0, "success": 4}, "system-memory": {"events": 4, "failures": 0, "success": 4}, "system-network": {"events": 44, "failures": 0, "success": 4}, "system-process": {"events": 1008, "failures": 0, "success": 4}},
"libbeat.config.module.running": 0,
"libbeat.config.module.starts": 0,
"libbeat.config.module.stops": 0,
"libbeat.config.reloads": 0,
"memstats": {"Alloc":3637704,"TotalAlloc":155
... ...现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：
- module: golang
metricsets: ["heap","expvar"]
enabled: true
period: 1s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"
expvar:
namespace: "metricbeat"
path: "/debug/vars"重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：
.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.acked").derivative().label("Elasticsearch Success"),.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.not_acked").derivative().label("Elasticsearch Failed")从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。
Golang 因为其语法简单，上手快且方便部署正被越来越多的开发者所青睐，一个 Golang 程序开发好了之后，势必要关心其运行情况，今天在这里就给大家介绍一下如果使用 Elastic Stack 来分析 Golang 程序的内存使用情况，方便对 Golang 程序做长期监控进而调优和诊断，甚至发现一些潜在的内存泄露等问题。
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：
OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.yml
现在启动 Metricbeat：
关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：
首先，启动的时候带上参数设置pprof监控的地址，如下：
现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：
重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：
从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。 收起阅读 »
Elastic Stack 其实是一个集合，包含 Elasticsearch、Logstash 和 Beats 这几个开源软件，而 Beats 又包含 Filebeat、Packetbeat、Winlogbeat、Metricbeat 和新出的 Heartbeat，呵呵，有点多吧，恩，每个 beat 做的事情不一样，没关系，今天主要用到 Elasticsearch、Metricbeat 和 Kibana 就行了。
Metricbeat 是一个专门用来获取服务器或应用服务内部运行指标数据的收集程序，也是 Golang 写的，部署包比较小才10M 左右，对目标服务器的部署环境也没有依赖，内存资源占用和 CPU 开销也较小，目前除了可以监控服务器本身的资源使用情况外，还支持常见的应用服务器和服务，目前支持列表如下：
- Apache Module
- Couchbase Module
- Docker Module
- HAProxy Module
- kafka Module
- MongoDB Module
- MySQL Module
- Nginx Module
- PostgreSQL Module
- Prometheus Module
- Redis Module
- System Module
- ZooKeeper Module
当然，也有可能你的应用不在上述列表，没关系，Metricbeat 是可以扩展的，你可以很方便的实现一个模块，而本文接下来所用的 Golang Module 也就是我刚刚为 Metricbeat 添加的扩展模块，目前已经 merge 进入 Metricbeat 的 master 分支，预计会在 6.0 版本发布，想了解是如何扩展这个模块的可以查看 代码路径 和 PR地址。
上面的这些可能还不够吸引人，我们来看一下 Kibana 对 Metricbeat 使用 Golang 模块收集的数据进行的可视化分析吧：
上面的图简单解读一下:
最上面一栏是 Golang Heap 的摘要信息，可以大致了解 Golang 的内存使用和 GC 情况，System 表示 Golang 程序从操作系统申请的内存，可以理解为进程所占的内存（注意不是进程对应的虚拟内存），Bytes allocated 表示 Heap 目前分配的内存，也就是 Golang 里面直接可使用的内存，GC limit 表示当 Golang 的 Heap 内存分配达到这个 limit 值之后就会开始执行 GC，这个值会随着每次 GC 而变化， GC cycles 则代表监控周期内的 GC 次数；
中间的三列分别是堆内存、进程内存和对象的统计情况；Heap Allocated 表示正在用和没有用但还未被回收的对象的大小；Heap Inuse 显然就是活跃的对象大小了；Heap Idle 表示已分配但空闲的内存；
底下两列是 GC 时间和 GC 次数的监控统计，CPUFraction 这个代表该进程 CPU 占用时间花在 GC 上面的百分比，值越大说明 GC 越频繁，浪费更多的时间在 GC 上面，上图虽然趋势陡峭，但是看范围在0.41%~0.52%之间，看起来还算可以，如果GC 比率占到个位数甚至更多比例，那肯定需要进一步优化程序了。
有了这些信息我们就能够知道该 Golang 的内存使用和分配情况和 GC 的执行情况，假如要分析是否有内存泄露，看内存使用和堆内存分配的趋势是否平稳就可以了，另外 GC_Limit 和 Byte Allocation 一直上升，那肯定就是有内存泄露了，结合历史信息还能对不同版本/提交对 Golang 的内存使用和 GC 影响进行分析。
接下来就要给大家介绍如何具体使用了，首先需要启用 Golang 的 expvar 服务，expvar（https://golang.org/pkg/expvar/） 是 Golang 提供的一个暴露内部变量或统计信息的标准包。
使用的方法很简单，只需要在 Golang 的程序引入该包即可，它会自动注册现有的 http 服务上，如下：
import _ "expvar"func metricsHandler(w http.ResponseWriter, r *http.Request) {
w.Header().Set("Content-Type", "application/json; charset=utf-8")
first := true
report := func(key string, value interface{}) {
if !first {
fmt.Fprintf(w, ",\n")
}
first = false
if str, ok := value.(string); ok {
fmt.Fprintf(w, "%q: %q", key, str)
} else {
fmt.Fprintf(w, "%q: %v", key, value)
}
}
fmt.Fprintf(w, "{\n")
expvar.Do(func(kv expvar.KeyValue) {
report(kv.Key, kv.Value)
})
fmt.Fprintf(w, "\n}\n")
}
func main() {
mux := http.NewServeMux()
mux.HandleFunc("/debug/vars", metricsHandler)
endpoint := http.ListenAndServe("localhost:6060", mux)
}OK，现在我们的 Golang 程序已经启动了，并且通过 expvar 暴露出了运行时的内存使用情况，现在我们需要使用 Metricbeat 来获取这些信息并存进 Elasticsearch。
关于 Metricbeat 的安装其实很简单，下载对应平台的包解压（下载地址：https://www.elastic.co/downloads/beats/metricbeat ），启动 Metricbeat 前，修改配置文件：metricbeat.yml
metricbeat.modules:
- module: golang
metricsets: ["heap"]
enabled: true
period: 10s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"output.elasticsearch:
hosts: ["localhost:9200"]现在启动 Metricbeat：
./metricbeat -e -v关于如何导入样例仪表板请参照这个文档：https://www.elastic.co/guide/e ... .html
除了监控已经有的内存信息之外，如果你还有一些内部的业务指标想要暴露出来，也是可以的，通过 expvar 来做同样可以。一个简单的例子如下：
var inerInt int64 = 1024
pubInt := expvar.NewInt("your_metric_key")
pubInt.Set(inerInt)
pubInt.Add(2)首先，启动的时候带上参数设置pprof监控的地址，如下：
./metricbeat -httpprof="127.0.0.1:6060" -e -v{
"output.events.acked": 1088,
"output.write.bytes": 1027455,
"output.write.errors": 0,
"output.messages.dropped": 0,
"output.elasticsearch.publishEvents.call.count": 24,
"output.elasticsearch.read.bytes": 12215,
"output.elasticsearch.read.errors": 0,
"output.elasticsearch.write.bytes": 1027455,
"output.elasticsearch.write.errors": 0,
"output.elasticsearch.events.acked": 1088,
"output.elasticsearch.events.not_acked": 0,
"output.kafka.events.acked": 0,
"output.kafka.events.not_acked": 0,
"output.kafka.publishEvents.call.count": 0,
"output.logstash.write.errors": 0,
"output.logstash.write.bytes": 0,
"output.logstash.events.acked": 0,
"output.logstash.events.not_acked": 0,
"output.logstash.publishEvents.call.count": 0,
"output.logstash.read.bytes": 0,
"output.logstash.read.errors": 0,
"output.redis.events.acked": 0,
"output.redis.events.not_acked": 0,
"output.redis.read.bytes": 0,
"output.redis.read.errors": 0,
"output.redis.write.bytes": 0,
"output.redis.write.errors": 0,
"beat.memstats.memory_total": 155721720,
"beat.memstats.memory_alloc": 3632728,
"beat.memstats.gc_next": 6052800,
"cmdline": ["./metricbeat","-httpprof=127.0.0.1:6060","-e","-v"],
"fetches": {"system-cpu": {"events": 4, "failures": 0, "success": 4}, "system-filesystem": {"events": 20, "failures": 0, "success": 4}, "system-fsstat": {"events": 4, "failures": 0, "success": 4}, "system-load": {"events": 4, "failures": 0, "success": 4}, "system-memory": {"events": 4, "failures": 0, "success": 4}, "system-network": {"events": 44, "failures": 0, "success": 4}, "system-process": {"events": 1008, "failures": 0, "success": 4}},
"libbeat.config.module.running": 0,
"libbeat.config.module.starts": 0,
"libbeat.config.module.stops": 0,
"libbeat.config.reloads": 0,
"memstats": {"Alloc":3637704,"TotalAlloc":155
... ...现在我们要修改 Metricbeat 的配置文件，Golang 模块有两个 metricset，可以理解为两个监控的指标类型，我们现在需要加入一个新的 expvar 类型，这个即自定义的其他指标，相应配置文件修改如下：
- module: golang
metricsets: ["heap","expvar"]
enabled: true
period: 1s
hosts: ["localhost:6060"]
heap.path: "/debug/vars"
expvar:
namespace: "metricbeat"
path: "/debug/vars"重启 Metricbeat 应该就能收到新的数据了，我们前往 Kibana。
这里假设关注 output.elasticsearch.events.acked和
output.elasticsearch.events.not_acked这两个指标，我们在Kibana里面简单定义一个曲线图就能看到 Metricbeat 发往 Elasticsearch 消息的成功和失败趋势。
Timelion 表达式：
.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.acked").derivative().label("Elasticsearch Success"),.es("metricbeat*",metric="max:golang.metricbeat.output.elasticsearch.events.not_acked").derivative().label("Elasticsearch Failed")从上图可以看到，发往 Elasticsearch 的消息很稳定，没有出现丢消息的情况，同时关于 Metricbeat 的内存情况，我们打开导入的 Dashboard 查看:
关于如何使用 Metricbeat 来监控 Golang 应用程序的内容基本上就差不多到这里了，上面介绍了如何基于 expvar 来监控 Golang 的内存情况和自定义业务监控指标，在结合 Elastic Stack 可以快速的进行分析，希望对大家有用。
最后，这个 Golang 模块目前还没 release，估计在 beats 6.0 发布，有兴趣尝鲜的可以自己下载源码打包。 收起阅读 »
medcl 发表于 : 2017-03-03 11:16
评论 (0)
为什么用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官方测试方案做的性能对比：
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官方测试方案做的性能对比：
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有什么区别，这里就不做说明了，有兴趣的同学可以看看这两个的源码就知道区别了。
收起阅读 »
whiletrue 发表于 : 2017-03-01 15:15
评论 (8)
Elastic Stack 5.2.2 发布
Elasticsearch 5.2.2
下载：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
下载：https://www.elastic.co/downloads/logstash
Release notes:https://www.elastic.co/guide/e ... .html
Kibana 5.2.2
下载：https://www.elastic.co/downloads/kibana
完整Release notes https://www.elastic.co/guide/e ... .html
Beats 5.2.2
Release notes：https://www.elastic.co/guide/e ... .html
下载：https://www.elastic.co/downloads/beats/
继续阅读 »
- 修复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/
Elasticsearch 5.2.2
下载：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
下载：https://www.elastic.co/downloads/logstash
Release notes:https://www.elastic.co/guide/e ... .html
Kibana 5.2.2
下载：https://www.elastic.co/downloads/kibana
完整Release notes https://www.elastic.co/guide/e ... .html
Beats 5.2.2
Release notes：https://www.elastic.co/guide/e ... .html
下载：https://www.elastic.co/downloads/beats/ 收起阅读 »
- 修复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/ 收起阅读 »
medcl 发表于 : 2017-03-01 10:37
评论 (5)
欢迎参加Elastic的Meetup线下活动问卷调查
问卷调查直达链接：https://www.surveymonkey.com/r/elastic-china17
同学们，乡亲们：
想要今年的Elastic线下活动来到您身边么，快参加我们的问卷调查吧，如果您的城市不在下拉列表，记得添加进去，问卷调查比较简单啦，大概只需要花费您几分钟时间，快来吧：https://www.surveymonkey.com/r/elastic-china17 。
另外Elastic也在寻找各个城市的演讲者、场地赞助、协办方、志愿者。如果您有项目用到了任何Elasticsearch、Kibana、Logstash或Beats，并且有兴趣分享您的经验故事（不管是5分钟还是50分钟）请让我们知道，我们非常愿意与我们的社区一起分享您的故事。不管是哪种参与方式都欢迎，请在问卷内留下联系方式或联系我：medcl123（添加注明来意）。
除了这个问卷调查，我们在也同时更新了 Elastic 用户组的行为准则（Code of Conduct）。参加我们的活动意味着您同意我们的准则。完整的准则可以访问：https://www.elastic.co/community/codeofconduct。所有的细节可以这个链接页找到。如果您还要其他问题，也欢迎告知我们：） — 我们会一直在这里提供帮助! :)
继续阅读 »
同学们，乡亲们：
想要今年的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。所有的细节可以这个链接页找到。如果您还要其他问题，也欢迎告知我们：） — 我们会一直在这里提供帮助! :)
问卷调查直达链接：https://www.surveymonkey.com/r/elastic-china17
同学们，乡亲们：
想要今年的Elastic线下活动来到您身边么，快参加我们的问卷调查吧，如果您的城市不在下拉列表，记得添加进去，问卷调查比较简单啦，大概只需要花费您几分钟时间，快来吧：https://www.surveymonkey.com/r/elastic-china17 。
另外Elastic也在寻找各个城市的演讲者、场地赞助、协办方、志愿者。如果您有项目用到了任何Elasticsearch、Kibana、Logstash或Beats，并且有兴趣分享您的经验故事（不管是5分钟还是50分钟）请让我们知道，我们非常愿意与我们的社区一起分享您的故事。不管是哪种参与方式都欢迎，请在问卷内留下联系方式或联系我：medcl123（添加注明来意）。
除了这个问卷调查，我们在也同时更新了 Elastic 用户组的行为准则（Code of Conduct）。参加我们的活动意味着您同意我们的准则。完整的准则可以访问：https://www.elastic.co/community/codeofconduct。所有的细节可以这个链接页找到。如果您还要其他问题，也欢迎告知我们：） — 我们会一直在这里提供帮助! :)
收起阅读 »
同学们，乡亲们：
想要今年的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。所有的细节可以这个链接页找到。如果您还要其他问题，也欢迎告知我们：） — 我们会一直在这里提供帮助! :)
Elastic Stack 5.2.1 发布
Elasticsearch 5.2.1 发布内容
基于 Lucene 6.4.1，所有5.2.0 用户都应该升级到该版本，修正了很多 bug，尤其了 Lucene6.4.1修复了两个重要的内存泄漏：
功能废弃：
改进增强：
Bug 修复：
其他细节详见 Release notes。
Download Elasticsearch 5.2.1
X-Pack 5.2.1 release notes
Kibana 5.2.1 发布内容：
在该版本中主要包括了一些重要的 bug 修复，包含一个安全风险的 fix 以及可能造成 kibana 崩溃的问题。
在5.0早期的版本中，如果配置了 SSL，特定的请求会造成 Kibana 无法释放文件打开句柄，这会造成进程随着时间推移的崩溃。请求在发生数据之前被取消也会造成进程的崩溃。还有一个安全的风险：ESA-2017-02（Http 头信息可能泄露敏感信息的问题，注：Kibana4不受影响）。
其他详见：Release notes
Download Kibana 5.2.1
Beats,Logstash 发布内容见：
https://www.elastic.co/guide/e ... .html
https://www.elastic.co/guide/e ... .html
继续阅读 »
基于 Lucene 6.4.1，所有5.2.0 用户都应该升级到该版本，修正了很多 bug，尤其了 Lucene6.4.1修复了两个重要的内存泄漏：
- 当存储字段配置为“best_compression",我们依赖于 JVM 回收机制来释放解压缩实例（Deflater/Inflater instances）。然而这些类也行只使用了很少的 JVM 堆栈内存，却使用了大量了本地内存，所以可能 会出现在 JVM 回收解压缩实例之前而操作系统先用完了本地内存。 LUCENE-7647。
- 特定的查询可能会持有 IndexReader 的一个引用，当这些查询被缓存之后，本来应该已经被删除的段会因为这个引用而继续被 Lucene 持有。LUCENE-7657。
功能废弃：
- Geo distance range 废弃，请使用`geo_distance` bucket aggregation 或 geo_distance sort来替代。#22835。
改进增强：
- 分配解释 API（allocation explaining）在未分配主分片信息中包含陈旧的副本信息（不管是陈旧还是损坏的）#22826。
Bug 修复：
- 如果查询超时，将缓存结果置为无效。#22807。
- Reindex 接口支持来源 es 版本<2.0，当不能清除旧的 scroll 不记录日志。
- 将参数：search.highlight.term_vector_multi_value 保留为节点级别。
其他细节详见 Release notes。
Download Elasticsearch 5.2.1
X-Pack 5.2.1 release notes
Kibana 5.2.1 发布内容：
在该版本中主要包括了一些重要的 bug 修复，包含一个安全风险的 fix 以及可能造成 kibana 崩溃的问题。
在5.0早期的版本中，如果配置了 SSL，特定的请求会造成 Kibana 无法释放文件打开句柄，这会造成进程随着时间推移的崩溃。请求在发生数据之前被取消也会造成进程的崩溃。还有一个安全的风险：ESA-2017-02（Http 头信息可能泄露敏感信息的问题，注：Kibana4不受影响）。
其他详见：Release notes
Download Kibana 5.2.1
Beats,Logstash 发布内容见：
https://www.elastic.co/guide/e ... .html
https://www.elastic.co/guide/e ... .html
Elasticsearch 5.2.1 发布内容
基于 Lucene 6.4.1，所有5.2.0 用户都应该升级到该版本，修正了很多 bug，尤其了 Lucene6.4.1修复了两个重要的内存泄漏：
功能废弃：
改进增强：
Bug 修复：
其他细节详见 Release notes。
Download Elasticsearch 5.2.1
X-Pack 5.2.1 release notes
Kibana 5.2.1 发布内容：
在该版本中主要包括了一些重要的 bug 修复，包含一个安全风险的 fix 以及可能造成 kibana 崩溃的问题。
在5.0早期的版本中，如果配置了 SSL，特定的请求会造成 Kibana 无法释放文件打开句柄，这会造成进程随着时间推移的崩溃。请求在发生数据之前被取消也会造成进程的崩溃。还有一个安全的风险：ESA-2017-02（Http 头信息可能泄露敏感信息的问题，注：Kibana4不受影响）。
其他详见：Release notes
Download Kibana 5.2.1
Beats,Logstash 发布内容见：
https://www.elastic.co/guide/e ... .html
https://www.elastic.co/guide/e ... .html
收起阅读 »
基于 Lucene 6.4.1，所有5.2.0 用户都应该升级到该版本，修正了很多 bug，尤其了 Lucene6.4.1修复了两个重要的内存泄漏：
- 当存储字段配置为“best_compression",我们依赖于 JVM 回收机制来释放解压缩实例（Deflater/Inflater instances）。然而这些类也行只使用了很少的 JVM 堆栈内存，却使用了大量了本地内存，所以可能 会出现在 JVM 回收解压缩实例之前而操作系统先用完了本地内存。 LUCENE-7647。
- 特定的查询可能会持有 IndexReader 的一个引用，当这些查询被缓存之后，本来应该已经被删除的段会因为这个引用而继续被 Lucene 持有。LUCENE-7657。
功能废弃：
- Geo distance range 废弃，请使用`geo_distance` bucket aggregation 或 geo_distance sort来替代。#22835。
改进增强：
- 分配解释 API（allocation explaining）在未分配主分片信息中包含陈旧的副本信息（不管是陈旧还是损坏的）#22826。
Bug 修复：
- 如果查询超时，将缓存结果置为无效。#22807。
- Reindex 接口支持来源 es 版本<2.0，当不能清除旧的 scroll 不记录日志。
- 将参数：search.highlight.term_vector_multi_value 保留为节点级别。
其他细节详见 Release notes。
Download Elasticsearch 5.2.1
X-Pack 5.2.1 release notes
Kibana 5.2.1 发布内容：
在该版本中主要包括了一些重要的 bug 修复，包含一个安全风险的 fix 以及可能造成 kibana 崩溃的问题。
在5.0早期的版本中，如果配置了 SSL，特定的请求会造成 Kibana 无法释放文件打开句柄，这会造成进程随着时间推移的崩溃。请求在发生数据之前被取消也会造成进程的崩溃。还有一个安全的风险：ESA-2017-02（Http 头信息可能泄露敏感信息的问题，注：Kibana4不受影响）。
其他详见：Release notes
Download Kibana 5.2.1
Beats,Logstash 发布内容见：
https://www.elastic.co/guide/e ... .html
https://www.elastic.co/guide/e ... .html
收起阅读 »
medcl 发表于 : 2017-02-15 14:07
评论 (4)
Elasticsearch 5.x 字段折叠的使用
在 Elasticsearch 5.x 有一个字段折叠（Field Collapsing，#22337）的功能非常有意思，在这里分享一下，
字段折叠是一个很有历史的需求了，可以看这个 issue，编号#256，最初是2010年7月提的issue，也是讨论最多的帖子之一（240+评论），熬了6年才支持的特性，你说牛不牛，哈哈。
目测该特性将于5.3发布，尝鲜地址：Elasticsearch-5.3.0-SNAPSHOT，文档地址：search-request-collapse。
So，什么是字段折叠，可以理解就是按特定字段进行合并去重，比如我们有一个菜谱搜索，我希望按菜谱的“菜系”字段进行折叠，即返回结果每个菜系都返回一个结果，也就是按菜系去重，我搜索关键字“鱼”，要去返回的结果里面各种菜系都有，有湘菜，有粤菜，有中餐，有西餐，别全是湘菜，就是这个意思，通过按特定字段折叠之后，来丰富搜索结果的多样性。
说到这里，有人肯定会想到，使用 term agg+ top hits agg 来实现啊，这种组合两种聚和的方式可以实现上面的功能，不过也有一些局限性，比如，不能分页，#4915；结果不够精确（top term+top hits，es 的聚合实现选择了牺牲精度来提高速度）；数据量大的情况下，聚合比较慢，影响搜索体验。
而新的的字段折叠的方式是怎么实现的的呢，有这些要点：
- 折叠+取 inner_hits 分两阶段执行（组合聚合的方式只有一个阶段），所以 top hits 永远是精确的。
- 字段折叠只在 top hits 层执行，不需要每次都在完整的结果集上对为每个折叠主键计算实际的 doc values 值，只对 top hits 这小部分数据操作就可以，和 term agg 相比要节省很多内存。
- 因为只在 top hits 上进行折叠，所以相比组合聚合的方式，速度要快很多。
- 折叠 top docs 不需要使用全局序列（global ordinals）来转换 string，相比 agg 这也节省了很多内存。
- 分页成为可能，和常规搜索一样，具有相同的局限，先获取 from+size 的内容，再合并。
- search_after 和 scroll 暂未实现，不过具备可行性。
- 折叠只影响搜索结果，不影响聚合，搜索结果的 total 是所有的命中纪录数，去重的结果数未知（无法计算）。
下面来看看具体的例子，就知道怎么回事了，使用起来很简单。
- 先准备索引和数据，这里以菜谱为例，name：菜谱名，type 为菜系，rating 为用户的累积平均评分
DELETE recipes
PUT recipes
POST recipes/type/_mapping
{
"properties": {
"name":{
"type": "text"
},
"rating":{
"type": "float"
},"type":{
"type": "keyword"
}
}
}
POST recipes/type/
{
"name":"清蒸鱼头","rating":1,"type":"湘菜"
}
POST recipes/type/
{
"name":"剁椒鱼头","rating":2,"type":"湘菜"
}
POST recipes/type/
{
"name":"红烧鲫鱼","rating":3,"type":"湘菜"
}
POST recipes/type/
{
"name":"鲫鱼汤（辣）","rating":3,"type":"湘菜"
}
POST recipes/type/
{
"name":"鲫鱼汤（微辣）","rating":4,"type":"湘菜"
}
POST recipes/type/
{
"name":"鲫鱼汤（变态辣）","rating":5,"type":"湘菜"
}
POST recipes/type/
{
"name":"广式鲫鱼汤","rating":5,"type":"粤菜"
}
POST recipes/type/
{
"name":"鱼香肉丝","rating":2,"type":"川菜"
}
POST recipes/type/
{
"name":"奶油鲍鱼汤","rating":2,"type":"西菜"
} - 现在我们看看普通的查询效果是怎么样的，搜索关键字带“鱼”的菜，返回3条数据
POST recipes/type/_search
{
"query": {"match": {
"name": "鱼"
}},"size": 3
} {
"took": 2,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": 0.26742277,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYF_OA-dG63Txsd",
"_score": 0.26742277,
"_source": {
"name": "鲫鱼汤（变态辣）",
"rating": 5,
"type": "湘菜"
}
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHXO_OA-dG63Txsa",
"_score": 0.19100356,
"_source": {
"name": "红烧鲫鱼",
"rating": 3,
"type": "湘菜"
}
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHWy_OA-dG63TxsZ",
"_score": 0.19100356,
"_source": {
"name": "剁椒鱼头",
"rating": 2,
"type": "湘菜"
}
}
]
}
}POST recipes/type/_search
{
"query": {"match": {
"name": "鱼"
}},"sort": [
{
"rating": {
"order": "desc"
}
}
],"size": 3
} {
"took": 1,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYF_OA-dG63Txsd",
"_score": null,
"_source": {
"name": "鲫鱼汤（变态辣）",
"rating": 5,
"type": "湘菜"
},
"sort": [
5
]
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYW_OA-dG63Txse",
"_score": null,
"_source": {
"name": "广式鲫鱼汤",
"rating": 5,
"type": "粤菜"
},
"sort": [
5
]
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHX7_OA-dG63Txsc",
"_score": null,
"_source": {
"name": "鲫鱼汤（微辣）",
"rating": 4,
"type": "湘菜"
},
"sort": [
4
]
}
]
}
}
GET recipes/type/_search
{
"query": {
"match": {
"name": "鱼"
}
},
"sort": [
{
"rating": {
"order": "desc"
}
}
],"aggs": {
"type": {
"terms": {
"field": "type",
"size": 10
},"aggs": {
"rated": {
"top_hits": {
"sort": [{
"rating": {"order": "desc"}
}],
"size": 1
}
}
}
}
},
"size": 0,
"from": 0
} {
"took": 4,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": 0,
"hits": []
},
"aggregations": {
"type": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "湘菜",
"doc_count": 6,
"rated": {
"hits": {
"total": 6,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYF_OA-dG63Txsd",
"_score": null,
"_source": {
"name": "鲫鱼汤（变态辣）",
"rating": 5,
"type": "湘菜"
},
"sort": [
5
]
}
]
}
}
},
{
"key": "川菜",
"doc_count": 1,
"rated": {
"hits": {
"total": 1,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYr_OA-dG63Txsf",
"_score": null,
"_source": {
"name": "鱼香肉丝",
"rating": 2,
"type": "川菜"
},
"sort": [
2
]
}
]
}
}
},
{
"key": "粤菜",
"doc_count": 1,
"rated": {
"hits": {
"total": 1,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYW_OA-dG63Txse",
"_score": null,
"_source": {
"name": "广式鲫鱼汤",
"rating": 5,
"type": "粤菜"
},
"sort": [
5
]
}
]
}
}
},
{
"key": "西菜",
"doc_count": 1,
"rated": {
"hits": {
"total": 1,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHY3_OA-dG63Txsg",
"_score": null,
"_source": {
"name": "奶油鲍鱼汤",
"rating": 2,
"type": "西菜"
},
"sort": [
2
]
}
]
}
}
}
]
}
}
}
GET recipes/type/_search
{
"query": {
"match": {
"name": "鱼"
}
},
"collapse": {
"field": "type"
},
"size": 3,
"from": 0
}{
"took": 1,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoDNlRJ_OA-dG63TxpW",
"_score": 0.018980097,
"_source": {
"name": "鲫鱼汤（微辣）",
"rating": 4,
"type": "湘菜"
},
"fields": {
"type": [
"湘菜"
]
}
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoDNlRk_OA-dG63TxpZ",
"_score": 0.013813315,
"_source": {
"name": "鱼香肉丝",
"rating": 2,
"type": "川菜"
},
"fields": {
"type": [
"川菜"
]
}
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoDNlRb_OA-dG63TxpY",
"_score": 0.0125863515,
"_source": {
"name": "广式鲫鱼汤",
"rating": 5,
"type": "粤菜"
},
"fields": {
"type": [
"粤菜"
]
}
}
]
}
}{
"took": 1,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoDNlRw_OA-dG63Txpa",
"_score": 0.012546891,
"_source": {
"name": "奶油鲍鱼汤",
"rating": 2,
"type": "西菜"
},
"fields": {
"type": [
"西菜"
]
}
}
]
}
}GET recipes/type/_search
{
"query": {
"match": {
"name": "鱼"
}
},
"collapse": {
"field": "type",
"inner_hits": {
"name": "top_rated",
"size": 2,
"sort": [
{
"rating": "desc"
}
]
}
},
"sort": [
{
"rating": {
"order": "desc"
}
}
],
"size": 2,
"from": 0
}{
"took": 1,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYF_OA-dG63Txsd",
"_score": null,
"_source": {
"name": "鲫鱼汤（变态辣）",
"rating": 5,
"type": "湘菜"
},
"fields": {
"type": [
"湘菜"
]
},
"sort": [
5
],
"inner_hits": {
"top_rated": {
"hits": {
"total": 6,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYF_OA-dG63Txsd",
"_score": null,
"_source": {
"name": "鲫鱼汤（变态辣）",
"rating": 5,
"type": "湘菜"
},
"sort": [
5
]
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHX7_OA-dG63Txsc",
"_score": null,
"_source": {
"name": "鲫鱼汤（微辣）",
"rating": 4,
"type": "湘菜"
},
"sort": [
4
]
}
]
}
}
}
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYW_OA-dG63Txse",
"_score": null,
"_source": {
"name": "广式鲫鱼汤",
"rating": 5,
"type": "粤菜"
},
"fields": {
"type": [
"粤菜"
]
},
"sort": [
5
],
"inner_hits": {
"top_rated": {
"hits": {
"total": 1,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYW_OA-dG63Txse",
"_score": null,
"_source": {
"name": "广式鲫鱼汤",
"rating": 5,
"type": "粤菜"
},
"sort": [
5
]
}
]
}
}
}
}
]
}
}在 Elasticsearch 5.x 有一个字段折叠（Field Collapsing，#22337）的功能非常有意思，在这里分享一下，
字段折叠是一个很有历史的需求了，可以看这个 issue，编号#256，最初是2010年7月提的issue，也是讨论最多的帖子之一（240+评论），熬了6年才支持的特性，你说牛不牛，哈哈。
目测该特性将于5.3发布，尝鲜地址：Elasticsearch-5.3.0-SNAPSHOT，文档地址：search-request-collapse。
So，什么是字段折叠，可以理解就是按特定字段进行合并去重，比如我们有一个菜谱搜索，我希望按菜谱的“菜系”字段进行折叠，即返回结果每个菜系都返回一个结果，也就是按菜系去重，我搜索关键字“鱼”，要去返回的结果里面各种菜系都有，有湘菜，有粤菜，有中餐，有西餐，别全是湘菜，就是这个意思，通过按特定字段折叠之后，来丰富搜索结果的多样性。
说到这里，有人肯定会想到，使用 term agg+ top hits agg 来实现啊，这种组合两种聚和的方式可以实现上面的功能，不过也有一些局限性，比如，不能分页，#4915；结果不够精确（top term+top hits，es 的聚合实现选择了牺牲精度来提高速度）；数据量大的情况下，聚合比较慢，影响搜索体验。
而新的的字段折叠的方式是怎么实现的的呢，有这些要点：
- 折叠+取 inner_hits 分两阶段执行（组合聚合的方式只有一个阶段），所以 top hits 永远是精确的。
- 字段折叠只在 top hits 层执行，不需要每次都在完整的结果集上对为每个折叠主键计算实际的 doc values 值，只对 top hits 这小部分数据操作就可以，和 term agg 相比要节省很多内存。
- 因为只在 top hits 上进行折叠，所以相比组合聚合的方式，速度要快很多。
- 折叠 top docs 不需要使用全局序列（global ordinals）来转换 string，相比 agg 这也节省了很多内存。
- 分页成为可能，和常规搜索一样，具有相同的局限，先获取 from+size 的内容，再合并。
- search_after 和 scroll 暂未实现，不过具备可行性。
- 折叠只影响搜索结果，不影响聚合，搜索结果的 total 是所有的命中纪录数，去重的结果数未知（无法计算）。
下面来看看具体的例子，就知道怎么回事了，使用起来很简单。
- 先准备索引和数据，这里以菜谱为例，name：菜谱名，type 为菜系，rating 为用户的累积平均评分
DELETE recipes
PUT recipes
POST recipes/type/_mapping
{
"properties": {
"name":{
"type": "text"
},
"rating":{
"type": "float"
},"type":{
"type": "keyword"
}
}
}
POST recipes/type/
{
"name":"清蒸鱼头","rating":1,"type":"湘菜"
}
POST recipes/type/
{
"name":"剁椒鱼头","rating":2,"type":"湘菜"
}
POST recipes/type/
{
"name":"红烧鲫鱼","rating":3,"type":"湘菜"
}
POST recipes/type/
{
"name":"鲫鱼汤（辣）","rating":3,"type":"湘菜"
}
POST recipes/type/
{
"name":"鲫鱼汤（微辣）","rating":4,"type":"湘菜"
}
POST recipes/type/
{
"name":"鲫鱼汤（变态辣）","rating":5,"type":"湘菜"
}
POST recipes/type/
{
"name":"广式鲫鱼汤","rating":5,"type":"粤菜"
}
POST recipes/type/
{
"name":"鱼香肉丝","rating":2,"type":"川菜"
}
POST recipes/type/
{
"name":"奶油鲍鱼汤","rating":2,"type":"西菜"
} - 现在我们看看普通的查询效果是怎么样的，搜索关键字带“鱼”的菜，返回3条数据
POST recipes/type/_search
{
"query": {"match": {
"name": "鱼"
}},"size": 3
} {
"took": 2,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": 0.26742277,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYF_OA-dG63Txsd",
"_score": 0.26742277,
"_source": {
"name": "鲫鱼汤（变态辣）",
"rating": 5,
"type": "湘菜"
}
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHXO_OA-dG63Txsa",
"_score": 0.19100356,
"_source": {
"name": "红烧鲫鱼",
"rating": 3,
"type": "湘菜"
}
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHWy_OA-dG63TxsZ",
"_score": 0.19100356,
"_source": {
"name": "剁椒鱼头",
"rating": 2,
"type": "湘菜"
}
}
]
}
}POST recipes/type/_search
{
"query": {"match": {
"name": "鱼"
}},"sort": [
{
"rating": {
"order": "desc"
}
}
],"size": 3
} {
"took": 1,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYF_OA-dG63Txsd",
"_score": null,
"_source": {
"name": "鲫鱼汤（变态辣）",
"rating": 5,
"type": "湘菜"
},
"sort": [
5
]
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYW_OA-dG63Txse",
"_score": null,
"_source": {
"name": "广式鲫鱼汤",
"rating": 5,
"type": "粤菜"
},
"sort": [
5
]
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHX7_OA-dG63Txsc",
"_score": null,
"_source": {
"name": "鲫鱼汤（微辣）",
"rating": 4,
"type": "湘菜"
},
"sort": [
4
]
}
]
}
}
GET recipes/type/_search
{
"query": {
"match": {
"name": "鱼"
}
},
"sort": [
{
"rating": {
"order": "desc"
}
}
],"aggs": {
"type": {
"terms": {
"field": "type",
"size": 10
},"aggs": {
"rated": {
"top_hits": {
"sort": [{
"rating": {"order": "desc"}
}],
"size": 1
}
}
}
}
},
"size": 0,
"from": 0
} {
"took": 4,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": 0,
"hits": []
},
"aggregations": {
"type": {
"doc_count_error_upper_bound": 0,
"sum_other_doc_count": 0,
"buckets": [
{
"key": "湘菜",
"doc_count": 6,
"rated": {
"hits": {
"total": 6,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYF_OA-dG63Txsd",
"_score": null,
"_source": {
"name": "鲫鱼汤（变态辣）",
"rating": 5,
"type": "湘菜"
},
"sort": [
5
]
}
]
}
}
},
{
"key": "川菜",
"doc_count": 1,
"rated": {
"hits": {
"total": 1,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYr_OA-dG63Txsf",
"_score": null,
"_source": {
"name": "鱼香肉丝",
"rating": 2,
"type": "川菜"
},
"sort": [
2
]
}
]
}
}
},
{
"key": "粤菜",
"doc_count": 1,
"rated": {
"hits": {
"total": 1,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYW_OA-dG63Txse",
"_score": null,
"_source": {
"name": "广式鲫鱼汤",
"rating": 5,
"type": "粤菜"
},
"sort": [
5
]
}
]
}
}
},
{
"key": "西菜",
"doc_count": 1,
"rated": {
"hits": {
"total": 1,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHY3_OA-dG63Txsg",
"_score": null,
"_source": {
"name": "奶油鲍鱼汤",
"rating": 2,
"type": "西菜"
},
"sort": [
2
]
}
]
}
}
}
]
}
}
}
GET recipes/type/_search
{
"query": {
"match": {
"name": "鱼"
}
},
"collapse": {
"field": "type"
},
"size": 3,
"from": 0
}{
"took": 1,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoDNlRJ_OA-dG63TxpW",
"_score": 0.018980097,
"_source": {
"name": "鲫鱼汤（微辣）",
"rating": 4,
"type": "湘菜"
},
"fields": {
"type": [
"湘菜"
]
}
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoDNlRk_OA-dG63TxpZ",
"_score": 0.013813315,
"_source": {
"name": "鱼香肉丝",
"rating": 2,
"type": "川菜"
},
"fields": {
"type": [
"川菜"
]
}
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoDNlRb_OA-dG63TxpY",
"_score": 0.0125863515,
"_source": {
"name": "广式鲫鱼汤",
"rating": 5,
"type": "粤菜"
},
"fields": {
"type": [
"粤菜"
]
}
}
]
}
}{
"took": 1,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoDNlRw_OA-dG63Txpa",
"_score": 0.012546891,
"_source": {
"name": "奶油鲍鱼汤",
"rating": 2,
"type": "西菜"
},
"fields": {
"type": [
"西菜"
]
}
}
]
}
}GET recipes/type/_search
{
"query": {
"match": {
"name": "鱼"
}
},
"collapse": {
"field": "type",
"inner_hits": {
"name": "top_rated",
"size": 2,
"sort": [
{
"rating": "desc"
}
]
}
},
"sort": [
{
"rating": {
"order": "desc"
}
}
],
"size": 2,
"from": 0
}{
"took": 1,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"failed": 0
},
"hits": {
"total": 9,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYF_OA-dG63Txsd",
"_score": null,
"_source": {
"name": "鲫鱼汤（变态辣）",
"rating": 5,
"type": "湘菜"
},
"fields": {
"type": [
"湘菜"
]
},
"sort": [
5
],
"inner_hits": {
"top_rated": {
"hits": {
"total": 6,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYF_OA-dG63Txsd",
"_score": null,
"_source": {
"name": "鲫鱼汤（变态辣）",
"rating": 5,
"type": "湘菜"
},
"sort": [
5
]
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHX7_OA-dG63Txsc",
"_score": null,
"_source": {
"name": "鲫鱼汤（微辣）",
"rating": 4,
"type": "湘菜"
},
"sort": [
4
]
}
]
}
}
}
},
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYW_OA-dG63Txse",
"_score": null,
"_source": {
"name": "广式鲫鱼汤",
"rating": 5,
"type": "粤菜"
},
"fields": {
"type": [
"粤菜"
]
},
"sort": [
5
],
"inner_hits": {
"top_rated": {
"hits": {
"total": 1,
"max_score": null,
"hits": [
{
"_index": "recipes",
"_type": "type",
"_id": "AVoESHYW_OA-dG63Txse",
"_score": null,
"_source": {
"name": "广式鲫鱼汤",
"rating": 5,
"type": "粤菜"
},
"sort": [
5
]
}
]
}
}
}
}
]
}
}
medcl 发表于 : 2017-02-03 18:45
评论 (27)
Elastic Stack 5.2.0 发布
本周三，Elastic 发布了 ElasticStack 的全新版本5.2.0，包含了很多激动人心的特性，让我们 一起来看看吧，
（Elastic Stack 包括 Elasticsearch、Logstash、Kibana、Beats）：
Elasticsearch 5.2.0 主要亮点:
相关链接：
Download Elasticsearch 5.2.0
Elasticsearch 5.2.0 release notes
Elasticsearch 5.2.0 breaking changes
X-Pack 5.2.0 release notes
Logstash 5.2.0 主要亮点：
相关连接：
Download Logstash 5.2.0
Logstash 5.2.0 release notes
Kibana 5.2.0 主要亮点：
相关连接：
Download Kibana 5.2.0
Kibana 5.2.0 release notes
Beats 5.2.0 主要亮点：
相关连接：
Download Beats 5.2.0
Beats 5.2.0 release notes
Elastic Stack 下载链接：https://www.elastic.co/downloads
Bug 反馈：http://github.com/elastic
以后有版本的更新消息都会在这里发布一份中文版，欢迎大家关注。
继续阅读 »
（Elastic Stack 包括 Elasticsearch、Logstash、Kibana、Beats）：
Elasticsearch 5.2.0 主要亮点:
- 新增数字和日期范围字段类型，非常方便对范围类型进行交并集的查询，比如你的数据是日历类型的数据，每天都有一些会议信息，会议的开始和结束时间都不同，你想看本周那天有空，可以使用 range fields 很方便的进行查询。了解更多
- 新增分片分配解释 API，会告知分片失败的具体原因，如分片损坏、磁盘写满还是配置错误，进行快速运维，以前只能根据经验到处寻找可能是什么问题，费事费力，了解更多。
- 对 Keyword 类型标准化，在5.0将 string 类型拆成了 text 和 keyword两种类型，text 支持分词，keyword 则不分词默认支持 doc values，不过有时候你还需要对 keyword 类型进行一些标准化处理，如都转成小写，现在可以使用 normalizers 参数来指定标准化的 filter。
- Terms 聚合的分区，terms 聚合默认返回10个 term，以前如果你需要返回全部的 term 列表是不可能的任务（基于内存压力），现在你可以通过将请求分区，以多次请求的方式来取回这些数据，了解更多。
- 字段折叠，在搜索时可以按某个字段的值进行折叠，在每个折叠的值内进行排序选取 topN，了解更多。
相关链接：
Download Elasticsearch 5.2.0
Elasticsearch 5.2.0 release notes
Elasticsearch 5.2.0 breaking changes
X-Pack 5.2.0 release notes
Logstash 5.2.0 主要亮点：
- 新的监控 UI，现在 X-Pack 也能监控 logstash 了，X-Pack 基础免费版就包括，如下图：
- 更多的监控 API，新增3个类型的统计信息：cgroup、持久化队列和 output新增持续时间字段。
- 离线插件管理，在很多没有公网的部署环境，都需要离线安装，以前的离线安装不够完善，尽管大部分插件没问题，但是还是存在个别插件的依赖链下载不完整的问题，为了解决这个问题，我们基本上重新设计了整个工作流程使用了新的方式来打包插件和他所有的依赖，了解更多。
相关连接：
Download Logstash 5.2.0
Logstash 5.2.0 release notes
Kibana 5.2.0 主要亮点：
- 支持 Elasticsearch Tribe 节点，在“admin”集群的基础上，引入了新的“data”集群，“data”集群可以理解成 Kibana 后面的数据来源，可以是 tribe 节点，而“admin”集群是存放 kibana 可视化信息“。kibana”索引的地方，默认 data 和 admin 集群都是在同一个集群，且不能是 tribe 节点，目前还有一些细节正在处理，如 console 还不能很好的工作。
- 增加新的可视化类型：热点图（heatmap），可以很方便的按区间和按时间来显示数据的范围分布，如下图：
- 开始进行国际化的支持，感谢 IBM 团队的努力，目前已经提供了基础的框架支持，虽然是万里长征的第一大步，但也是非常激动人心的。
- 地图服务的改进，Elastic 自己的 Tile 地图服务已经上线几个月了，我们现在能提供10个级别的缩放了，X-Pack 基础用户可以达到12个级别的缩放，并且我们正在尝试18个级别的缩放，并且从5.2开始，我们能让这些级别动态调整，不用发布新的 Kibana。
- 监控容器中的 Elasticsearch，现在我们可以监控容器里面的 Elasticsearch 实例的运行情况了，CPU 利用率、GC、堆栈使用情况等，如下图：
相关连接：
Download Kibana 5.2.0
Kibana 5.2.0 release notes
Beats 5.2.0 主要亮点：
- 新增 Beat：Heartbeat，一个新的正式的官方beat 成员，用于可用性监控，和所有的 beat 一样，轻量级，Heartbeat 可以用于很多场景，比如安全，你不希望暴露某个端口时，使用 Heartbeat，当你发现该端口对外开启了，就可以触发通知，或者服务/网站可用性检测，服务down 了可以及时感知，目前支持：ICMP、TCP 和 HTTP 类型的监控，目前 Heartbeat还处于 beat 阶段，暂不推荐用于生产环境。
- Metricbeat 可跟踪网络连接，从5.2开始，Metricbeat 导出了 linux 系统的应用程序的网络连接信息，每个进程打开的 tcp 套接字，本地及远程的 ip 都包含在内，基于它，你可以进行如下的图分析：
- 收集Prometheus导出的指标，从5.2开始，监控系统普罗米修斯的收集模块导出的数据可以提供给 Metricbeat 然后索引进 Elasticsearch。
相关连接：
Download Beats 5.2.0
Beats 5.2.0 release notes
Elastic Stack 下载链接：https://www.elastic.co/downloads
Bug 反馈：http://github.com/elastic
以后有版本的更新消息都会在这里发布一份中文版，欢迎大家关注。
本周三，Elastic 发布了 ElasticStack 的全新版本5.2.0，包含了很多激动人心的特性，让我们 一起来看看吧，
（Elastic Stack 包括 Elasticsearch、Logstash、Kibana、Beats）：
Elasticsearch 5.2.0 主要亮点:
相关链接：
Download Elasticsearch 5.2.0
Elasticsearch 5.2.0 release notes
Elasticsearch 5.2.0 breaking changes
X-Pack 5.2.0 release notes
Logstash 5.2.0 主要亮点：
相关连接：
Download Logstash 5.2.0
Logstash 5.2.0 release notes
Kibana 5.2.0 主要亮点：
相关连接：
Download Kibana 5.2.0
Kibana 5.2.0 release notes
Beats 5.2.0 主要亮点：
相关连接：
Download Beats 5.2.0
Beats 5.2.0 release notes
Elastic Stack 下载链接：https://www.elastic.co/downloads
Bug 反馈：http://github.com/elastic
以后有版本的更新消息都会在这里发布一份中文版，欢迎大家关注。 收起阅读 »
（Elastic Stack 包括 Elasticsearch、Logstash、Kibana、Beats）：
Elasticsearch 5.2.0 主要亮点:
- 新增数字和日期范围字段类型，非常方便对范围类型进行交并集的查询，比如你的数据是日历类型的数据，每天都有一些会议信息，会议的开始和结束时间都不同，你想看本周那天有空，可以使用 range fields 很方便的进行查询。了解更多
- 新增分片分配解释 API，会告知分片失败的具体原因，如分片损坏、磁盘写满还是配置错误，进行快速运维，以前只能根据经验到处寻找可能是什么问题，费事费力，了解更多。
- 对 Keyword 类型标准化，在5.0将 string 类型拆成了 text 和 keyword两种类型，text 支持分词，keyword 则不分词默认支持 doc values，不过有时候你还需要对 keyword 类型进行一些标准化处理，如都转成小写，现在可以使用 normalizers 参数来指定标准化的 filter。
- Terms 聚合的分区，terms 聚合默认返回10个 term，以前如果你需要返回全部的 term 列表是不可能的任务（基于内存压力），现在你可以通过将请求分区，以多次请求的方式来取回这些数据，了解更多。
- 字段折叠，在搜索时可以按某个字段的值进行折叠，在每个折叠的值内进行排序选取 topN，了解更多。
相关链接：
Download Elasticsearch 5.2.0
Elasticsearch 5.2.0 release notes
Elasticsearch 5.2.0 breaking changes
X-Pack 5.2.0 release notes
Logstash 5.2.0 主要亮点：
- 新的监控 UI，现在 X-Pack 也能监控 logstash 了，X-Pack 基础免费版就包括，如下图：
- 更多的监控 API，新增3个类型的统计信息：cgroup、持久化队列和 output新增持续时间字段。
- 离线插件管理，在很多没有公网的部署环境，都需要离线安装，以前的离线安装不够完善，尽管大部分插件没问题，但是还是存在个别插件的依赖链下载不完整的问题，为了解决这个问题，我们基本上重新设计了整个工作流程使用了新的方式来打包插件和他所有的依赖，了解更多。
相关连接：
Download Logstash 5.2.0
Logstash 5.2.0 release notes
Kibana 5.2.0 主要亮点：
- 支持 Elasticsearch Tribe 节点，在“admin”集群的基础上，引入了新的“data”集群，“data”集群可以理解成 Kibana 后面的数据来源，可以是 tribe 节点，而“admin”集群是存放 kibana 可视化信息“。kibana”索引的地方，默认 data 和 admin 集群都是在同一个集群，且不能是 tribe 节点，目前还有一些细节正在处理，如 console 还不能很好的工作。
- 增加新的可视化类型：热点图（heatmap），可以很方便的按区间和按时间来显示数据的范围分布，如下图：
- 开始进行国际化的支持，感谢 IBM 团队的努力，目前已经提供了基础的框架支持，虽然是万里长征的第一大步，但也是非常激动人心的。
- 地图服务的改进，Elastic 自己的 Tile 地图服务已经上线几个月了，我们现在能提供10个级别的缩放了，X-Pack 基础用户可以达到12个级别的缩放，并且我们正在尝试18个级别的缩放，并且从5.2开始，我们能让这些级别动态调整，不用发布新的 Kibana。
- 监控容器中的 Elasticsearch，现在我们可以监控容器里面的 Elasticsearch 实例的运行情况了，CPU 利用率、GC、堆栈使用情况等，如下图：
相关连接：
Download Kibana 5.2.0
Kibana 5.2.0 release notes
Beats 5.2.0 主要亮点：
- 新增 Beat：Heartbeat，一个新的正式的官方beat 成员，用于可用性监控，和所有的 beat 一样，轻量级，Heartbeat 可以用于很多场景，比如安全，你不希望暴露某个端口时，使用 Heartbeat，当你发现该端口对外开启了，就可以触发通知，或者服务/网站可用性检测，服务down 了可以及时感知，目前支持：ICMP、TCP 和 HTTP 类型的监控，目前 Heartbeat还处于 beat 阶段，暂不推荐用于生产环境。
- Metricbeat 可跟踪网络连接，从5.2开始，Metricbeat 导出了 linux 系统的应用程序的网络连接信息，每个进程打开的 tcp 套接字，本地及远程的 ip 都包含在内，基于它，你可以进行如下的图分析：
- 收集Prometheus导出的指标，从5.2开始，监控系统普罗米修斯的收集模块导出的数据可以提供给 Metricbeat 然后索引进 Elasticsearch。
相关连接：
Download Beats 5.2.0
Beats 5.2.0 release notes
Elastic Stack 下载链接：https://www.elastic.co/downloads
Bug 反馈：http://github.com/elastic
以后有版本的更新消息都会在这里发布一份中文版，欢迎大家关注。 收起阅读 »
medcl 发表于 : 2017-02-03 13:26
评论 (1)
发现的一个不错的elasticsearch 官方文档的翻译文档
这几天一直在学习elasticsearch，很多地方不是太明白，于是去官方网站上查看说明文档，发现真的很不方便查看，一是由于文档布局排版不好，查看不同的API还得必须跳到不同页面上，最重要一点是需要翻墙才能看文档，很是烦恼，今天忽然在一个网站上发现了一个把elasticsearch官方2.3.3的java elasticsearch 文档翻译了，而且我看了一下，还是不错的，于是分享给大家，果断收藏啊：
Elasticsearch 2.3.3 JAVA api说明文档
继续阅读 »
Elasticsearch 2.3.3 JAVA api说明文档
这几天一直在学习elasticsearch，很多地方不是太明白，于是去官方网站上查看说明文档，发现真的很不方便查看，一是由于文档布局排版不好，查看不同的API还得必须跳到不同页面上，最重要一点是需要翻墙才能看文档，很是烦恼，今天忽然在一个网站上发现了一个把elasticsearch官方2.3.3的java elasticsearch 文档翻译了，而且我看了一下，还是不错的，于是分享给大家，果断收藏啊：
Elasticsearch 2.3.3 JAVA api说明文档 收起阅读 »
Elasticsearch 2.3.3 JAVA api说明文档 收起阅读 »
guopengfei 发表于 : 2017-01-14 15:43
评论 (1)
Elasticsearch 安全加固 101
最近 MongoDB 的安全事件闹得沸沸扬扬，应该不少人都听说了吧，事情大概是，因为 MongoDB 默认的安全设置造成了数据外泄并且被黑客勒索才能找回数据，想了解的，这里有几个链接：
http://www.jianshu.com/p/48d17a69e190
http://mt.sohu.com/20170107/n478047698.shtml
http://bbs.tianya.cn/post-itinfo-503786-1.shtml
安全从来不是等到出事才要注意的事情，可以说安全是第一重要的事情，不管你是公司的CTO、技术总监、运维总监、架构师还是一线工程师，都应该有安全意识，好了，废话不多说了，Elasticsearch 的用户现在越来越多了，有些已经成为公司的基础服务，所以数据的安全非常重要，今天主要给大家介绍 Elasticsearch 围绕安全方面的的几点使用事项：
下载安装
请使用正规渠道下载 Elasticsearch，首选官方网站，下载完成，记得要验证下载文件的 sha1值和官网下载的提供的sha1值进行对比，避免下载过程中被人拦截破坏文件，甚至注入恶意代码。
不要随便安装第三方的插件，插件有可能引入安全漏洞甚至本身自带后门，需谨慎使用。
链接君：https://www.elastic.co/downloads
使用最新的 Elasticsearch
请关注 Elastic 网站，及时更新升级 Elasticsearch 的最新版本，Elasticsearch 每次版本发布都会优化和改进一部分功能，尤其是安全漏洞的补丁，仔细阅读 Elasticsearch 的更新记录，Elasticsearch 的版本遵照 语义化版本 ，所以小版本间应该是能够无缝升级的，建议及时本地测试和线上更新，升级前，记得 snapshot 做好备份。
链接君：https://www.elastic.co/downloads
修改默认的 Elasticsearch 集群名称
Elasticsearch 默认的集群名称是 elasticsearch，请在生成环境上一定要修改成其他的名称，并且不同的环境和不同的集群要保证不相同，监控集群节点情况，如果有未知节点加入，一定要及时预警。
文档君：https://www.elastic.co/guide/e ... .name
不要暴露 Elasticsearch 在公网上
Elasticsearch 默认端口是9200，绑定的是本机127.0.0.1的这个 ip，这个默认参数其实很安全，但是有很多人想要绑定其他的 lan 口或者公网的 ip，可以修改相应参数，记住，修改有风险，如果确实需要将 Elasticsearch 暴露在公网环境，请修改特定的端口绑定IP，不要直接修改参数： network.host，而是要分别修改：http.port 来绑定 HTTP 协议9200 端口的 IP（RESTful 接口调用），修改：transport.tcp.port 对应的 TCP 9300 端口的 IP（集群内通信），如果你不需要 http 端口，你干脆禁用掉，另外还需要在 Elasticsearch 之上加上成熟的安全防护措施（注意是成熟的！），在这里提供几种方案：
- 9200的 HTTP 接口之上加上 Nginx 来提供 Http Basic-Auth 的基本的身份认证，辅助 SSL 证书进行传输层的加密，Nginx 进一步限制可接受 Verb 请求类型及可被操作的索引前缀。
- 使用 Elastic 的 X-Pack 插件，同样提供了 Http Basic-Auth 和 SSL 传输层的加密，X-Pack 还能提供内外 Elasticsearch 集群节点间的流量加密，避免旁路攻击。
文档君：https://www.elastic.co/guide/e ... tings
禁用批量删除索引
Elasticsearch 支持通过_all（全部）和通配符（*）来批量删除索引，在生产环境，这个有点危险，你可以通过设置： action.destructive_requires_name: true 来禁用它。
安全使用动态脚本
Elasticsearch 的脚本很方便的可以对数据进行操作，不过如果你暂时没有用上，还请禁用它（Elasticsearch 在1.2.x 以后已经默认禁用了），如果你已经在使用动态脚本，比如 Groovy，它不是沙盒机制的脚本引擎，启用 inline 或 store 类型的groovy 有安全风险，请限制脚本的接触方，比如通过模板的方式来限制脚本的调用，只需要执行特定预先定义好的脚本，对调用参数进行过滤和参数值的检测，做好验证，同时各种日志都必须要保留好，方便进行日志分析，异常的调用和请求一定要有发现和预警机制。
Elasticsearch 默认启用了 Java Security Manager ，但还请正确配置其白名单。
使用 Groovy 或者JavaScript 等脚本的用户，尽快迁移到 Painless 脚本，Painless 更快更安全。
文档君：https://www.elastic.co/guide/e ... .html
给 Elasticsearch 服务器加固
服务器加固是一个必备流程，不管上面运行的是什么服务；
首先，请开启防火墙，请设置防火墙规则，只开启必备的端口，完成之后，使用扫描工具扫描服务器，检查端口开发情况；
如果可能，不要用密码的方法来远程登录服务器，使用公私钥的方式来 ssh 登录服务器，如果只能使用密码，请妥善保管好你的用户名和密码，禁用 root 用户，不用使用弱密码。
关注 Java 最新的漏洞，使用安全的 JVM 运行时。
服务器及时更新最新的软件，使用安全的 repo 软件源，绑定软件源的 host和 ip，避免 dns 污染造成的攻击，关注服务器软件漏洞，及时打上补丁。
收集系统日志和安装相应的入侵检测软件，及时发现服务器是否有异常行为。
不要以 root 身份运行 Elasticsearch
如果你的运维人员打算以 root 身份来运行某个服务，这个运维人员一定是一个不合格的运维人员，记住一定不要以 root 身份来运行 Elasticsearch，另外，要不和其他的服务公用相同的用户，然后还要保证该用户的权限要最小化。
范例君：
sudo -u es-user ES_JAVA_OPTS="-Xms1024m -Xmx1024m" /opt/elasticsearch/bin/elasticsearc正确设置 Elasticsearch 的数据目录
请确保 Elasticsearch 的目录分配了合理的读写权限，避免使用共享文件系统，确保只有 elasticsearch 的启动用户才能访问，同理，日志目录也一样需要正确配置，避免泄露敏感信息。
文档君：https://www.elastic.co/guide/e ... tings
定期对 Elasticsearch 进行备份
使用 Elasticsearch 提供的备份还原机制，定期对 Elasticsearch 的数据进行快照备份，以备不时之需。
文档君：https://www.elastic.co/guide/e ... .html
加上监控和预警
Elasticsearch 提供了很好的默认参数，对参数方面还做了正确性检测，bootstrap 启动检查，不准确的参数，直接不允许 Elasticsearch 启动，以至于有很多人抱怨，怎么现在部署到线上默认就需要做这么多设置才能使用呢，是的，以前启动就默认绑定了所有的网卡，集群见自动发现和相连，现在需要手动绑定局域网网卡，默认只是绑定的本机127.0.0.1的 ip，对上线来说麻烦了一点，做了这些检查也就是为了保证数据安全，以前很多的公网都能直接访问的 Elasticsearch 实例，都是因为默认设置就绑定了公网 ip，但是这些还不够，作为用户，你还需要收集各种日志和系统监控信息，及时主动掌握服务健康和资源使用情况，发现异常情况要及时处理，这里提供一些方案:
- 使用开源的 Elastic Stack 收集这些日志，可以使用 Filebeat 收集日志，Metricbeat收集系统监控信息，存进 Elasticsearch，一旦发现异常的波动，使用 Watcher 来进行预警，通过邮件或者 webhook 调用短信、微信或者电话。
- 使用其他厂商的安全监控产品。
- 使用托管的 Elasticsearch 云的产品，如 Elastic Cloud等等。
是的，把安全这个事情考虑进去之后，很多事情都要比没考虑要变得更加复杂和麻烦，千里之堤毁于蚁穴，一个不起眼的忽视就有可能造成全部数据的丢失和泄露，出来混迟早是要还的，安全问题千万不能忽视。
以上几点建议举例针对 linux 平台，其他平台思路基本上一样，仅供参考，安全是一个包含很多方方面面的学科，抛砖引玉，希望大家有用。
最后，Elastic 非常关心我们的产品安全，如果您发现有任何安全方面的问题，还请在这里上报：
https://www.elastic.co/community/security
企业用户需要 X-Pack 及 Elastic 官方技术支持，请访问下面的链接：
https://www.elastic.co/cn/contact
最近 MongoDB 的安全事件闹得沸沸扬扬，应该不少人都听说了吧，事情大概是，因为 MongoDB 默认的安全设置造成了数据外泄并且被黑客勒索才能找回数据，想了解的，这里有几个链接：
http://www.jianshu.com/p/48d17a69e190
http://mt.sohu.com/20170107/n478047698.shtml
http://bbs.tianya.cn/post-itinfo-503786-1.shtml
安全从来不是等到出事才要注意的事情，可以说安全是第一重要的事情，不管你是公司的CTO、技术总监、运维总监、架构师还是一线工程师，都应该有安全意识，好了，废话不多说了，Elasticsearch 的用户现在越来越多了，有些已经成为公司的基础服务，所以数据的安全非常重要，今天主要给大家介绍 Elasticsearch 围绕安全方面的的几点使用事项：
下载安装
请使用正规渠道下载 Elasticsearch，首选官方网站，下载完成，记得要验证下载文件的 sha1值和官网下载的提供的sha1值进行对比，避免下载过程中被人拦截破坏文件，甚至注入恶意代码。
不要随便安装第三方的插件，插件有可能引入安全漏洞甚至本身自带后门，需谨慎使用。
链接君：https://www.elastic.co/downloads
使用最新的 Elasticsearch
请关注 Elastic 网站，及时更新升级 Elasticsearch 的最新版本，Elasticsearch 每次版本发布都会优化和改进一部分功能，尤其是安全漏洞的补丁，仔细阅读 Elasticsearch 的更新记录，Elasticsearch 的版本遵照 语义化版本 ，所以小版本间应该是能够无缝升级的，建议及时本地测试和线上更新，升级前，记得 snapshot 做好备份。
链接君：https://www.elastic.co/downloads
修改默认的 Elasticsearch 集群名称
Elasticsearch 默认的集群名称是 elasticsearch，请在生成环境上一定要修改成其他的名称，并且不同的环境和不同的集群要保证不相同，监控集群节点情况，如果有未知节点加入，一定要及时预警。
文档君：https://www.elastic.co/guide/e ... .name
不要暴露 Elasticsearch 在公网上
Elasticsearch 默认端口是9200，绑定的是本机127.0.0.1的这个 ip，这个默认参数其实很安全，但是有很多人想要绑定其他的 lan 口或者公网的 ip，可以修改相应参数，记住，修改有风险，如果确实需要将 Elasticsearch 暴露在公网环境，请修改特定的端口绑定IP，不要直接修改参数： network.host，而是要分别修改：http.port 来绑定 HTTP 协议9200 端口的 IP（RESTful 接口调用），修改：transport.tcp.port 对应的 TCP 9300 端口的 IP（集群内通信），如果你不需要 http 端口，你干脆禁用掉，另外还需要在 Elasticsearch 之上加上成熟的安全防护措施（注意是成熟的！），在这里提供几种方案：
- 9200的 HTTP 接口之上加上 Nginx 来提供 Http Basic-Auth 的基本的身份认证，辅助 SSL 证书进行传输层的加密，Nginx 进一步限制可接受 Verb 请求类型及可被操作的索引前缀。
- 使用 Elastic 的 X-Pack 插件，同样提供了 Http Basic-Auth 和 SSL 传输层的加密，X-Pack 还能提供内外 Elasticsearch 集群节点间的流量加密，避免旁路攻击。
文档君：https://www.elastic.co/guide/e ... tings
禁用批量删除索引
Elasticsearch 支持通过_all（全部）和通配符（*）来批量删除索引，在生产环境，这个有点危险，你可以通过设置： action.destructive_requires_name: true 来禁用它。
安全使用动态脚本
Elasticsearch 的脚本很方便的可以对数据进行操作，不过如果你暂时没有用上，还请禁用它（Elasticsearch 在1.2.x 以后已经默认禁用了），如果你已经在使用动态脚本，比如 Groovy，它不是沙盒机制的脚本引擎，启用 inline 或 store 类型的groovy 有安全风险，请限制脚本的接触方，比如通过模板的方式来限制脚本的调用，只需要执行特定预先定义好的脚本，对调用参数进行过滤和参数值的检测，做好验证，同时各种日志都必须要保留好，方便进行日志分析，异常的调用和请求一定要有发现和预警机制。
Elasticsearch 默认启用了 Java Security Manager ，但还请正确配置其白名单。
使用 Groovy 或者JavaScript 等脚本的用户，尽快迁移到 Painless 脚本，Painless 更快更安全。
文档君：https://www.elastic.co/guide/e ... .html
给 Elasticsearch 服务器加固
服务器加固是一个必备流程，不管上面运行的是什么服务；
首先，请开启防火墙，请设置防火墙规则，只开启必备的端口，完成之后，使用扫描工具扫描服务器，检查端口开发情况；
如果可能，不要用密码的方法来远程登录服务器，使用公私钥的方式来 ssh 登录服务器，如果只能使用密码，请妥善保管好你的用户名和密码，禁用 root 用户，不用使用弱密码。
关注 Java 最新的漏洞，使用安全的 JVM 运行时。
服务器及时更新最新的软件，使用安全的 repo 软件源，绑定软件源的 host和 ip，避免 dns 污染造成的攻击，关注服务器软件漏洞，及时打上补丁。
收集系统日志和安装相应的入侵检测软件，及时发现服务器是否有异常行为。
不要以 root 身份运行 Elasticsearch
如果你的运维人员打算以 root 身份来运行某个服务，这个运维人员一定是一个不合格的运维人员，记住一定不要以 root 身份来运行 Elasticsearch，另外，要不和其他的服务公用相同的用户，然后还要保证该用户的权限要最小化。
范例君：
sudo -u es-user ES_JAVA_OPTS="-Xms1024m -Xmx1024m" /opt/elasticsearch/bin/elasticsearc正确设置 Elasticsearch 的数据目录
请确保 Elasticsearch 的目录分配了合理的读写权限，避免使用共享文件系统，确保只有 elasticsearch 的启动用户才能访问，同理，日志目录也一样需要正确配置，避免泄露敏感信息。
文档君：https://www.elastic.co/guide/e ... tings
定期对 Elasticsearch 进行备份
使用 Elasticsearch 提供的备份还原机制，定期对 Elasticsearch 的数据进行快照备份，以备不时之需。
文档君：https://www.elastic.co/guide/e ... .html
加上监控和预警
Elasticsearch 提供了很好的默认参数，对参数方面还做了正确性检测，bootstrap 启动检查，不准确的参数，直接不允许 Elasticsearch 启动，以至于有很多人抱怨，怎么现在部署到线上默认就需要做这么多设置才能使用呢，是的，以前启动就默认绑定了所有的网卡，集群见自动发现和相连，现在需要手动绑定局域网网卡，默认只是绑定的本机127.0.0.1的 ip，对上线来说麻烦了一点，做了这些检查也就是为了保证数据安全，以前很多的公网都能直接访问的 Elasticsearch 实例，都是因为默认设置就绑定了公网 ip，但是这些还不够，作为用户，你还需要收集各种日志和系统监控信息，及时主动掌握服务健康和资源使用情况，发现异常情况要及时处理，这里提供一些方案:
- 使用开源的 Elastic Stack 收集这些日志，可以使用 Filebeat 收集日志，Metricbeat收集系统监控信息，存进 Elasticsearch，一旦发现异常的波动，使用 Watcher 来进行预警，通过邮件或者 webhook 调用短信、微信或者电话。
- 使用其他厂商的安全监控产品。
- 使用托管的 Elasticsearch 云的产品，如 Elastic Cloud等等。
是的，把安全这个事情考虑进去之后，很多事情都要比没考虑要变得更加复杂和麻烦，千里之堤毁于蚁穴，一个不起眼的忽视就有可能造成全部数据的丢失和泄露，出来混迟早是要还的，安全问题千万不能忽视。
以上几点建议举例针对 linux 平台，其他平台思路基本上一样，仅供参考，安全是一个包含很多方方面面的学科，抛砖引玉，希望大家有用。
最后，Elastic 非常关心我们的产品安全，如果您发现有任何安全方面的问题，还请在这里上报：
https://www.elastic.co/community/security
企业用户需要 X-Pack 及 Elastic 官方技术支持，请访问下面的链接：
https://www.elastic.co/cn/contact 收起阅读 »
招聘
招聘需求：
技术总监1名：
1、 日志分析产品研发经验优先，8年以上工作经验
2、 精通elasticsearch、Redis、MongoDB、Neo4J等NoSQL系统，熟悉elasticsearch集群管理和性能调优，有在实际项目中使用搜索引擎工具、内存数据库、文档数据库、图数据库的经验
3、 熟悉Hadoop、Spark、Spark Streaming、Storm、HBase、ZooKeeper等大数据生态系统组件;熟悉Kafka、ZeroMQ等消息系统组件
4、 精通日志处理工具集ELK，flume，heka等
5、 熟悉Linux环境，熟练使用Python和Shell进行脚本编程
6、 精通JAVA语言，熟悉主流开源框架Struts2、Spring、Hibernate，SpringMVC的运行机制及使用。熟练掌握和使用J2EE开发中常见面向对象设计模式(Singleton，Proxy，Factory等)
7、 有系统运维管理平台项目开发及管理经验优先
8、 提供优厚待遇及期权，薪水50万以上
9、 金融行业背景优先考虑
技术专家2名：
1、熟悉Hadoop生态圈相关技术，如Hbase，Hive，Zookeeper，flume，kafka，storm
2、了解spark运行机制，研读spark部分内核源码；了解ELK日志分析平台（elasticsearch、logstash、kibana）使用
3、 熟悉Linux系统的基本操作和集群环境的搭建和部署
4、 熟悉JavaEE的开发，掌握JavaEE流行框架的使用，如：Struts2、Spring、Hibernate、SpringMVC等
5、熟悉主流数据库Oracle、DB2、MySQL、Mariadb的使用及性能优化；会使用NoSql数据库（如redis）解决开发过程中遇到的业务问题
6、提供优厚待遇和期权，薪水30万以上
7、金融行业优先考虑
如有意向请联系郝女士 联系电话：13520834022 邮箱：haojinjin16@163.com
招聘单位：洋大数据信息技术（北京）有限公司
继续阅读 »
技术总监1名：
1、 日志分析产品研发经验优先，8年以上工作经验
2、 精通elasticsearch、Redis、MongoDB、Neo4J等NoSQL系统，熟悉elasticsearch集群管理和性能调优，有在实际项目中使用搜索引擎工具、内存数据库、文档数据库、图数据库的经验
3、 熟悉Hadoop、Spark、Spark Streaming、Storm、HBase、ZooKeeper等大数据生态系统组件;熟悉Kafka、ZeroMQ等消息系统组件
4、 精通日志处理工具集ELK，flume，heka等
5、 熟悉Linux环境，熟练使用Python和Shell进行脚本编程
6、 精通JAVA语言，熟悉主流开源框架Struts2、Spring、Hibernate，SpringMVC的运行机制及使用。熟练掌握和使用J2EE开发中常见面向对象设计模式(Singleton，Proxy，Factory等)
7、 有系统运维管理平台项目开发及管理经验优先
8、 提供优厚待遇及期权，薪水50万以上
9、 金融行业背景优先考虑
技术专家2名：
1、熟悉Hadoop生态圈相关技术，如Hbase，Hive，Zookeeper，flume，kafka，storm
2、了解spark运行机制，研读spark部分内核源码；了解ELK日志分析平台（elasticsearch、logstash、kibana）使用
3、 熟悉Linux系统的基本操作和集群环境的搭建和部署
4、 熟悉JavaEE的开发，掌握JavaEE流行框架的使用，如：Struts2、Spring、Hibernate、SpringMVC等
5、熟悉主流数据库Oracle、DB2、MySQL、Mariadb的使用及性能优化；会使用NoSql数据库（如redis）解决开发过程中遇到的业务问题
6、提供优厚待遇和期权，薪水30万以上
7、金融行业优先考虑
如有意向请联系郝女士 联系电话：13520834022 邮箱：haojinjin16@163.com
招聘单位：洋大数据信息技术（北京）有限公司
招聘需求：
技术总监1名：
1、 日志分析产品研发经验优先，8年以上工作经验
2、 精通elasticsearch、Redis、MongoDB、Neo4J等NoSQL系统，熟悉elasticsearch集群管理和性能调优，有在实际项目中使用搜索引擎工具、内存数据库、文档数据库、图数据库的经验
3、 熟悉Hadoop、Spark、Spark Streaming、Storm、HBase、ZooKeeper等大数据生态系统组件;熟悉Kafka、ZeroMQ等消息系统组件
4、 精通日志处理工具集ELK，flume，heka等
5、 熟悉Linux环境，熟练使用Python和Shell进行脚本编程
6、 精通JAVA语言，熟悉主流开源框架Struts2、Spring、Hibernate，SpringMVC的运行机制及使用。熟练掌握和使用J2EE开发中常见面向对象设计模式(Singleton，Proxy，Factory等)
7、 有系统运维管理平台项目开发及管理经验优先
8、 提供优厚待遇及期权，薪水50万以上
9、 金融行业背景优先考虑
技术专家2名：
1、熟悉Hadoop生态圈相关技术，如Hbase，Hive，Zookeeper，flume，kafka，storm
2、了解spark运行机制，研读spark部分内核源码；了解ELK日志分析平台（elasticsearch、logstash、kibana）使用
3、 熟悉Linux系统的基本操作和集群环境的搭建和部署
4、 熟悉JavaEE的开发，掌握JavaEE流行框架的使用，如：Struts2、Spring、Hibernate、SpringMVC等
5、熟悉主流数据库Oracle、DB2、MySQL、Mariadb的使用及性能优化；会使用NoSql数据库（如redis）解决开发过程中遇到的业务问题
6、提供优厚待遇和期权，薪水30万以上
7、金融行业优先考虑
如有意向请联系郝女士 联系电话：13520834022 邮箱：haojinjin16@163.com
招聘单位：洋大数据信息技术（北京）有限公司 收起阅读 »
技术总监1名：
1、 日志分析产品研发经验优先，8年以上工作经验
2、 精通elasticsearch、Redis、MongoDB、Neo4J等NoSQL系统，熟悉elasticsearch集群管理和性能调优，有在实际项目中使用搜索引擎工具、内存数据库、文档数据库、图数据库的经验
3、 熟悉Hadoop、Spark、Spark Streaming、Storm、HBase、ZooKeeper等大数据生态系统组件;熟悉Kafka、ZeroMQ等消息系统组件
4、 精通日志处理工具集ELK，flume，heka等
5、 熟悉Linux环境，熟练使用Python和Shell进行脚本编程
6、 精通JAVA语言，熟悉主流开源框架Struts2、Spring、Hibernate，SpringMVC的运行机制及使用。熟练掌握和使用J2EE开发中常见面向对象设计模式(Singleton，Proxy，Factory等)
7、 有系统运维管理平台项目开发及管理经验优先
8、 提供优厚待遇及期权，薪水50万以上
9、 金融行业背景优先考虑
技术专家2名：
1、熟悉Hadoop生态圈相关技术，如Hbase，Hive，Zookeeper，flume，kafka，storm
2、了解spark运行机制，研读spark部分内核源码；了解ELK日志分析平台（elasticsearch、logstash、kibana）使用
3、 熟悉Linux系统的基本操作和集群环境的搭建和部署
4、 熟悉JavaEE的开发，掌握JavaEE流行框架的使用，如：Struts2、Spring、Hibernate、SpringMVC等
5、熟悉主流数据库Oracle、DB2、MySQL、Mariadb的使用及性能优化；会使用NoSql数据库（如redis）解决开发过程中遇到的业务问题
6、提供优厚待遇和期权，薪水30万以上
7、金融行业优先考虑
如有意向请联系郝女士 联系电话：13520834022 邮箱：haojinjin16@163.com
招聘单位：洋大数据信息技术（北京）有限公司 收起阅读 »
对话 Kibana 之父：如果需要，你应该自己动手编写工具
转载：http://www.infoq.com/cn/news/2 ... nTool
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
继续阅读 »
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
如果你有一个想法，把它code出来，build起来。不要等其他人的开源代码，有可能你会等到，但是有可能你永远等不到。在你写出来之后，你没准会收获惊喜。
转载：http://www.infoq.com/cn/news/2 ... nTool
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
收起阅读 »
在 Elastic 中国开发者大会 2016上，ELK 正式宣布更名为“Elastic Stack”，Elastic公司称其开源项目累计已经有8000万次下载。Elastic Stack 最新版本为5.0，从此，Elastic公司会对Elasticsearch、Kibana、Logstash、Beats、X-Pack进行统一规划以同版本号码发布。会上，Kibana 的原作者 Rashid Khan 进行了题为《Kibana 5.0: The Window into the Elastic Stack》。 PPT下载：http://elasticsearch.cn/article/122
早在2001年，Rashid 就接触了运维工作，他的第一份工作是在摩根大通集团做网络运维管理分析员。2012年，Rashid 在美国一家媒体公司担任架构工程师，并且研发了 Kibana 的初始版本，那时他的目的是专门设计界面以适配 Logstash，如今 Kibana 已经逐渐演变成了 Elasticsearch 的分析平台。运维出身的他是在怎样的情况下开始了 Kibana 开发，Kibana 走到今天经历了什么，将来 Kibana 的发展会是怎样的？InfoQ 对 Rashid 进行了采访，以下文章来自于采访稿件的整理。
作为运维人员，我亟须优化日志搜索
开始的时候做运维工作遇到很多问题，on call待命，甚至在凌晨2点被叫醒；这种工作状态让我感到很厌烦。往往，在日志中可以发现问题所在，但是需要花费好久时间才能找到。
于是，我寻找有哪些开源软件可以做基本的日志搜索，然后发现了Logstash和与之配合使用的Elasticsearch。经过测试，我发现Elasticsearch速度很快并且提供我所需要的功能；然后我就开始编写一套非常简单的interface作为补充展示，大概花费了我几天的时间。这就是第一版Kibana的诞生过程，当时是采用PHP编写的，功能是可以展示日志并配有搜索入口，目的是把这个工具可以交付给我的boss，使得他无需我的参与便可以使用这个interface。需要提一句的是，Elasticsearch 对于Web编程很友好，并且日志数据按照日期排列。
在全职投入 Kibana 为 Elastic 公司工作之前，我一直从事运维工作并且我非常喜欢运维工作。因为这段实践经验帮助我体会到了运维人的问题和困难，这让我知道了需要创造一个什么样的工具。我依然认为运维是一个非常有挑战的工作，让所有的东西都正常地运转起来。
编程吧，动手创造自己的工具
的确，我是运维人员，但是我还自己动手开发工具。这在美国越来越普遍了，因为大家意识到，如果你可以编写代码，你的工作会轻松很多，代码可以代替你进行重复工作。通过代码实现自动化是正确的途径，没有人愿意不停地做同样的事情。
编写Kibana是因为我当时没有发现一个适合我的工具，于是我决定自己动手。第一版Kibana是用PHP写的，第二版是用Ruby，第三版之后是用JavaScript。我不害怕学习心得语言，因为学语言并不难，Ruby或者JavaScript的语言掌握仅仅是简单的熟悉语法，并没有接触到实际项目中复杂的事情。而重写Kibana的工作也并不复杂，因为其实Elasticsearch做的工作最重。
“哪种编程语言最好？”说实话，其实这个问题的讨论对我而言并不重要。重要的是，为你的工作选择恰当的语言。PHP在我心中仍然有一席之地，我认为它依然是一个好的语言，可能很多人有异议，但是我认为它简单易上手、稳定变化慢，相关工具也很容易上手。Node.js相对来说，比较复杂；Node社区也意识到这个问题，并且正在改进。比如说，当时我选择了Ruby重写Kibana，是因为Logstash是用JRuby写的，Elasticsearch 使用Java写的（JRuby可以理解为Ruby可以跑在JVM里面）。当时想把 Kibana 的 Ruby那个版本是因为想放到Logstash中，但是没有成功。所以，接下来我们研发了Kibana 3 。
在开发Kibana之前，我用过Graphite，但是为什么依然不满足呢？首先，Graphite很棒，所有关于数字、指标、时间序列的事情。但是那个时候，我需要的是一个可以做日志搜索的东西，需要有一个Dashboard可以给出一个图片。我非常希望从日志中获得信息并且把它们和预定的指标绑定在一起，实际上这些幕后工作都是Elasticsearch做的，并且速度真的快很多。此外需要考虑到扩展性，Graphite对于它适合的大小还算可以，即使超过了极限，更多的数据对应着更多的CPU消耗；但是想扩展很多的话，就很困难了，这一点上Graphite还有很多可以提升的空间，Elastic Stack就可以很轻松地实现。
不过，我依然很喜欢Graphite，我也依然认为这是一个有需求的工具，并且它其实是可以和Elasticsearch、Kibana结合在一起使用的。Architecture dependent的问题困扰了很多人， 比如32bit和64bit两者之间，即便是传输一个文件也不能工作，这是一个非常可怕的事情。Graphite 解决了这个问题，并且界面很美，功能强大 。Kibana也解决了很多相似的问题， 尤其是加上了Elasticsearch的配合，解决了许多我在做运维工作时总是非常想做的工作。
从来没有犹豫过是否开源
12岁的时候就开始接触开源项目了，所以在写Kibana的时候从来没有犹豫过要不要把它开源。
开始的时候我们只是把需求写在纸上，然后一条条做。放到Github之后，看到下载量不断上升我们感到很吃惊。我们没有想到，原来这么多人都面临这同样的问题，没有想到大家对这样的一个开源项目如此需要。开源的目的就是为了能帮助人们，最初我也曾疑惑有可能根本没有人用；然后发现越来越多的人在讨论、使用它。现在Elastic Stack是一个开源整体，把个人的事业career放在服务其他人的开源项目上，并能收获到好的反馈，这让我们感到很开心、很欣慰。
当时的小愿望，现在的大公司
Kibana第一版存在仅仅几周。是因为我开始使用Ruby进行重写，这大概花费了两周的时间。因为Logstash使用Ruby写的（即便当时我并不会Ruby），而我的目的就是让Kibana适配Logstash和Elasticsearch，让三者在一起可以协作获得更多的信息。当时我的想法就是让三个工具可以无缝衔接起来好似一个工具一样，有趣的是，这仅仅是当时我自己的一个愿望，后来Elasticsearch的人联系我问要不要合并在成为同一家公司，我们才发现彼此的看法竟然不谋而合。
我现在依然是on call的。在 Elastic 公司，我们有on call轮班制。其实这是与用户交流的机会，这是我们 Elastic 每一个开发者都非常珍视的机会。在对用户支持的过程中，我们可以更清晰地了解用户的需求和真实使用情况；还有一些其他方式，比如会议、沙龙、见面会等，任何可以帮助我们与社区连接的。在我看来，在用户发生问题时，你在他身边并且帮助修复问题：没有比这个更好的工作方式。所以，on call不是折磨，是机会。
Kibana的下一步：数据挖掘、角色报表
1、数据挖掘，精益求精
最开始在做日志分析的那个时候，坦率地讲，我并没有关联到了Data mining。因为那时只是想先把问题弄清楚。但是在把所有的问题都解决完（这些并不难，只是花时间而已），实现了最初我们想要的Kibana之后，运维的工作量就大大减少了。
一切都运转得很顺利之后，我们开始思考怎样能把事情做得越来越好，尽量少地产生问题。我们可以获得数据，并且发现了一些问题发生的规律：问题的发生节点，比如说往往半夜三点、发布新版本之后；问题的发生频率，哪些问题非常热门，我们需要把对应的工作放在CDN上；问题的优化处理，发生问题之后如何最快地回滚。机器学习很强有力，而且对于运维人员而言，越少的红色提示越幸福。但是目前我的考虑是，能做到提前预警就已经很棒了。
基于这些思考，我们认为需要开始进行数据挖掘的工作了，这样才把事情做得越来越好，才能更大程度地帮助公司用户。在五六年前，很少会有人想到运维团队可以给出商业业务的指导意见，但是现在这开始越来越普遍。
2、接下来，Dashboard不会只有public一种
此前Kibana的Dashboard是完全公开的，没有角色区分。我知道一些其他的工具提供了包边权限区分的功能。最初的时候，只是想保持事情的简单化，Kibana并没有考虑到把Dashboard做成基于角色的，我们考虑更多的是产品易用性、功能，而没有打算触及安全模块。对于我们自己而言，这并不是过去那些年优先级第一的事项。最开始Kibana的主要矛盾是怎样把内容展现出来，打造Elasticsearch的良好用户界面，所以那个时候是界面是对所有用户可见的。而权限的控制我们是在Elasticsearch上面实现的，搜索、索引、集群操作添加是在Elasticsearch，也就是说我们首先Elasticsearch中实现数据层的安全。
接下来，我们考虑怎样把安全性延展到Kibana中，对不同角色进行区分化的搜索展示。（此前，有一个插件可以满足在Kibana中进行 Elasticsearch 用户的控制。代码是开源的，任何公司都可以编写自己的安全模块，并且我们也乐意帮助他们）在决定做一件事情之后我们就希望把一件事情做得非常好，而不是半途而废。
Kibana in Elastic Stack 5.0
研发情况
研发出新功能的第一版本通常很快，但是需要不断的测试确保所有运转正常。Elastic Stack5.0 的所有功能大概花费了9个月的研发时间。在决策哪些功能需要研发时，我们有几周的考虑时间，还会参考社区中的反馈。然后我们还会给开发者一些自主空间，我们试着避免总是给某些人下发某些任务。我们认为最好主意并不来自与管理层或者经理，而是来自于那些与用户交流频繁的软件工程师，花费很多时间做客户支持的同事。会面通常是远程的，因为我们是个分布式的公司，公司成员分布于30多个国家，一共470多人。Kibana部分的研发、测试和运营人员一共有20多人。
如果有两个程序员所做的事情是一样的话，没有关系这不是重复劳动，反而可以让产品更加优化，两个人可以互相讨论加速功能研发；否则的话产品会被程序员打上过强的个人烙印，最终让产品交付给客户的是整个团队。
会一直并且只是配合Elasticsearch
是的，我们没有其他 datasource 的计划，因为我们大部分的使用case是要有时间序列的。
最开始融合在一起的是 Elasticsearch 和 Logstash，然后 Kibana 参与进来。在这个融合的过程中，遇到任何冲突或者改变，我们的评判标准都是怎样对用户而言更友好。举例说明，安全问题最佳的解决是在数据层，搜索非常占用内存，使用ES可以做很复杂的事情，在旧版本的 Kibana 中，可以使用 Elasticsearch 的 API，但是这拖缓了速度，并且用户可能会做一些危险的事情。在 Kibana 和 Elasticsearch 融合之后，我再也没有那样做了，对于一些重的内存需求工作不会在UI层（Kibana）而是会放到数据层（ES），用最少的内存，让尽可能多的计算脱离 JVM heap ，放入socket breaker，让我们管理更简洁干净并做到在UI可追踪。
Kibana的美学
Kibana最初的设计师只是我一个人，现在当然我们有了自己的很优秀的设计师，这是很被看重的部分，没有外包出去。因为我们需要和设计团队频繁地交流，不断地给予反馈，和工程团队。这是我们公司文化的一个重要部分。
你想一想这是运维人员需要终日面对的工具，没有人愿意一直看着丑的东西；此外，也希望Kibana可以让运维人员的boss们感到惊艳，我们希望可以帮助使用者产生非常美的工作。
写在最后
在采访结束时，InfoQ问Rashid是否可以给广大读者一些建议，Rashid想了想说：
如果你有一个想法，把它code出来，build起来。不要等其他人的开源代码，有可能你会等到，但是有可能你永远等不到。在你写出来之后，你没准会收获惊喜。
收起阅读 »
medcl 发表于 : 2017-01-11 11:45
评论 (2)
Elasticsearch 2.x mapping tips
elasticsearch 2.x mapping tips
作者：杨振涛 首发于：Elasticsearch 中文社区 日期：2017-1-10
如果把elasticsearch中的mapping类比为关系型数据库中的schema的话，那么我们可能重点强调了两者之间的共性，而忽略了elasticsearch里mapping很不相同的部分 —— 这恰恰是实践中最容易被坑的地方。这里总结了几点实践中的小心得，希望对你所有帮助。
mapping 基础
创建索引库index
查看指定索引库的mapping:
PS: 这时你获得的结果为空，因为刚建的库，没有mapping信息。
创建索引类型type并指定mapping :
更新mapping （只能增加字段，不能删除字段，也不能修改字段类型，或者说无法增加一个不同类型的同名字段）:
增加属性 score：
更新成功会返回：
删除mapping :
2.4版本开始ES已经不支持mapping的删除了。
tip1 dynamic 模式
动态mapping是ES的一个重要特性，这个配置的可选值及含义如下：
tip2 主要数据类型及注意事项
分词和不分词的值都需要，中英文都需要 ，
长度截取，超长过滤 ，
大小写问题（不分词时索引数据不会转小写，搜索都会转小写）
analyzer: analyzed, not_analyzed, no（表示该属性不能用来做搜索和聚合）
properties ： .raw, .en/.cn
tip3 id设置
在不设置id的情况下，默认的ES会给一个类似HASH串的随机ID；如果业务上需要且可以保证索引数据的唯一性，也可以使用业务ID作为索引ID，好处就是可以根据业务ID轻松地GET到索引数据，而无需维护索引ID和业务ID的关系。
同时，设置mapping的时候也可以指定ID的生成策略，比如UUID：
tip4 index和type规划
index的别名这个特性就不再强调了，不管是否用到，第一时间设置别名是最佳实践！ schema 比较相似的type，放在同一个index里；schema差异非常大的type，建议放在不同的index里；原因是跟搜索引擎的segment以及lucene有关，本质上同一个index里的type底层是同样的存储结构，差异越大意味着type a的属性在type b里大部分都是空值，那么最终会得到一个非常稀疏的矩阵，影响计算效率并浪费存储空间。
关于滚动index的问题，对于日志类的搜索应用，按天或其他维度做滚动index是非常好必要的，这样可以更好地区分冷热数据。比如：
如果只需要查询最近3天的数据，那么只需要对3天前的index remove alias即可，然后每天循环滚动。一个细节是，对于这种场景下的索引，写入的时候必须使用原始的index name，而不能使用alias；查询的时候则使用alias。
另一个问题，就是index容量的规划，副本数直接决定需要多少冗余空间；另外，索引数据本身也会有膨胀的现象，尤其是基于中文的全文搜索应用，term集可能会比较大。比如有10000个docs，占用100MB空间时，并不能简单认为100000个docs就占用约1GB。
tip5 测试分词器
如果使用的是基于词典的分词器，比如IK这类，那么线上系统可能会需要按需添加自定义词，或者同义词等，技术上我们可以暴露该类功能给搜索引擎运营人员使用。所以，需要提供一个测试分词器的接口，方便对比和验证。ES默认就提供这样的REST接口的。
按指定分词器分词指定文本：
按指定索引库的属性测试分词效果：
以上关于 mapping 的几点心得，并非金科玉律，需要根据不同的业务需求场景来区别分析和应对。如果你有更多心得，欢迎回复本文分享。
关于作者：
杨振涛，vivo移动互联网 搜索架构师，关注实时搜索，搜索广告，以及大数据的存储、索引、搜索和可视化。
继续阅读 »
作者：杨振涛 首发于：Elasticsearch 中文社区 日期：2017-1-10
如果把elasticsearch中的mapping类比为关系型数据库中的schema的话，那么我们可能重点强调了两者之间的共性，而忽略了elasticsearch里mapping很不相同的部分 —— 这恰恰是实践中最容易被坑的地方。这里总结了几点实践中的小心得，希望对你所有帮助。
mapping 基础
创建索引库index
curl -XPOST "http://192.168.9.19:9200/vivo_vimc"查看指定索引库的mapping:
curl -XGET "http://192.168.9.19:9200/vivo_ ... ot%3B
PS: 这时你获得的结果为空，因为刚建的库，没有mapping信息。
创建索引类型type并指定mapping :
curl -XPOST http://192.168.9.19:9200/vivo_vmic/apps/_mapping -d '{
"apps" : {
"properties" : {
"appName" : {
"type" : "string",
"index" : "not_analyzed",
"fields" :{
"cn": {
"type" : "string",
"index" : "analyzed",
"analyzer": "ik"
},
"en": {
"type" : "string",
}
},
"store":"yes"
},
"status" : {
"type" : "boolean"
},
"type" : {
"type" : "integer"
},
"onsaleDate" : {
"type" : "date"
},
}
}
}'更新mapping （只能增加字段，不能删除字段，也不能修改字段类型，或者说无法增加一个不同类型的同名字段）:
增加属性 score：
curl -XPOST "http://192.168.9.19:9200/vivo_ ... ot%3B -d '{
"apps": {
"properties": {
"score":{
"type":"float"
}
}
}
}'更新成功会返回：
{
"acknowledged" : true
}删除mapping :
2.4版本开始ES已经不支持mapping的删除了。
tip1 dynamic 模式
动态mapping是ES的一个重要特性，这个配置的可选值及含义如下：
- true ：支持动态扩展，新增数据有新的属性时，自动添加，索引成功
- false ：不支持动态扩展，新增数据有新的属性时，直接忽略，索引成功
- strict: 不支持动态扩展，新增数据有新的属性时，会报错，索引失败
tip2 主要数据类型及注意事项
- string
分词和不分词的值都需要，中英文都需要 ，
长度截取，超长过滤 ，
大小写问题（不分词时索引数据不会转小写，搜索都会转小写）
analyzer: analyzed, not_analyzed, no（表示该属性不能用来做搜索和聚合）
properties ： .raw, .en/.cn
- date : 如果不明确指定，那么默认的date格式是："strict_date_optional_time||epoch_millis"，这是官网的表述，意思是可以是一个字符串类型的输入，也可以是数值类型的输入，前者可以是日期或者日期加上时间，后者则是毫秒数。关于时区信息：不管业务上是否需要时区信息，我们建议依然保存，以防万一。另外，data类型在明确指定 format 参数时，也有很多坑，对于format: epoch_second, epools_millis ,如果你想用来排序，那么为了性能，我们强烈建议你使用 epoc_second，差距很大哟，你可以亲自做一个对比测试。
- long, integer, short, byte, double ,float 希望此类字段参与搜索和聚合的话，就不能设置not_analyzed。
- boolean, binaryboolean类型比较特殊，在ES里面只定义了false类的值（ false, "false", "off", "no", "0", "" , 0, 0.0 ），其他所有都认为是true。实践中，我们建议优先使用 0（编程和性能友好），其次使用 true（兼容json默认的类型）。
- ipv4 type:ip 日志分析等最常用的数据类型，注意这里的是ipv4，ipv6目前暂不支持（ES 2.x）；赋值时其实传递的是字符串，但ES内部其实保存的是一个long类型。
- geo type:geo_point ， type:geo_shape LBS服务的必选数据类型，但不建议完全依赖此特性，业务层面要尽可能地缩小范围，或者在使用围栏类功能时，只要业务容忍，使用正方形代替圆形。
- 数组，对象，内嵌将一个复杂对象放在一个属性中，其中数组最常用。
- completion主要是用来做自动完成和拼写纠错的。
tip3 id设置
在不设置id的情况下，默认的ES会给一个类似HASH串的随机ID；如果业务上需要且可以保证索引数据的唯一性，也可以使用业务ID作为索引ID，好处就是可以根据业务ID轻松地GET到索引数据，而无需维护索引ID和业务ID的关系。
同时，设置mapping的时候也可以指定ID的生成策略，比如UUID：
curl -s -XPUT http://192.168.9.19:9200/vivo_vimc -d '
{
"mappings": {
"apps": {
"_id": {
"path": "uuid"
},
"properties": {
"cnName": {
"type": "string",
"index": "analyzed"
}
}
}
}
}'tip4 index和type规划
index的别名这个特性就不再强调了，不管是否用到，第一时间设置别名是最佳实践！ schema 比较相似的type，放在同一个index里；schema差异非常大的type，建议放在不同的index里；原因是跟搜索引擎的segment以及lucene有关，本质上同一个index里的type底层是同样的存储结构，差异越大意味着type a的属性在type b里大部分都是空值，那么最终会得到一个非常稀疏的矩阵，影响计算效率并浪费存储空间。
关于滚动index的问题，对于日志类的搜索应用，按天或其他维度做滚动index是非常好必要的，这样可以更好地区分冷热数据。比如：
index alias
vivo_appstore_log_20160108
vivo_appstore_log_20160109 vivo_appstore_log
vivo_appstore_log_20160110 vivo_appstore_log
vivo_appstore_log_20160111 vivo_appstore_log
...
如果只需要查询最近3天的数据，那么只需要对3天前的index remove alias即可，然后每天循环滚动。一个细节是，对于这种场景下的索引，写入的时候必须使用原始的index name，而不能使用alias；查询的时候则使用alias。
另一个问题，就是index容量的规划，副本数直接决定需要多少冗余空间；另外，索引数据本身也会有膨胀的现象，尤其是基于中文的全文搜索应用，term集可能会比较大。比如有10000个docs，占用100MB空间时，并不能简单认为100000个docs就占用约1GB。
tip5 测试分词器
如果使用的是基于词典的分词器，比如IK这类，那么线上系统可能会需要按需添加自定义词，或者同义词等，技术上我们可以暴露该类功能给搜索引擎运营人员使用。所以，需要提供一个测试分词器的接口，方便对比和验证。ES默认就提供这样的REST接口的。
按指定分词器分词指定文本：
GET /vivo_vimc/apps/_analyze?text=Hello, vivo 移动互联网&analyzer=ik按指定索引库的属性测试分词效果：
GET /vivo_vimc/apps/_analyze
{
"field": "appName",
"text": "Pokemon Go"
}以上关于 mapping 的几点心得，并非金科玉律，需要根据不同的业务需求场景来区别分析和应对。如果你有更多心得，欢迎回复本文分享。
关于作者：
杨振涛，vivo移动互联网 搜索架构师，关注实时搜索，搜索广告，以及大数据的存储、索引、搜索和可视化。
elasticsearch 2.x mapping tips
作者：杨振涛 首发于：Elasticsearch 中文社区 日期：2017-1-10
如果把elasticsearch中的mapping类比为关系型数据库中的schema的话，那么我们可能重点强调了两者之间的共性，而忽略了elasticsearch里mapping很不相同的部分 —— 这恰恰是实践中最容易被坑的地方。这里总结了几点实践中的小心得，希望对你所有帮助。
mapping 基础
创建索引库index
查看指定索引库的mapping:
PS: 这时你获得的结果为空，因为刚建的库，没有mapping信息。
创建索引类型type并指定mapping :
更新mapping （只能增加字段，不能删除字段，也不能修改字段类型，或者说无法增加一个不同类型的同名字段）:
增加属性 score：
更新成功会返回：
删除mapping :
2.4版本开始ES已经不支持mapping的删除了。
tip1 dynamic 模式
动态mapping是ES的一个重要特性，这个配置的可选值及含义如下：
tip2 主要数据类型及注意事项
分词和不分词的值都需要，中英文都需要 ，
长度截取，超长过滤 ，
大小写问题（不分词时索引数据不会转小写，搜索都会转小写）
analyzer: analyzed, not_analyzed, no（表示该属性不能用来做搜索和聚合）
properties ： .raw, .en/.cn
tip3 id设置
在不设置id的情况下，默认的ES会给一个类似HASH串的随机ID；如果业务上需要且可以保证索引数据的唯一性，也可以使用业务ID作为索引ID，好处就是可以根据业务ID轻松地GET到索引数据，而无需维护索引ID和业务ID的关系。
同时，设置mapping的时候也可以指定ID的生成策略，比如UUID：
tip4 index和type规划
index的别名这个特性就不再强调了，不管是否用到，第一时间设置别名是最佳实践！ schema 比较相似的type，放在同一个index里；schema差异非常大的type，建议放在不同的index里；原因是跟搜索引擎的segment以及lucene有关，本质上同一个index里的type底层是同样的存储结构，差异越大意味着type a的属性在type b里大部分都是空值，那么最终会得到一个非常稀疏的矩阵，影响计算效率并浪费存储空间。
关于滚动index的问题，对于日志类的搜索应用，按天或其他维度做滚动index是非常好必要的，这样可以更好地区分冷热数据。比如：
如果只需要查询最近3天的数据，那么只需要对3天前的index remove alias即可，然后每天循环滚动。一个细节是，对于这种场景下的索引，写入的时候必须使用原始的index name，而不能使用alias；查询的时候则使用alias。
另一个问题，就是index容量的规划，副本数直接决定需要多少冗余空间；另外，索引数据本身也会有膨胀的现象，尤其是基于中文的全文搜索应用，term集可能会比较大。比如有10000个docs，占用100MB空间时，并不能简单认为100000个docs就占用约1GB。
tip5 测试分词器
如果使用的是基于词典的分词器，比如IK这类，那么线上系统可能会需要按需添加自定义词，或者同义词等，技术上我们可以暴露该类功能给搜索引擎运营人员使用。所以，需要提供一个测试分词器的接口，方便对比和验证。ES默认就提供这样的REST接口的。
按指定分词器分词指定文本：
按指定索引库的属性测试分词效果：
以上关于 mapping 的几点心得，并非金科玉律，需要根据不同的业务需求场景来区别分析和应对。如果你有更多心得，欢迎回复本文分享。
关于作者：
杨振涛，vivo移动互联网 搜索架构师，关注实时搜索，搜索广告，以及大数据的存储、索引、搜索和可视化。 收起阅读 »
作者：杨振涛 首发于：Elasticsearch 中文社区 日期：2017-1-10
如果把elasticsearch中的mapping类比为关系型数据库中的schema的话，那么我们可能重点强调了两者之间的共性，而忽略了elasticsearch里mapping很不相同的部分 —— 这恰恰是实践中最容易被坑的地方。这里总结了几点实践中的小心得，希望对你所有帮助。
mapping 基础
创建索引库index
curl -XPOST "http://192.168.9.19:9200/vivo_vimc"查看指定索引库的mapping:
curl -XGET "http://192.168.9.19:9200/vivo_ ... ot%3B
PS: 这时你获得的结果为空，因为刚建的库，没有mapping信息。
创建索引类型type并指定mapping :
curl -XPOST http://192.168.9.19:9200/vivo_vmic/apps/_mapping -d '{
"apps" : {
"properties" : {
"appName" : {
"type" : "string",
"index" : "not_analyzed",
"fields" :{
"cn": {
"type" : "string",
"index" : "analyzed",
"analyzer": "ik"
},
"en": {
"type" : "string",
}
},
"store":"yes"
},
"status" : {
"type" : "boolean"
},
"type" : {
"type" : "integer"
},
"onsaleDate" : {
"type" : "date"
},
}
}
}'更新mapping （只能增加字段，不能删除字段，也不能修改字段类型，或者说无法增加一个不同类型的同名字段）:
增加属性 score：
curl -XPOST "http://192.168.9.19:9200/vivo_ ... ot%3B -d '{
"apps": {
"properties": {
"score":{
"type":"float"
}
}
}
}'更新成功会返回：
{
"acknowledged" : true
}删除mapping :
2.4版本开始ES已经不支持mapping的删除了。
tip1 dynamic 模式
动态mapping是ES的一个重要特性，这个配置的可选值及含义如下：
- true ：支持动态扩展，新增数据有新的属性时，自动添加，索引成功
- false ：不支持动态扩展，新增数据有新的属性时，直接忽略，索引成功
- strict: 不支持动态扩展，新增数据有新的属性时，会报错，索引失败
tip2 主要数据类型及注意事项
- string
分词和不分词的值都需要，中英文都需要 ，
长度截取，超长过滤 ，
大小写问题（不分词时索引数据不会转小写，搜索都会转小写）
analyzer: analyzed, not_analyzed, no（表示该属性不能用来做搜索和聚合）
properties ： .raw, .en/.cn
- date : 如果不明确指定，那么默认的date格式是："strict_date_optional_time||epoch_millis"，这是官网的表述，意思是可以是一个字符串类型的输入，也可以是数值类型的输入，前者可以是日期或者日期加上时间，后者则是毫秒数。关于时区信息：不管业务上是否需要时区信息，我们建议依然保存，以防万一。另外，data类型在明确指定 format 参数时，也有很多坑，对于format: epoch_second, epools_millis ,如果你想用来排序，那么为了性能，我们强烈建议你使用 epoc_second，差距很大哟，你可以亲自做一个对比测试。
- long, integer, short, byte, double ,float 希望此类字段参与搜索和聚合的话，就不能设置not_analyzed。
- boolean, binaryboolean类型比较特殊，在ES里面只定义了false类的值（ false, "false", "off", "no", "0", "" , 0, 0.0 ），其他所有都认为是true。实践中，我们建议优先使用 0（编程和性能友好），其次使用 true（兼容json默认的类型）。
- ipv4 type:ip 日志分析等最常用的数据类型，注意这里的是ipv4，ipv6目前暂不支持（ES 2.x）；赋值时其实传递的是字符串，但ES内部其实保存的是一个long类型。
- geo type:geo_point ， type:geo_shape LBS服务的必选数据类型，但不建议完全依赖此特性，业务层面要尽可能地缩小范围，或者在使用围栏类功能时，只要业务容忍，使用正方形代替圆形。
- 数组，对象，内嵌将一个复杂对象放在一个属性中，其中数组最常用。
- completion主要是用来做自动完成和拼写纠错的。
tip3 id设置
在不设置id的情况下，默认的ES会给一个类似HASH串的随机ID；如果业务上需要且可以保证索引数据的唯一性，也可以使用业务ID作为索引ID，好处就是可以根据业务ID轻松地GET到索引数据，而无需维护索引ID和业务ID的关系。
同时，设置mapping的时候也可以指定ID的生成策略，比如UUID：
curl -s -XPUT http://192.168.9.19:9200/vivo_vimc -d '
{
"mappings": {
"apps": {
"_id": {
"path": "uuid"
},
"properties": {
"cnName": {
"type": "string",
"index": "analyzed"
}
}
}
}
}'tip4 index和type规划
index的别名这个特性就不再强调了，不管是否用到，第一时间设置别名是最佳实践！ schema 比较相似的type，放在同一个index里；schema差异非常大的type，建议放在不同的index里；原因是跟搜索引擎的segment以及lucene有关，本质上同一个index里的type底层是同样的存储结构，差异越大意味着type a的属性在type b里大部分都是空值，那么最终会得到一个非常稀疏的矩阵，影响计算效率并浪费存储空间。
关于滚动index的问题，对于日志类的搜索应用，按天或其他维度做滚动index是非常好必要的，这样可以更好地区分冷热数据。比如：
index alias
vivo_appstore_log_20160108
vivo_appstore_log_20160109 vivo_appstore_log
vivo_appstore_log_20160110 vivo_appstore_log
vivo_appstore_log_20160111 vivo_appstore_log
...
如果只需要查询最近3天的数据，那么只需要对3天前的index remove alias即可，然后每天循环滚动。一个细节是，对于这种场景下的索引，写入的时候必须使用原始的index name，而不能使用alias；查询的时候则使用alias。
另一个问题，就是index容量的规划，副本数直接决定需要多少冗余空间；另外，索引数据本身也会有膨胀的现象，尤其是基于中文的全文搜索应用，term集可能会比较大。比如有10000个docs，占用100MB空间时，并不能简单认为100000个docs就占用约1GB。
tip5 测试分词器
如果使用的是基于词典的分词器，比如IK这类，那么线上系统可能会需要按需添加自定义词，或者同义词等，技术上我们可以暴露该类功能给搜索引擎运营人员使用。所以，需要提供一个测试分词器的接口，方便对比和验证。ES默认就提供这样的REST接口的。
按指定分词器分词指定文本：
GET /vivo_vimc/apps/_analyze?text=Hello, vivo 移动互联网&analyzer=ik按指定索引库的属性测试分词效果：
GET /vivo_vimc/apps/_analyze
{
"field": "appName",
"text": "Pokemon Go"
}以上关于 mapping 的几点心得，并非金科玉律，需要根据不同的业务需求场景来区别分析和应对。如果你有更多心得，欢迎回复本文分享。
关于作者：
杨振涛，vivo移动互联网 搜索架构师，关注实时搜索，搜索广告，以及大数据的存储、索引、搜索和可视化。 收起阅读 »
