大家好，ElasticTalk 第4次直播将于本周进行，主题是关于 Elastic 官方认证考试的。
 
我于7月初成功通过了 Elastic Certified Engineer 的考试，拿到下面的徽章。


 
感兴趣的同学可以扫下面海报中的二维码或者搜索 elastic-talk 微信号，添加好友后进入直播群。
 


 

ElasticTalk 第3期 直播的内容是 Elasticsearch 压测实战之 esrally 进阶实战。

本次我们主要讲解了 esrally 如何自定义测试集群、自定义数据集和报告，最后还讲了三步上手 esrally 的方法。
 
视频地址如下：
http://www.bilibili.com/video/av27117279/

 
ElasticTalk 第2期 直播的内容是 Elasticsearch 压测实战之 esrally 入门和实战。希望这次直播可以帮助大家快速掌握 esrally 这款优秀的 es 压测工具。
 
视频地址如下：
https://www.bilibili.com/video/av27114309/

 
去年做了3期 ElasticTalk 的直播节目，预计下周开始恢复。现在放出相关的视频内容，希望对大家有所帮助。
 
第1期的课程内容为用 ElasticStack 快速收集分析 Nginx 日志，其中详细讲解了如何使用 filebeat 的 module 功能。
 
 
视频地址如下：
https://www.bilibili.com/video/av27123368/

Elastic 官方在6月29日推出了认证服务，即 elastic certified engineer(官方网页)，在7月9日我参加了认证考试，并顺利通过拿到了这枚官方认证的徽章。
 


 
考试还是有一定难度的，需要你对 elastic 的知识面有比较全面的掌握，由于是面向 engineer 的认证，所以只是在应用层面，不会考理论深度层面，感兴趣的同学可以根据官方的考纲重点来准备考试了，下周我会和大家再详细分享下该认证考试的方式和建议。
 
Good Luck!

大家好，经过近半年的辛勤努力，我在慕课网推出了《Elastic Stack 从入门到实践》的课程（https://coding.imooc.com/class/chapter/181.html），其中包含了 elasticsearch 教程、beats 和 logstash 教程、kibana 教程，简单看下课程的内容：

第1章 课程概述
对课程整体进行介绍给出相关学习说明和建议

第2章 Elasticsearch 篇之 入门
本章会对 Elasticsearch 篇进行一个总体的介绍，让大家对该篇每一章要讲解的内容有初步的了解。然后会讲解 Elasticsearch 中常见的术语、api，然后运行 Elasticsearch 并实际感受 api 的调用方式，为接下来的课程做好准备。

第3章 Elasticsearch 篇之倒排索引与分词
本章会讲解搜索引擎的基础倒排索引，让大家对倒排索引有一个直观的认识，掌握它的组成。然后为大家讲解分词的相关知识，介绍 es 内置的分词器，还会介绍中文分词的常见解决方案。

第4章 Elasticsearch 篇之Mapping 设置
本章会讲解 Elasticsearch 中数据建模的基础--Mapping，即如何定义数据字段和类型。让大家熟悉 mapping 中常见的配置项，也会讲解 dynamic mapping 和 template 的相关知识。

第5章 Elasticsearch 篇之Search API 介绍
本章会讲解搜索特性，详细讲解 Search API 的组成和分类，带领大家逐个了解、掌握 API 的使用方法和技巧。

第6章 Elasticsearch 篇之分布式特性介绍
本章会讲解 Elasticsearch 集群是如何一步步搭建起来的，让大家了解不同节点类型的作用，shard 设计的意义以及文档是如何存储到 shard 上的，也会给大家介绍脑裂等问题。

第7章 Elasticsearch 篇之深入了解 Search 的运行机制
本章会深入讲解 Search 的运行机制，比如 Query 和 Fetch 阶段具体哪些工作，分片为相关性算分带来了哪些问题。另外还会讲解排序、分页与遍历的解决方案和相关问题。

第8章 Elasticsearch 篇之聚合分析入门
本章会介绍 Elasticsearch 聚合分析的功能，让大家了解其分类、组成，带领大家逐个了解、掌握每一个聚合 API 的使用方法和技巧，为后续 Kibana 使用打好基础。

第9章 Elasticsearch 篇之数据建模
本章会介绍使用 Elasticsearch 中要注意的数据建模常见问题以及优化思路和方案，让大家可以根据自己的业务场景设置最合理的模型。

