2018 年 Elastic Advent Calendar 分享活动已结束 ??
medcl 发表了文章 • 44 个评论 • 8419 次浏览 • 2018-11-20 22:33
活动规则很简单：
活动创意来自于圣诞节倒计时，从12月1号开始到12月25日结束。
每天固定一篇文章分享，内容长短都可。
报名现在开始，留言报名即可，留言格式： Day[日期] - 你的分享标题。
一共25篇，报满即止。
虽然是西方的节日，不过目的是为了大家一起分享，重在参与嘛。
往期活动可参考：https://elasticsearch.cn/topic/advent
活动参与名单：
如何发布？
自己选择发布文章，按你的标题在12月你的这一天发布出来就好了。
活动创意来自于圣诞节倒计时，从12月1号开始到12月25日结束。
每天固定一篇文章分享，内容长短都可。
报名现在开始，留言报名即可，留言格式： Day[日期] - 你的分享标题。
一共25篇，报满即止。
虽然是西方的节日，不过目的是为了大家一起分享，重在参与嘛。
往期活动可参考：https://elasticsearch.cn/topic/advent
活动参与名单：
- Day 1 - ELK 使用小技巧 - @rochy
- Day 2 - ES 6.x拼音分词高亮爬坑记 - @abia
- Day 3 - kibana二次开发tips - @vv
- Day 4 - PB级规模数据的Elasticsearch分库分表实践 - @ouyangchucai
- Day 5 - es存储设备全解析 - @cyberdak
- Day 6 - 上手 Logstash Pipeline to Pipeline 特性 - @rockybean
- Day 7 - Elasticsearch中数据是如何存储的 - @weizijun
- Day 8 - 如何使用Spark快速将数据写入Elasticsearch - @Ricky Huo
- Day 9 - 动手实现一个自定义beat - @Xinglong
- Day 10 - Elasticsearch 分片恢复并发数过大引发的bug分析 - @howardhuang
- Day 11 - Elasticsearch 5.x 6.x父子关系维护检索实战 - @yinbp
- Day 12 - Elasticsearch日志场景最佳实践 - @ginger
- Day 13 - Elasticsearch-Hadoop打通Elasticsearch和Hadoop - @Jasonbian
- Day 14 - 订单中心基于elasticsearch 的解决方案 - @blogsit
- Day 15 - 基于海量公司分词ES中文分词插件 - @novia
- Day 16 - Elasticsearch性能调优 - @白衬衣
- Day 17 - 关于日志型数据管理策略的思考 - @kennywu76
- Day 18 - 记filebeat内存泄漏问题分析及调优 - @点火三周
- Day 19 - 通过点击反馈优化es搜索结果排序 - @laigood
- Day 20 - Elastic性能实战指南 - @laoyang360
- Day 21 - ECE 版本升级扫雷实战 - @Ben_Wu
- Day 22 - 熟练使用ES离做好搜索还差多远 - @nodexy
- Day 23 - 基于 HanLP 的 ES 中文分词插件 - @rochy
- Day 24 - predator捕捉病毒样本 - @swordsmanli
- Day 25 - Elasticsearch Ingest节点数据管道处理器 - @bindiego
如何发布？
自己选择发布文章，按你的标题在12月你的这一天发布出来就好了。
Day 14: Elasticsearch 5 入坑指南
kennywu76 发表了文章 • 33 个评论 • 28123 次浏览 • 2016-12-15 13:16
尝鲜
10月26日，Elasticsearch5.0.0 GA终于放出，携程ES Ops团队也在第一时间在DEV和UAT环境分别进行了2.4.0 至5.0.0的升级和测试。升级完成后，除了部分Query不向前兼容（主要是Filtered Query)，需要在应用端做一些修改以外，未发现其他问题。通过监控系统看对比升级前后的主要系统指标，在同等索引量的情况下，CPU使用率有明显下降 ( 30% - 50%左右) ，相信性能方面5.0应该是有较大提升的。
在测试环境稳定运行了2周以后，我们决定选定一个生产集群进行升级，考验新版本在更为复杂的用户环境下的表现。 出于对业务影响最小化的考虑，用于日志分析的集群被圈定为升级目标。该集群也是携程十几个集群中规模最大的一个，共有120个数据结点运行于70台物理机上，总数据量接近1PB。
升级前需要做一些准备工作，下载官方的Migration Helper插件，检查集群设置和索引的兼容性。对于不兼容的配置项，MH会详尽列出，其中标注为红色部分为为升级前必须修改项。1.x版本创建的索引，是无法直接升级到5的，需要先在2.x集群里做一次reindex 。 MH提供了不兼容索引扫描功能，对于找到的不兼容索引，可以直接在UI上发起reindex操作，等待结束即可。 如果是用于业务搜索集群，数据可能比较重要，建议升级前做一个Snapshot，万一升级过程出现意外，可以回退版本从备份里快速恢复数据。我们的日志集群数据量极大，也没有对数据100%不丢的要求，因此升级前没有做Snapshot。 做完所有的准备工作后，预先通知所有用户集群升级的时间以及可能产生的影响，选定了周五深夜用户低峰期，开始正式升级工作。
首先通过Ansible将新版本批量部署到所有结点并统一配置，紧接着对原有集群做了Full Stop，校验所有的ES已经停下后，开始Full Start。整个过程比较顺利，所有结点正常启动，数据恢复完成后，集群重新回到正常服务状态。
周末两天运行，未发现有任何的异样，CPU利用率也降了不少，看起来很靠谱……直到周一
踏坑
周一早上，随着用户访问量高峰来临，马上浮现出一个诡异的现象： 索引速率遇到了瓶颈，数据开始在前置的消息队列(Kafka)里堆积。 从监控数据看，尽管所有的数据结点CPU消耗都比上周同期低，磁盘IO也很低，但索引速率却低了很多。反复对比查看升级前后各类监控指标后，终于发现一个可疑点，所有结点的网络流量比升级前高了好几倍！ 在集群架构上，我们是单独架设了几台client node做为数据写入和分发的入口，现在这几个node的网络流量已经饱和，成为数据写入的瓶颈。一开始，怀疑是否2.4启用了tcp压缩，而5.0取消了，但翻查官方文档后发现transport.tcp.compress在2.4和5.0里默认都是关闭的！ 这时候只有两个解决办法了，要么启用tcp压缩，要么扩容client node。 先考虑了一下tcp压缩的方案，快速扒了一下ES源码，在transport.TcpTransport这个类里，sendRequest和sendResponse两个方法会根据transport.tcp.compress设置来决定发送的消息是否要经过压缩，而在messageReceived方法则会读取消息头部的状态信息，探测消息是否经过压缩以及压缩的方法，而后决定是否需要解压，以及采用的解压方式。 这样看起来，ES是允许tcp压缩和不压缩的结点之间通讯的，那么只对client node启用压缩应该就可以了。测试环境测试过后，验证了想法的可行性。于是对生产的client node开启tcp压缩，同时在数据发送端(hangout的ES output)也启用tcp压缩，重启client node后入口网络流量降到和之前2.4差不多的程度，问题得到规避。 针对这个问题在Github上提交了issue https://github.com/elastic/ela ... 21612， 但未得到官方合理的解释。
解决好这个问题，另外一个问题来了，很多执行大量历史数据搜索的用户反映出不了结果。 从监控数据看，这类查询的搜索耗时非常久，直到网关300秒超时（查询api前置的nginx代理)。我们之前对集群设置过Global Search timeout为60s，用来保护集群资源过多被超高代价的查询消耗，在2.4版本是有效果的，现在看来不起作用了。手动测试了一下，这个参数果然失效！ 于是向官方报告了第2个问题：https://github.com/elastic/ela ... 21595 。 这个问题很快被官方确认为Bug，修复也很快加入到了5.0.2。 为了规避这个问题，我们只好临时修改了一下Kibana以及第三方API访问要经过的nginx proxy，默认为所有的search request加入一个超时选项。此后，问题有一些缓解，但仍然发现用户查询大范围历史数据时，部分用于存储历史数据的结点响应很慢。
我们的集群是做了冷热分离的结构的，热节点主要承担写入和存放过去24小时数据，冷结点没有写入，查询频率也低，所以为了最大化利用硬件资源，一台物理机上跑了3个实例，这样一台128GB内存的机器可以存放下近30TB的索引。查看冷结点的监控数据，看到用户查询期间磁盘的read IO非常高，直接将磁盘IO Util%撑到100%，并且可持续数小时，同时search thread pool有大量的active thread处于无法完成状态，search queue不断攀升直至饱和、开始reject。 表象上看search thread似乎一直在尝试从磁盘大量读取数据，一次search甚至可以持续几十分钟至一个小时，耗尽了所有的搜索线程，导致拒绝后续的搜索服务。 于是Github上报了第3个issue: https://github.com/elastic/ela ... 21611 这个问题找到解决办法之前，我们只能通过反复重启有问题的冷结点来缓解。 和官方讨论过程中，得知5.0在Lucene文件访问方式上有一个比较大的改动，2.4使用mmapfs读取索引文件的部分，而5.0以后改为用mmapfs读取索引文件的全部。怀疑问题和这个变动有关，尝试将所有索引文件的设置改为NIOFS后，问题迎刃而解。 搜索性能一下回到了2.4时代，再也没出现搜索线程超长时间执行的问题。之后找时间复现了这个问题，并抓取了线程栈，看到长时间执行的搜索线程一直在做Global Ordinal的构造工作。 至于为何会这样，还不清楚。 从官方给出的信息看，底层索引文件的访问模式是没有变化的，仅仅是将文件读取方式全部改成了mmapfs，理论上应该性能更好，但是看起来在我们这种一台机器跑多个ES实例，所有分配的heap为系统缓存3倍的极端用例下，大范围的数据搜索可能造成过高的磁盘读IO，集群性能指数级下降。
以上问题前后耗了4天才完全规避掉，支持团队连续熬夜后集群总算回复到平稳状态。然而好景不长，运行一段时间以后，数据结点出现疑似内存泄漏现象。结点总数据没怎么增加、甚至还有减少的情况下，heap使用率一只呈攀升趋势，Old GC无法回收内存。这个问题对用户影响较小，通过监控我们可以及时发现内存即将用尽的结点，做一次重启很快就恢复了。 为排查根源，我们对一个有问题的结点做了dump，通过MAT工具分析，看到meta data相关的一个alias对象被实例化了有6600万次之多！ 在Github上提交了第四个issue: https://github.com/elastic/ela ... 22013，不多久被确认为已知问题https://github.com/elastic/ela ... 21284 ,在5.0.1已经修复。
最后还存在一个master node内存泄漏的问题，这个问题在2.4.0时代就存在了，升级到5.0.0以后依然没有修复。由于我们的master node和data node是分离的，所以这个问题比较容易通过监控发现，解决方式也很简单和迅速，重启master node即可，对用户完全无影响。之后不久，5.0.2版本正式发布，release notes里提到了对这个问题的修复 https://github.com/elastic/ela ... 21578 。
上周周末我们将集群rolling upgrade到了5.0.2，global search timeout失效和两个内存泄漏的问题从根源上解决掉了。 网络流量增大的问题依然存在，仍然需要通过启用client结点的transport.tcp.compress规避。 冷结点搜索性能的问题没看到有提及，估计没解决，安全起见，还是保持索引的文件系统为NIOFS。升级完成运行一段时间后，可以肯定，5.0.2已经比较稳定。
心得
升到5.0.2后，对于其中一组数据结点这两天特意加了点索引负载，通过监控数据将v5.0.2与2.4.0做实际运行环境的索引吞吐量对比。
在近似的CPU使用率和load情况下，5.0.2能够支撑更大的吞吐量。另外5.0带来的Instant aggregation功能，对于跨多个索引的时序类型数据的聚合也可以有效Cache了，在使用Kibana的时候提速感觉非常明显。
升级过程虽然遇到很多波折，但由于集群架构上做了角色分离(client,master,data)和冷热分离，因而Bug引起的故障比较容易被限定在一个较小的范围而不至于影响所有的功能和所有的用户。 故障点定位更加容易，规避措施也更容易实施。 部分规避措施实施过程中甚至对用户是完全无影响的，比如: 重启内存泄漏的master node)。详尽的监控为问题的发现和诊断提供了有力的支持。
Elasticsearch是非常复杂的系统，官方的测试无法覆盖所有的用例场景和数据规模，一些极端的应用场景可能触发某个深藏的Bug或者缺陷而陷入困境。 因此对于稳定性要求极高的应用，最好还是采用经过长时间考验的版本，比如v2.4.2。
10月26日，Elasticsearch5.0.0 GA终于放出，携程ES Ops团队也在第一时间在DEV和UAT环境分别进行了2.4.0 至5.0.0的升级和测试。升级完成后，除了部分Query不向前兼容（主要是Filtered Query)，需要在应用端做一些修改以外，未发现其他问题。通过监控系统看对比升级前后的主要系统指标，在同等索引量的情况下，CPU使用率有明显下降 ( 30% - 50%左右) ，相信性能方面5.0应该是有较大提升的。
在测试环境稳定运行了2周以后，我们决定选定一个生产集群进行升级，考验新版本在更为复杂的用户环境下的表现。 出于对业务影响最小化的考虑，用于日志分析的集群被圈定为升级目标。该集群也是携程十几个集群中规模最大的一个，共有120个数据结点运行于70台物理机上，总数据量接近1PB。
升级前需要做一些准备工作，下载官方的Migration Helper插件，检查集群设置和索引的兼容性。对于不兼容的配置项，MH会详尽列出，其中标注为红色部分为为升级前必须修改项。1.x版本创建的索引，是无法直接升级到5的，需要先在2.x集群里做一次reindex 。 MH提供了不兼容索引扫描功能，对于找到的不兼容索引，可以直接在UI上发起reindex操作，等待结束即可。 如果是用于业务搜索集群，数据可能比较重要，建议升级前做一个Snapshot，万一升级过程出现意外，可以回退版本从备份里快速恢复数据。我们的日志集群数据量极大，也没有对数据100%不丢的要求，因此升级前没有做Snapshot。 做完所有的准备工作后，预先通知所有用户集群升级的时间以及可能产生的影响，选定了周五深夜用户低峰期，开始正式升级工作。
首先通过Ansible将新版本批量部署到所有结点并统一配置，紧接着对原有集群做了Full Stop，校验所有的ES已经停下后，开始Full Start。整个过程比较顺利，所有结点正常启动，数据恢复完成后，集群重新回到正常服务状态。
周末两天运行，未发现有任何的异样，CPU利用率也降了不少，看起来很靠谱……直到周一
踏坑
周一早上，随着用户访问量高峰来临，马上浮现出一个诡异的现象： 索引速率遇到了瓶颈，数据开始在前置的消息队列(Kafka)里堆积。 从监控数据看，尽管所有的数据结点CPU消耗都比上周同期低，磁盘IO也很低，但索引速率却低了很多。反复对比查看升级前后各类监控指标后，终于发现一个可疑点，所有结点的网络流量比升级前高了好几倍！ 在集群架构上，我们是单独架设了几台client node做为数据写入和分发的入口，现在这几个node的网络流量已经饱和，成为数据写入的瓶颈。一开始，怀疑是否2.4启用了tcp压缩，而5.0取消了，但翻查官方文档后发现transport.tcp.compress在2.4和5.0里默认都是关闭的！ 这时候只有两个解决办法了，要么启用tcp压缩，要么扩容client node。 先考虑了一下tcp压缩的方案，快速扒了一下ES源码，在transport.TcpTransport这个类里，sendRequest和sendResponse两个方法会根据transport.tcp.compress设置来决定发送的消息是否要经过压缩，而在messageReceived方法则会读取消息头部的状态信息，探测消息是否经过压缩以及压缩的方法，而后决定是否需要解压，以及采用的解压方式。 这样看起来，ES是允许tcp压缩和不压缩的结点之间通讯的，那么只对client node启用压缩应该就可以了。测试环境测试过后，验证了想法的可行性。于是对生产的client node开启tcp压缩，同时在数据发送端(hangout的ES output)也启用tcp压缩，重启client node后入口网络流量降到和之前2.4差不多的程度，问题得到规避。 针对这个问题在Github上提交了issue https://github.com/elastic/ela ... 21612， 但未得到官方合理的解释。
解决好这个问题，另外一个问题来了，很多执行大量历史数据搜索的用户反映出不了结果。 从监控数据看，这类查询的搜索耗时非常久，直到网关300秒超时（查询api前置的nginx代理)。我们之前对集群设置过Global Search timeout为60s，用来保护集群资源过多被超高代价的查询消耗，在2.4版本是有效果的，现在看来不起作用了。手动测试了一下，这个参数果然失效！ 于是向官方报告了第2个问题：https://github.com/elastic/ela ... 21595 。 这个问题很快被官方确认为Bug，修复也很快加入到了5.0.2。 为了规避这个问题，我们只好临时修改了一下Kibana以及第三方API访问要经过的nginx proxy，默认为所有的search request加入一个超时选项。此后，问题有一些缓解，但仍然发现用户查询大范围历史数据时，部分用于存储历史数据的结点响应很慢。
我们的集群是做了冷热分离的结构的，热节点主要承担写入和存放过去24小时数据，冷结点没有写入，查询频率也低，所以为了最大化利用硬件资源，一台物理机上跑了3个实例，这样一台128GB内存的机器可以存放下近30TB的索引。查看冷结点的监控数据，看到用户查询期间磁盘的read IO非常高，直接将磁盘IO Util%撑到100%，并且可持续数小时，同时search thread pool有大量的active thread处于无法完成状态，search queue不断攀升直至饱和、开始reject。 表象上看search thread似乎一直在尝试从磁盘大量读取数据，一次search甚至可以持续几十分钟至一个小时，耗尽了所有的搜索线程，导致拒绝后续的搜索服务。 于是Github上报了第3个issue: https://github.com/elastic/ela ... 21611 这个问题找到解决办法之前，我们只能通过反复重启有问题的冷结点来缓解。 和官方讨论过程中，得知5.0在Lucene文件访问方式上有一个比较大的改动，2.4使用mmapfs读取索引文件的部分，而5.0以后改为用mmapfs读取索引文件的全部。怀疑问题和这个变动有关，尝试将所有索引文件的设置改为NIOFS后，问题迎刃而解。 搜索性能一下回到了2.4时代，再也没出现搜索线程超长时间执行的问题。之后找时间复现了这个问题，并抓取了线程栈，看到长时间执行的搜索线程一直在做Global Ordinal的构造工作。 至于为何会这样，还不清楚。 从官方给出的信息看，底层索引文件的访问模式是没有变化的，仅仅是将文件读取方式全部改成了mmapfs，理论上应该性能更好，但是看起来在我们这种一台机器跑多个ES实例，所有分配的heap为系统缓存3倍的极端用例下，大范围的数据搜索可能造成过高的磁盘读IO，集群性能指数级下降。
以上问题前后耗了4天才完全规避掉，支持团队连续熬夜后集群总算回复到平稳状态。然而好景不长，运行一段时间以后，数据结点出现疑似内存泄漏现象。结点总数据没怎么增加、甚至还有减少的情况下，heap使用率一只呈攀升趋势，Old GC无法回收内存。这个问题对用户影响较小，通过监控我们可以及时发现内存即将用尽的结点，做一次重启很快就恢复了。 为排查根源，我们对一个有问题的结点做了dump，通过MAT工具分析，看到meta data相关的一个alias对象被实例化了有6600万次之多！ 在Github上提交了第四个issue: https://github.com/elastic/ela ... 22013，不多久被确认为已知问题https://github.com/elastic/ela ... 21284 ,在5.0.1已经修复。
最后还存在一个master node内存泄漏的问题，这个问题在2.4.0时代就存在了，升级到5.0.0以后依然没有修复。由于我们的master node和data node是分离的，所以这个问题比较容易通过监控发现，解决方式也很简单和迅速，重启master node即可，对用户完全无影响。之后不久，5.0.2版本正式发布，release notes里提到了对这个问题的修复 https://github.com/elastic/ela ... 21578 。
上周周末我们将集群rolling upgrade到了5.0.2，global search timeout失效和两个内存泄漏的问题从根源上解决掉了。 网络流量增大的问题依然存在，仍然需要通过启用client结点的transport.tcp.compress规避。 冷结点搜索性能的问题没看到有提及，估计没解决，安全起见，还是保持索引的文件系统为NIOFS。升级完成运行一段时间后，可以肯定，5.0.2已经比较稳定。
心得
升到5.0.2后，对于其中一组数据结点这两天特意加了点索引负载，通过监控数据将v5.0.2与2.4.0做实际运行环境的索引吞吐量对比。
在近似的CPU使用率和load情况下，5.0.2能够支撑更大的吞吐量。另外5.0带来的Instant aggregation功能，对于跨多个索引的时序类型数据的聚合也可以有效Cache了，在使用Kibana的时候提速感觉非常明显。
升级过程虽然遇到很多波折，但由于集群架构上做了角色分离(client,master,data)和冷热分离，因而Bug引起的故障比较容易被限定在一个较小的范围而不至于影响所有的功能和所有的用户。 故障点定位更加容易，规避措施也更容易实施。 部分规避措施实施过程中甚至对用户是完全无影响的，比如: 重启内存泄漏的master node)。详尽的监控为问题的发现和诊断提供了有力的支持。
Elasticsearch是非常复杂的系统，官方的测试无法覆盖所有的用例场景和数据规模，一些极端的应用场景可能触发某个深藏的Bug或者缺陷而陷入困境。 因此对于稳定性要求极高的应用，最好还是采用经过长时间考验的版本，比如v2.4.2。
Day1: 大规模Elasticsearch集群管理心得
kennywu76 发表了文章 • 83 个评论 • 49152 次浏览 • 2016-12-02 10:07
【携程旅行网 吴晓刚】
ElasticSearch目前在互联网公司主要用于两种应用场景，其一是用于构建业务的搜索功能模块且多是垂直领域的搜索，数据量级一般在千万至数十亿这个级别；其二用于大规模数据的实时OLAP，经典的如ELKStack，数据规模可能达到千亿或更多。 这两种场景的数据索引和应用访问模式上差异较大，在硬件选型和集群优化方面侧重点也会有所不同。一般来说后一种场景属于大数据范畴，数据量级和集群规模更大，在管理方面也更有挑战。
应Medcl大大的邀请，为ES中文社区做今年的Advent开篇，分享一下我在管理自家公司用于日志分析的ES集群方面的一点心得，蜻蜓点水，泛泛而谈，希望大方向上能对大家提供一些帮助。
这里的自家，即是携程旅行网。从2013年开始接触ES，我们团队先后实践过0.9.x -> 5.0.0中间各个版本，从最初只用于运维内部IIS日志的分析，到如今支持IT、呼叫中心、安全、测试、业务研发等多个部门超过200种日志型数据的实时检索与分析。 一路走来，愉悦了大家，也死磕了自己。
目前我们最大的日志单集群有120个data node，运行于70台物理服务器上。数据规模如下:
运维这样大规模的ES集群，有哪些值得注意的地方？
一. 必不可少的工具
工欲善其事必先利其器，从一开始，哪怕就只有几个node，就应该使用分布式配置管理工具来做集群的部署。随着应用的成熟，集群规模的逐步扩大，效率的提升会凸显。 官方提供了ES Puppet Module和Chef Cookbook，熟悉这两个工具的同学可以直接拿过来用。 我们自己则是采用的Ansible，编写了一套Playbook来达到类似的效果。 用熟这类工具，对于集群的初始部署，配置批量更改，集群版本升级，重启故障结点都会快捷和安全许多。
第二个必备利器就是sense插件。通过这个插件直接调用集群的restful API，在做集群和索引的状态查看，索引配置更改的时候非常方便。语法提示和自动补全功能更是实用，减少了翻看文档的频率。在Kibana5里面，sense已经成为一个内置的控制台，无需额外安装。
二. 硬件配置
我们采用的是32vcoreCPU + 128GB RAM的服务器，磁盘配置大部分服务器是12块4TB SATA机械磁盘做的Raid0，少部分机器是刚上了不久的6块800GB SSD raid0，主要目的是想做冷热数据分离，后面谈到集群架构的时候，再进一步解释一下如何利用硬件资源。
三. 集群的管理
四. 版本选择
我们在2.4版本上稳定跑了很长时间，比较保守的同学可以上2.4，激进有精力折腾的可以考虑最新的5.0。 我们集群两周前从v2.4.0升级到了v5.0.0这个版本，除了升级第一周遇到一个不稳定的问题以外，感觉新版本带来的以下特性还是非常值得去升级的:
升级第一周，我们的冷数据结点出现间歇性不响应问题，从而刨出3个issue提交给官方:
Issue#21595 Issue#21612 Issue#21611
第一个问题确认为Bug，将在5.0.2修复，其他两个目前还不清楚根源，看起来也只在我们的应用场景里遇到了。所幸问题都找到了了规避措施，实施这些措施以后，最近一周我们的集群重新回到以前2.4版本时期的稳定状态。
五. 监控
不差钱没空折腾的建议还是买官方的xpack省心，有精力折腾的，利用ES各种丰富的stats api，用自己熟悉的监控工具采集数据，可视化出来就好了。 那么多监控指标，最最关键的还是以下几类:
最后就是多上手实践，遇到问题多查官方资料，多Google看是否有其他人遇到同类问题，精力充足有编程背景的同学也可以多刨刨源码。
ElasticSearch目前在互联网公司主要用于两种应用场景，其一是用于构建业务的搜索功能模块且多是垂直领域的搜索，数据量级一般在千万至数十亿这个级别；其二用于大规模数据的实时OLAP，经典的如ELKStack，数据规模可能达到千亿或更多。 这两种场景的数据索引和应用访问模式上差异较大，在硬件选型和集群优化方面侧重点也会有所不同。一般来说后一种场景属于大数据范畴，数据量级和集群规模更大，在管理方面也更有挑战。
应Medcl大大的邀请，为ES中文社区做今年的Advent开篇，分享一下我在管理自家公司用于日志分析的ES集群方面的一点心得，蜻蜓点水，泛泛而谈，希望大方向上能对大家提供一些帮助。
这里的自家，即是携程旅行网。从2013年开始接触ES，我们团队先后实践过0.9.x -> 5.0.0中间各个版本，从最初只用于运维内部IIS日志的分析，到如今支持IT、呼叫中心、安全、测试、业务研发等多个部门超过200种日志型数据的实时检索与分析。 一路走来，愉悦了大家，也死磕了自己。
目前我们最大的日志单集群有120个data node，运行于70台物理服务器上。数据规模如下:
- 单日索引数据条数600亿，新增索引文件25TB (含一个复制片则为50TB)
- 业务高峰期峰值索引速率维持在百万条/秒
- 历史数据保留时长根据业务需求制定，从10天 - 90天不等
- 集群共3441个索引、17000个分片、数据总量约9300亿, 磁盘总消耗1PB
- Kibana用户600多人, 每日来自Kibana和第三方的API调用共63万次
- 查询响应时间百分位 75%:0.160s 90%:1.640s 95%:6.691s 99%:14.0039s
运维这样大规模的ES集群，有哪些值得注意的地方？
一. 必不可少的工具
工欲善其事必先利其器，从一开始，哪怕就只有几个node，就应该使用分布式配置管理工具来做集群的部署。随着应用的成熟，集群规模的逐步扩大，效率的提升会凸显。 官方提供了ES Puppet Module和Chef Cookbook，熟悉这两个工具的同学可以直接拿过来用。 我们自己则是采用的Ansible，编写了一套Playbook来达到类似的效果。 用熟这类工具，对于集群的初始部署，配置批量更改，集群版本升级，重启故障结点都会快捷和安全许多。
第二个必备利器就是sense插件。通过这个插件直接调用集群的restful API，在做集群和索引的状态查看，索引配置更改的时候非常方便。语法提示和自动补全功能更是实用，减少了翻看文档的频率。在Kibana5里面，sense已经成为一个内置的控制台，无需额外安装。
二. 硬件配置
我们采用的是32vcoreCPU + 128GB RAM的服务器，磁盘配置大部分服务器是12块4TB SATA机械磁盘做的Raid0，少部分机器是刚上了不久的6块800GB SSD raid0，主要目的是想做冷热数据分离，后面谈到集群架构的时候，再进一步解释一下如何利用硬件资源。
三. 集群的管理
- 首先很有必要对ES的结点做角色划分和隔离。大家知道ES的data node除了放数据以外，也可以兼任master和client的角色，多数同学会将这些角色混入到data node。然而对于一个规模较大，用户较多的集群，master和client在一些极端使用情况下可能会有性能瓶颈甚至内存溢出，从而使得共存的data node故障。data node的故障恢复涉及到数据的迁移，对集群资源有一定消耗，容易造成数据写入延迟或者查询减慢。如果将master和client独立出来，一旦出现问题，重启后几乎是瞬间就恢复的，对用户几乎没有任何影响。另外将这些角色独立出来的以后，也将对应的计算资源消耗从data node剥离出来，更容易掌握data node资源消耗与写入量和查询量之间的联系，便于做容量管理和规划。
- 避免过高的并发，包括控制shard数量和threadpool的数量。在写入量和查询性能能够满足的前提下，为索引分配尽量少的分片。分片过多会带来诸多负面影响，例如：每次查询后需要汇总排序的数据更多；过多的并发带来的线程切换造成过多的CPU损耗；索引的删除和配置更新更慢Issue#18776; 过多的shard也带来更多小的segment，而过多的小segment会带来非常显著的heap内存消耗，特别是如果查询线程配置得很多的情况下。 配置过大的threadpool更是会产生很多诡异的性能问题Issue#18161里所描述的问题就是我们所经历过的。 默认的Theadpool大小一般来说工作得很不错了。
- 冷热数据最好做分离。对于日志型应用来说，一般是每天建立一个新索引，当天的热索引在写入的同时也会有较多的查询。如果上面还存有比较长时间之前的冷数据，那么当用户做大跨度的历史数据查询的时候，过多的磁盘IO和CPU消耗很容易拖慢写入，造成数据的延迟。所以我们用了一部分机器来做冷数据的存储，利用ES可以给结点配置自定义属性的功能，为冷结点加上"boxtype":"weak"的标识，每晚通过维护脚本更新冷数据的索引路由设置index.routing.allocation.{require|include|exclude}，让数据自动向冷结点迁移。 冷数据的特性是不再写入，用户查的频率较低，但量级可能很大。比如我们有个索引每天2TB，并且用户要求保持过去90天数据随时可查。保持这么大量的索引为open状态，并非只消耗磁盘空间。ES为了快速访问磁盘上的索引文件，需要在内存里驻留一些数据(索引文件的索引)，也就是所谓的segment memory。稍微熟悉ES的同学知道，JVM heap分配不能超过32GB，对于我们128GB RAM, 48TB磁盘空间的机器而言，如果只跑一个ES实例，只能利用到32GB不到的heap，当heap快用饱和的时候，磁盘上保存的索引文件还不到10TB，这样显然是不经济的。 因此我们决定在冷结点上跑3个ES实例，每个分配31GB heap空间，从而可以在一台物理服务器上存储30多TB的索引数据并保持open状态，供用户随时搜索。 实际使用下来，由于冷数据搜索频率不高，也没有写入，即时只剩余35GB内存给os做文件系统缓存，查询性能还是可以满足需求的。
- 不同数据量级的shard最好隔离到不同组别的结点。 大家知道ES会自己平衡shard在集群的分布，这个自动平衡的逻辑主要考量三个因素。其一同一索引下的shard尽量分散到不同的结点;其二每个结点上的shard数量尽量接近;其三结点的磁盘有足够的剩余空间。这个策略只能保证shard数量分布均匀，而并不能保证数据大小分布均匀。 实际应用中，我们有200多种索引，数据量级差别很大，大的一天几个TB，小的一个月才几个GB，并且每种类型的数据保留时长又千差万别。抛出的问题，就是如何能比较平衡并充分的利用所有节点的资源。 针对这个问题，我们还是通过对结点添加属性标签来做分组，结合index routing控制的方式来做一些精细化的控制。尽量让不同量级的数据使用不同组别的结点，使得每个组内结点上的数据量比较容易自动平衡。
- 定期做索引的force merge，并且最好是每个shard merge成一个segment。前面提到过，heap消耗与segment数量也有关系，force merge可以显著降低这种消耗。 如果merge成一个segment还有一个好处，就是对于terms aggregation，搜索时无需构造Global Ordinals，可以提升聚合速度。
四. 版本选择
我们在2.4版本上稳定跑了很长时间，比较保守的同学可以上2.4，激进有精力折腾的可以考虑最新的5.0。 我们集群两周前从v2.4.0升级到了v5.0.0这个版本，除了升级第一周遇到一个不稳定的问题以外，感觉新版本带来的以下特性还是非常值得去升级的:
- 结点启动的Bootstrap过程加入了很多关键系统参数设置的核验，比如Max File Descriptors, Memory Lock, Virtual Memory设置等等，如果设置不正确会拒绝启动并抛出异常。 与其带着错误的系统参数启动，并在日后造成性能问题，不如启动失败告知用户问题，是个很好的设计！
- 索引性能提升。升级后在同样索引速率下，我们看到cpu消耗下降非常明显，除了对索引速率提升有帮助，也会一定程度提升搜索速率。
- 新的数值型数据结构，存储空间更小，Range和地理位置计算更快速
- Instant Aggregation对于类似now-7d to now这样的范围查询聚合能够做cache了，实际使用下来，效果明显，用户在Kibana上跑个过去一周数据的聚合，头2次刷新慢点，之后有cache了几乎就瞬间刷出！
- 更多的保护措施保证集群的稳定，比如对一次搜索hit的shard数量做了限制，增强了circuit breaker的特性，更好的防护集群资源被坏查询耗尽。
升级第一周，我们的冷数据结点出现间歇性不响应问题，从而刨出3个issue提交给官方:
Issue#21595 Issue#21612 Issue#21611
第一个问题确认为Bug，将在5.0.2修复，其他两个目前还不清楚根源，看起来也只在我们的应用场景里遇到了。所幸问题都找到了了规避措施，实施这些措施以后，最近一周我们的集群重新回到以前2.4版本时期的稳定状态。
五. 监控
不差钱没空折腾的建议还是买官方的xpack省心，有精力折腾的，利用ES各种丰富的stats api，用自己熟悉的监控工具采集数据，可视化出来就好了。 那么多监控指标，最最关键的还是以下几类:
- 各类Thread pool的使用情况，active/queue/reject可视化出来。 判断集群是否有性能瓶颈了，看看业务高峰期各类queue是不是很高，reject是不是经常发生，基本可以做到心里有数。
- JVM的heap used%以及old GC的频率，如果old GC频率很高，并且多次GC过后heap used%几乎下不来，说明heap压力太大，要考虑扩容了。（也有可能是有问题的查询或者聚合造成的，需要结合用户访问记录来判断)。
- Segment memory大小和Segment的数量。节点上存放的索引较多的时候，这两个指标就值得关注，要知道segment memory是常驻heap不会被GC回收的，因此当heap压力太大的时候，可以结合这个指标判断是否是因为节点上存放的数据过多，需要扩容。Segement的数量也是比较关键的，如果小的segment非常多，比如有几千，即使segment memory本身不多，但是在搜索线程很多的情况下，依然会吃掉相当多的heap，原因是lucene为每个segment会在thread local里记录状态信息，这块的heap内存开销和(segment数量* thread数量)相关。
- 很有必要记录用户的访问记录。我们只开放了http api给用户，前置了一个nginx做http代理，将用户第三方api的访问记录通过access log全部记录下来。通过分析访问记录，可以在集群出现性能问题时，快速找到问题根源，对于问题排查和性能优化都很有帮助。
最后就是多上手实践，遇到问题多查官方资料，多Google看是否有其他人遇到同类问题，精力充足有编程背景的同学也可以多刨刨源码。
