我们经历过的坑和坎儿：1，elasticsearch 进程JVM Heap High Usage（ > 90% ）。

很长一段时间，我们都在应对JVM Heap High Usage，他带了的问题是Old GC次数多，时间长，es节点频繁退出集群，整个集群几乎停止响应。现在我们的主要策略是开启doc_values；限制query执行时占用的JVM Heap size；analyzed string只允许做query，不允许facets或者aggs；定期close 用户不需要的index。

2，Elasticsearch Query DSL、Facets、Aggs学习困惑。

有人为此开发了使用SQL执行ES Query的插件，一定程度上减轻了进入门槛。我们给出的学习他们的建议是观察Kibana的Request Body或试用Marvel的Senese插件，它有自动完成Query、Facets、Aggs的功能。另外最常用的query是query string query，最常用的aggs是Terms、Date Histogram，可以应付大部分需求。

3，logstash不工作。

非官方的问题插件，及使用logstash-filter-ruby时未考虑到的异常等，导致Logstash运行时工作线程（worker thread）异常退出，Logstash僵死。我们的建议是尽可能不要在config中使用logstash-filter-ruby，尽量使用官方插件。不过我们也遇到过复杂的日志，写过250行+的config，用尽了ruby filter。当前未发现Logstash有好的成熟的监控方案，Logstash的内部状态也获取不到。我们目前通过间接的监控Kafka topic consumer是否落后或elasticsearch indexing rate来检验logstash的工作情况。

4，Kibana没有用户的概念，不同用户的数据无法隔离。

多个用户共享的Kibana Dashboard，误操作或误删时常影响其他用户，保存的dashboard太多，找到特定的dashboard很困难。官方到目前为止，未在这方面做过改进。有很多非官方的改进，我们也曾经用过三斗大神定制的Kibana3，也对Kibana index做了snapshot储存到HDFS里面。

5，与用户沟通成本高。

与我们的用户协商日志格式，数据可视化配置时，由于人的不确定性容易造成多次来回确定和修改，效率低下。我们毕竟是提供日志分析服务的，不给用户做日志运维，所以近期也在探索通过日志接入自动化、推荐用户提供给我们json格式数据，定期组织用户的Kibana培训来减少沟通成本。
Q & A问：logstash连es出现timeout的情况有没?如何解决的?
答：我们常见的是ES Jvm Heap Usage比较高的时候会timeout，如果是服务内存小换大内存。另外不要对analyzed的string做aggs、facets，开启doc_values。

问：关于日志中异常报警的，有哪些方式？关键字过滤？
答：对于日志解析失败的情况，logstash 常见的是_grokparsefailuer和_jsonparsefailure，数据写入es后，执行query查询这两个关键词的数量即可。对于报警方案，watch是官方刚出的，其实比它早的实现方案，如Yelp的elastalert。

问：大数据分析平台（基于HDFS）跟kibana的展现会有很大区别吗？或者说最大的区别会在哪些方面？
答：你说的区别，我理解是Hadoop与Elasticsearch的区别，一个是离线分析，以job为单位，一个是实时搜索和统计，以query为单位。这里有三个关键词：实时，搜索，统计。Hadoop是离线的，es是实时的；es本质上是一个搜引擎，可以用来做全文检索等工作，Hadoop显然于此无关。统计是Hadoop与es都能做的，我不了解Hadoop有没有像Kibana这样的数据可视化组件。

问：你们的ES集群数据节点和查询节点做了分离吗？logstash是直接把数据写入查询节点还是数据节点？另外你们直接用的node模式还是transport模式呢？
答：（1）还没有做分离。（2）我们还在用http protocol模式。

PPT已经上传至微盘。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
以上内容根据2015年7月14日晚微信群分享内容整理。分享人高英举，就职于新浪，主要负责dip实时日志分析服务技术架构与实现，为微博，微盘，视频，cdn等多个部门提供实时日志统计和搜索服务，热衷于将开源技术服务化，产品化。微博：@gary的影响力。 DockOne每周都会组织定向的技术分享，欢迎感兴趣的同学加微信：liyingjiesx，进群参与。