第10章 Elasticsearch 篇之集群调优建议
本章会介绍 Elasticsearch 集群在搭建、配置上的注意事项，也会讲解读写性能优化的方案和调优的方式。

第11章 Logstash 篇之入门与运行机制
本章会介绍 Logstash 的作用、使用方法，让大家了解其组成和运行机制，带领大家实际操作 Logstash 来收集1个日志文件。

第12章 Logstash 篇之插件详解
本章会详细介绍 Input、Filter、Ouput 以及 Codec 插件 的作用和相关配置，让大家了解常见相关插件的使用场景和效果，以及如何合理选择各个插件来实现自己的业务需求。

第13章 Logstash 篇之实例分析
本章会以实例的形式为大家演示如何使用 Logstash 收集各种类型的数据，比如日志文件、数据库、tcp/udp 等。

第14章 Beats 篇之Filebeat
本章会介绍 Beats 的作用和组成，然后为大家详细介绍 Filebeat 的功能和常见配置，同时会详细讲解如何使用 Module 模块来快速完成日志的收集到分析工作。

第15章 Beats 篇之Metricbeat
本章会介绍 Metricbeat 的功能和使用技巧，让大家对 Metricbeat 的使用有一个直观的感受。

第16章 Beats 篇之Packetbeat
本章会介绍 Packetbeat 的功能和使用技巧，带领大家用 Packetbeat 来收集网络数据并进行分析，让大家对 Packetbeat 有一个直观的感受。

第17章 Beats 篇之其他 beat
本章会介绍其他众多beat的作用和应用场景，带领大家去发现社区提供的多种多样的beat,以满足日常业务开发的需求。

第18章 Kibana 篇之 入门与管理
本章会介绍 Kibana 的入门知识，让大家对 Kibana 有一个整体的了解，另外还会详细介绍Management 的功能，熟悉 Kibana 的配置。

第19章 Kibana 篇之 数据探索 Discovery
本章会介绍 Kibana 的数据探索功能，让大家了解 Discovery 的功能和使用技巧。

第20章 Kibana 篇之 可视化分析
本章会介绍Kibana 的可视化分析功能，首先会带领大家逐个操作 Kibana 提供的每一个图表，并会介绍时序分析工具 Timelion，然后会介绍如何使用 Dashboard功能来整合图表后讲故事或者做报表，也会讲解 Dashboard 使用中要注意的问题和使用技巧。 ...

第21章 实践篇 之搜索项目
本章会讲解一个搜索引擎相关的实践项目，带领大家通过编写少量的代码，快速基于 Elastic Stack 来构建一个具备常见搜索功能的系统，比如类似 Airbnb 的搜房系统、豆瓣电影等。

第22章 实践篇 之日志分析项目
本章会根据慕课网的日志为大家展示如何使用 Elastic Stack 来快速分析日志数据，带领大家一步步完成数据收集、处理、存储到可视化分析的步骤，最终打造属于自己的 Dashboard。

第23章 实践篇 之数据分析项目
本章会为大家展示如何使用 Elastic Stack 来分析身边的数据，比如空气质量分析、订单数据分析等等，让大家通过本章的学习可以快速将 Elastic Stack 应用到实际生活中。
 

 
实践方面我从搜索项目、日志分析和数据分析三个维度介绍了 Elastic Stack 的功能，可以看下最终的效果截图：
 


 


 
 




 
那么剩下的就看你们了！
 
 
 
 
 
 
 
 

北京时间周四凌晨1点15分，知名代码托管网站GitHub遭遇了有史以来最严重的DDoS网络攻击，峰值流量达到了1.35Tbps。尽管此类攻击的特点就是利用如潮水般的流量同时涌入网站，不过本次攻击不同之处在于采用了更先进的放大技术，目的是针对主机服务器产生更严重的影响。

报道称，拥有超过900万开发者用户的GitHub，是全球最知名的开源代码库之一。美国东部时间周三下午，为用户提供海量开源代码的GitHub透露，其可能遭受了有史最强的DDoS攻击，专家称攻击者采用了放大攻击的新方法，可能会在未来发生更大规模的分布式拒绝服务（DDoS）攻击。

据悉，对GitHub平台的第一次峰值流量攻击达到了1.35Tbps，随后又出现了另外一次400Gbps的峰值，这可能也将成为目前记录在案的最强DDoS攻击。对GitHub的攻击甚至超过了2016年对Dyn的大规模DDoS攻击，峰值流量达1.2Tbps，当时关闭了美国的互联网服务。


然而，对GitHub的攻击几乎毫发无损，只经历了几分钟的零星停机时间。按照GitHub方面的说法，从当地时间2月28日起，GitHub.com经历了两次间歇性不可访问，但其强调开发者数据依然安全。此外，GitHub在攻击发生10分钟后便向CDN服务商Akamai请求协助，访问GitHub的流量目前已由AkamaiProlexic接管。Prolexic接管了中间人路由所有进出GitHub的流量，并通过其清理中心发送数据来清除和阻止恶意数据包。八分钟后，攻击者松了口气，袭击事件下降了。


近年来随着互联网病毒的广泛传播，大规模的DDoS攻击愈发增多。而GitHub也并非第一次遭到DDoS攻击，2015年，Github曾遭到当时最大规模的攻击。

 

本次分享主要包含两个方面的实战经验：索引性能和查询性能。
一. 索引性能（Index Performance）
首先要考虑的是，索引性能是否有必要做优化？
索引速度提高与否？主要是看瓶颈在什么地方，若是 Read DB（产生DOC）的速度比较慢，那瓶颈不在 ElasticSearch 时，优化就没那么大的动力。实际上 Elasticsearch 的索引速度还是非常快的。
我们有一次遇到 Elasticsearch 升级后索引速度很慢，查下来是新版 IK 分词的问题，修改分词插件后得到解决。
如果需要优化，应该如何优化？
SSD 是经济压力能承受情况下的不二选择。减少碎片也可以提高索引速度，每天进行优化还是很有必要的。在初次索引的时候，把 replica 设置为 0，也能提高索引速度。
bulk 是不是一定需要呢？
若是 Elasticsearch 普通索引已经导致高企的 LA，IO 压力已经见顶，这时候 bulk 也无法提供帮助，SSD 应该是很好的选择。
在 create doc 速度能跟上的时候，bulk 是可以提高速度的。
记得 threadpool.index.queue_size ++，不然会出现索引时队列不够用的情况。
indices.memory.index_buffer_size:10% 这个参数可以进行适当调整。
调整如下参数也可以提高索引速度：index.translog.flush_threshold_ops:50000 和 refresh_interval。
二. 查询性能（Query Perofrmance）
王道是什么？routing，routing，还是 routing。
我们为了提高查询速度，减少慢查询，结合自己的业务实践，使用多个集群，每个集群使用不同的 routing。比如，用户是一个routing维度。
在实践中，这个routing 非常重要。
我们碰到一种情况，想把此维度的查询（即用户查询）引到非用户routing 的集群，结果集群完全顶不住！
在大型的本地分类网站中，城市、类目也是一个不错的维度。我们使用这种维度进行各种搭配。然后在前端分析查询，把各个不同查询分别引入合适的集群。这样做以后，每个集群只需要很少的机器，而且保持很小的 CPU Usage 和 LA。从而查询速度够快，慢查询几乎消灭。
分合？
分别（索引和routing）查询和合并（索引和routing）查询，即此分合的意思。
索引越来越大，单个 shard 也很巨大，查询速度也越来越慢。这时候，是选择分索引还是更多的shards？
在实践过程中，更多的 shards 会带来额外的索引压力，即 IO 压力。
我们选择了分索引。比如按照每个大分类一个索引，或者主要的大城市一个索引。然后将他们进行合并查询。如：http://cluster1:9200/shanghai,beijing/_search?routing=fang，自动将查询中城市属性且值为上海或北京的查询，且是房类目的，引入集群 cluster1，并且routing等于fang。
http://cluster1:9200/other/_search?routing=jinan,linyi。小城市的索引，我们使用城市做 routing，如本例中同时查询济南和临沂城市。
http://cluster1:9200/_all/_search，全部城市查询。
再如： http://cluster2:9200/fang,che/_search?routing=shanghai_qiche,shanghai_zufang,beijing_qiche,beijing_zufang。查询上海和北京在小分类汽车、整租的信息，那我们进行如上合并查询。并将其引入集群 cluster2。
使用更多的 shards？
除了有 IO 压力，而且不能进行全部城市或全部类目查询，因为完全顶不住。
Elastic 官方文档建议：一个 Node 最好不要多于三个 shards。
若是 "more shards”，除了增加更多的机器，是没办法做到这一点的。
分索引，虽然一个 Node 总的shards 还是挺多的，但是一个索引可以保持3个以内的shards。
我们使用分索引时，全量查询是可以顶住的，虽然压力有点儿高。
索引越来越大，资源使用也越来越多。若是要进行更细的集群分配，大索引使用的资源成倍增加。
有什么办法能减小索引？显然，创建 doc 时，把不需要的 field 去掉是一个办法；但是，这需要对业务非常熟悉。
有啥立竿见影的办法？
根据我们信息的特点，内容（field:description）占了索引的一大半，那我们就不把 description 索引进 ES，doc 小了一倍，集群也小了一倍，所用的资源（Memory, HD or SSD, Host, snapshot存储，还有时间）大大节省，查询速度自然也更快。
那要查 description 怎么办？
上面的实例中，我们可以把查询引入不同集群，自然我们也可以把 description 查询引入一个非实时（也可以实时）集群，这主要是我们业务特点决定的，因为description查询所占比例非常小，使得我们可以这样做。
被哪些查询搞过？第一位是 Range 查询，这货的性能真不敢恭维。在最热的查询中，若是有这货，肯定是非常痛苦的，网页变慢，查询速度变慢，集群 LA 高企，严重的时候会导致集群 shard 自动下线。所以，建议在最热的查询中避免使用 Range 查询。
Facet 查询，在后续版本这个被 aggregations 替代，我们大多数时候让它在后端进行运算。
三. 其他
1)线程池
线程池我们默认使用 fixed，使用 cached 有可能控制不好。主要是比较大的分片 relocation时，会导致分片自动下线，集群可能处于危险状态。在集群高压时，若是 cached ，分片也可能自动下线。自 1.4 版本后，我们就一直 fixed，至于新版是否还存在这个问题，就没再试验了。
两个原因：一是 routing王道带来的改善，使得集群一直低压运行；二是使用fixed 后，已经极少遇到自动下线shard了。
我们前面说过，user 是一个非常好的维度。这个维度很重要，routing 效果非常明显。其他维度，需要根据业务特点，进行组合。
所以我们的集群一直是低压运行，就很少再去关注新版本的 使用 cached 配置问题。
hreadpool.search.queue_size 这个配置是很重要的，一般默认是够用了，可以尝试提高。
2）优化
每天优化是有好处的，可以大大改善查询性能。max_num_segments 建议配置为1。虽然优化时间会变长，但是在高峰期前能完成的话，会对查询性能有很大好处。
3) JVM GC的选择：选择 G1还是 CMS？
应该大多数人还是选择了 CMS，我们使用的经验是 G1 和 CMS 比较接近；但和 CMS 相比，还是有一点距离，至少在我们使用经验中是如此。
JVM 32G 现象？
128G内存的机器配置一个 JVM，然后是巨大的 heapsize （如64G）？
还是配多个 JVM instance，较小的 heapsize（如32G）？
我的建议是后者。实际使用中，后者也能帮助我们节省不少资源，并提供不错的性能。具体请参阅 “Don’t Cross 32 GB!" （https://www.elastic.co/guide/e ... _oops）
跨 32G 时，有一个现象，使用更多的内存，比如 40G，效果还不如31G！
这篇文档值得大家仔细阅读。
JVM 还有一个配置 bootstrap.mlockall: true，比较重要。这是让 JVM 启动的时候就 锁定 heap 内存。
有没有用过 较小的 heapsize，加上SSD？我听说有人使用过，效果还不错，当然，我们自己还没试过。
4）插件工具
推荐 kopf，是一个挺不错的工具，更新及时，功能完备，可以让你忘掉很多 API :)。



上面是 kopf 的图片。管理Elasticsearch 集群真心方便。以前那些 API ，慢慢要忘光了:)
索引，查询，和一些重要的配置，是今天分享的重点。

Q&A
Q1：您建议生产环境JVM采用什么样的参数设置？FULL GC频率和时间如何？
CMS 标准配置。
ES_HEAP_NEWSIZE=?G
JAVA_OPTS="$JAVA_OPTS -XX:+UseCondCardMark"
JAVA_OPTS="$JAVA_OPTS -XX:CMSWaitDuration=250"
JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"
JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"
JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"
JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"
Full GC 很少去care 它了。我们使用 Elasticsearch 在JVM上花的时间很少。
Q2：生产环境服务器如何配置性价比较高？单机CPU核数、主频？内存容量？磁盘容量？
内存大一些，CPU 多核是必要的，JVM 和 Elasticsearch 会充分使用内存和多核的。 关于内存容量的问题，很多是 JVM Tunning 的问题。 磁盘容量没啥要求。
Q3： 分组统计(Facet 查询或 aggregations )大多数时候让它在后端进行运算，怎么实现？应用如果需要实时进行统计而且并发量较大，如何优化？
因为我们是网站系统，所以对于 Facet 请求，引导到后端慢慢计算，前端初始的时候可能没数据，但是此后就会有了。
如果是精确要求的话，那就只能从 提高 facet 查询性能去下手，比如 routing、filter、cache、更多的内存...
Q4：存进Elasticsearch的数据，timestamp是UTC时间，Elasticsearch集群会在UTC 0点，也就是北京时间早上8点自动执行优化？如何改参数设置这个时间？
我们没有使用Elasticsearch的自动优化设置。自己控制优化时间。
Q5：我的Java程序，log4j2 Flume appender，然后机器上的Flume agent ，直接Elasticsearch 的sink avro到 es节点上，多少个agent 连在单个Elasticsearch节点比较合适 ？
ElasticSearch本身是一个分布式计算集群，所以，请求平均分配到每个 node 即可。
Q6：我代码里直接用 Java API 生成Flume appender 格式，Flume agent 里interceptor去拆分几个字段，这样是不是太累了？比较推荐的做法是不是还是各业务点自己控制字段，调用Elasticsearch API 生成索引内容？
业务点自己控制生成的文档吧？如果需要产生不同routing，并且分了索引，这些其实是业务相关的。routing和不同索引，都是根据业务情况哪些查询比较集中而进行处理的。
Q7：您见过或管理过的生产环境的Elasticsearch数据量多大？
我们使用 Elasticsearch 进行某些业务处理，数据量过亿。
Q8：SSD性能提升多少？
SSD 对索引帮助非常大，效果当当的，提高几十倍应该是没问题。不过，我们没有试过完全使用SSD顶查询，而是使用内存，内存性价比还是不错的。
Q9：我们现在有256个shard，用uid做routing，所有查询都是走routing。每个shard有30多G，每次扩容很慢，有什么建议？
可以考虑使用分合查询吗？ 或者使用更多的维度？ 256个 shard 确实比较难以控制。但是如果是分索引和查询，比more shards(256) 效果应该会好不少。
Q10：Elasticsearch排序等聚合类的操作需要用到fielddata，查询时很慢。新版本中doc values聚合查询操作性能提升很大，你们有没有用过？
Facet 查询需要更大的内存，更多的 CPU 资源。可以考虑routing、filter、cache等多种方式提高性能。
Aggs 将来是要替换 Facet，建议尽快替换原来的facet API。
Q11：Elasticsearch配置bootstrap.mlockall，我们在使用中发现会导致启动很慢，因为Elasticsearch要获取到足够的内存才开始启动。
启动慢是可以接受的，启动慢的原因也许是内存没有有效释放过，比如文件 cached了。 内存充足的情况下，启动速度还是蛮快的，可以接受。 JVM 和 Lucene 都需要内存，一般是JVM 50%, 剩下的50% 文件cached 为Lucene 使用。
Q12：优化是一个开销比较大的操作，每天优化的时候是否会导致查询不可用？如何优化这块？
优化是开销很大的。不会导致查询不可用。优化是值得的，大量的碎片会导致查询性能大大降低。 如果非常 care 查询，可以考虑多个集群。在优化时，查询 skip 这个集群就可以。
Q13：Elasticsearch适合做到10亿级数据查询，每天千万级的数据实时写入或更新吗？
10亿是可以做到的，如果文档轻量，10亿所占的资源还不是很多。
ELK 使用 Elasticsearch ，进行日志处理每天千万是小case吧？
不过我们除了使用 ELK 进行日志处理，还进行业务处理，10亿级快速查询是可以做到，不过，需要做一些工作，比如索引和shards的分分合合：）
Q14：Elasticsearch相比Solr有什么优势吗？
我们当年使用 Solr 的时候，Elasticsearch 刚出来。他们都是基于 Lucene的。 Elasticsearch 相对于 solr ，省事是一个优点。而且现在 Elasticsearch 相关的应用软件也越来越多。Solr 和 Lucene 集成度很高，更新版本是和Lucene一起的，这是个优点。
很多年没用 Solr了，毕竟那时候数据量还不大，所以折腾的就少了，主要还是折腾 JVM。所以，就不再过多的比较了。
Q15：分词用的什么组件？Elasticsearch自带的吗？
我们使用 IK 分词，不过其他分词也不错。IK分词更新还是很及时的。而且它可以远程更新词典。：）
Q16： reindex有没有好的方法？
reindex 这个和 Lucene 有关，它的 update 就是 delete+ add。
Q17：以上面的两个例子为例 ： 是存储多份同样的数据么？
是两个集群。第一个集群使用大城市分索引，不过，还有大部分小城市合并一个索引。大城市还是用类目进行routing，小城市合并的索引就使用城市进行routing 。
第二个集群，大类分得索引，比如fang、che，房屋和车辆和其他类目在一个集群上，他们使用 city+二级类目做routing。
Q18：集群部署有没有使用 Docker ？ 我们使用的时候 ，同一个服务器 节点之间的互相发现没有问题 ，但是跨机器的时候需要强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群互相发现问题。
我们使用puppet进行部署。暂没使用 Docker。 强制指定network.publish_host 和 discovery.zen.ping.unicast.hosts 才能解决集群，跨IP段的时候是有这个需要。
Q19：您建议采用什么样的数据总线架构来保证业务数据按routing写入多个Elasticsearch集群，怎么保证多集群Elasticsearch中的数据与数据库中数据的一致性？
我们以前使用 php在web代码中进行索引和分析 query，然后引导到不同集群。 现在我们开发了一套go rest系统——4sea，使用 redis + elastic 以综合提高性能。
索引时，更新db的同时，提交一个文档 ID 通知4sea 进行更新，然后根据配置更新到不同集群。
数据提交到查询时，就是分析 query 并引导到不同集群。
这套 4sea 系统，有机会的可以考虑开源，不算很复杂的。
Q20： 能介绍一下Elasticsearch的集群rebanlance、段合并相关的原理和经验吗？
“段”合并？，我们是根据业务特点，产生几个不一样的集群，主要还是 routing 不一样。
shards 比较平均很重要的，所以选择routing 维度是难点，选择城市的话，大城市所在分片会非常大，此时可以考虑 分索引，几个大城市几个索引，然后小城市合并一个索引。
如果 shards 大小分布平均的话，就不关心如何 allocation 了。
Q21：关于集群rebalance，其实就是cluster.routing.allocation配置下的那些rebalance相关的设置，比如allow_rebalance／cluster_concurrent_rebalance／node_initial_primaries_recoveries，推荐怎么配置？
分片多的情况下，这个才是需要的吧。
分片比较少时，allow_rebalance disable，然后手动也可以接受的。
分片多，一般情况会自动平衡。我们对主从不太关心。只是如果一台机器多个 JVM instance （多个 Elasticsearch node）的话，我们写了个脚本来避免同一shard 在一台机器上。
cluster_concurrent_rebalance 在恢复的时候根据情况修改。正常情况下，再改成默认就好了。
node_initial_primaries_recoveries，在保证集群低压的情况下，不怎么care。
kopf 上面有好多这种配置，你可以多试试。
Q22：合并查询是异步请求还是同步请求？做缓存吗？
合并查询是 Elasticsearch 自带 API。
Q23：用http url connection请求的时候，会发现返回请求很耗时，一般怎么处理？
尽可能减少慢查询吧？我们很多工作就是想办法如何减少慢查询，routing和分分合合，就是这个目的。
Q24：生产环境单个节点存储多少G数据？
有大的，有小的。小的也几十G了。不过根据我们自己的业务特点，某些集群就去掉了全文索引。唯一的全文索引，使用基本的routing（比较平衡的routing，比如user。城市的话，就做不到平衡了，因为大城市数据很多），然后做了 快照，反正是增量快照，1小时甚至更短时间都可以考虑！！！去掉全文索引的其他业务集群，就小多了。
 

Grok 是一个常用的对日志进行结构化的一个工具，
可以通过在线工具进行调试：
http://grokdebug.herokuapp.com
http://grokconstructor.appspot.com
 
不过有时候比较慢，甚至不能访问，所以现在为大家搭好了一个国内的镜像，方便使用：
http://grok.elasticsearch.cn/
 
目前还是英文，源码fork至：https://github.com/elasticsear ... uctor
欢迎提交PR来进行翻译。


 
PS: 
1. Kibana后续将提供Grok Debug的功能；
2.如果你的日志每一行都遵循固定格式，你可以考虑使用 dissect filter，性能更强更简单。

看得出来是踩了不少坑总结出来的，推荐下： 基于ElasticSearch的亿级实时日志系统实践