elasticsearch

elasticsearch

es集群规模较大时,配置文件一般怎么管理?

Elasticsearchkennywu76 回复了问题 • 2 人关注 • 1 个回复 • 100 次浏览 • 9 小时前 • 来自相关话题

elasticsearch能不能进行分组聚合的同时对聚合结果进行分页?求助!!!

Elasticsearchbingyuf2012 回复了问题 • 5 人关注 • 4 个回复 • 346 次浏览 • 3 天前 • 来自相关话题

求复杂业务下数据导入elasticsearch的解决方案

Elasticsearchbingyuf2012 回复了问题 • 2 人关注 • 1 个回复 • 303 次浏览 • 3 天前 • 来自相关话题

【新人求助】kibana-5.4.1错误Cannot assign to read only property '__esModule'

回复

Kibanadbnaxlc 回复了问题 • 1 人关注 • 1 个回复 • 229 次浏览 • 4 天前 • 来自相关话题

logstash-input-jdbc 数据无法导入到已经存在的索引库?

LogstashNovemberRain_Jack 回复了问题 • 3 人关注 • 2 个回复 • 240 次浏览 • 4 天前 • 来自相关话题

elasticsearch拼音提示指定字段问题

Elasticsearchwengqiankun 回复了问题 • 3 人关注 • 2 个回复 • 440 次浏览 • 5 天前 • 来自相关话题

elasticsearch高亮关键词在原文中的位置

回复

Elasticsearchwcx945 发起了问题 • 2 人关注 • 0 个回复 • 262 次浏览 • 5 天前 • 来自相关话题

springboot集成elasticSearch问题

Elasticsearchtoken01 回复了问题 • 3 人关注 • 3 个回复 • 309 次浏览 • 5 天前 • 来自相关话题

分组查询排序问题

Elasticsearchhailang 回复了问题 • 2 人关注 • 2 个回复 • 267 次浏览 • 2017-06-19 17:03 • 来自相关话题

Kibana error with X-Pack monitoring

Kibanamedcl 回复了问题 • 2 人关注 • 1 个回复 • 264 次浏览 • 2017-06-19 12:47 • 来自相关话题

条新动态, 点击查看
我知道了。
      "aggs": {
        "avg_rating": {
          "avg": {
            "script": &qu... 显示全部 »
我知道了。
      "aggs": {
        "avg_rating": {
          "avg": {
            "script": "_score"
          }
        }
      }
聚合部分这样写就可以了,如果script报
【scripts of type [inline], operation [aggs] and lang [groovy] are disabled】的错误
就在
就在配置文件elasticsearch.yml里

script.inline: on
script.indexed: on
script.engine.groovy.inline.aggs: on
script.engine.groovy.inline.update: on这几行配置加上然后重启els就可以了
 
我已经使用在了生产环境,是没有问题的。这个问题纠结了几天,终于找到方法了,跟帖在这里。
bsll

bsll 回答了问题 • 2016-11-16 17:14 • 2 个回复 不感兴趣

一个nested字段聚合父子字段

赞同来自:

写了一个demo,不过不知道你是不是这个意思。
DELETE /test_agg
PUT /test_agg
{
   "mappings": {
      "agg_type": {
          "... 显示全部 »
写了一个demo,不过不知道你是不是这个意思。
DELETE /test_agg
PUT /test_agg
{
   "mappings": {
      "agg_type": {
          "properties": {
          "all":{
              "type": "nested",
              "properties": {
                  "parent_id": {
                     "type": "integer"
                  },
                  "child_id": {
                     "type": "integer"
                  }
              }
          }
          }
      }
   }
}

POST /test_agg/agg_type/1
{
    "all":{
        "parent_id":1,
        "child_id":2
        
    }
}
POST /test_agg/agg_type/2
{
    "all":{
        "parent_id":1,
        "child_id":3
        
    }
}
POST /test_agg/agg_type/3
{
    "all":{
        "parent_id":2,
        "child_id":3
        
    }
}
POST /test_agg/_search
POST /test_agg/agg_type/_search
{
    "size": 0, 
   "aggs": {
      "category": {
         "aggs": {
            "term_list": {
               "terms": {
                  "field": "all.parent_id"
               },
               "aggs": {
                  "term_list": {
                     "terms": {
                        "field": "all.child_id"
                     }
                  }
               }
            }
         },
         "nested": {
            "path": "all"
         }
      }
   }
}
 
wungking

wungking 回答了问题 • 2016-12-16 16:44 • 5 个回复 不感兴趣

如何清理Elasticsearch特定时间段数据?

赞同来自:

这个有三种思路,
第一种:设置入ES的条件,0-8点的日志数据就不入ES,这样就不需要有删除的操作;
 
第二种:整理这类日志,将需要的数据 转存到新的索引下,不需要的直接丢掉,这样可以保证你能存储较多的日志数      据,也不担心容量增加的太快;
 
第三... 显示全部 »
这个有三种思路,
第一种:设置入ES的条件,0-8点的日志数据就不入ES,这样就不需要有删除的操作;
 
第二种:整理这类日志,将需要的数据 转存到新的索引下,不需要的直接丢掉,这样可以保证你能存储较多的日志数      据,也不担心容量增加的太快;
 
第三种:楼上提的那种方法,官网上只是一个实验性的API,按照官网描述,这个操作应该是比较耗资源的;
 
综上:你还是考虑第一种方法吧,不收集不需要的时间段的数据
kennywu76

kennywu76 回答了问题 • 2017-01-04 11:38 • 2 个回复 不感兴趣

新增节点数据均衡.

赞同来自:

对于新增结点是数据的平衡, shard balancing heuristics这个调整比较难以精确控制。 推荐使用索引级别设置: index.routing.allocation.total_shards_per_node  , 这个参数可以控制单个索引在同... 显示全部 »
对于新增结点是数据的平衡, shard balancing heuristics这个调整比较难以精确控制。 推荐使用索引级别设置: index.routing.allocation.total_shards_per_node  , 这个参数可以控制单个索引在同一个结点上最多分配几个shard。 默认是无上限,因此在扩容新结点的时候,很可能一个索引的很多shard分到同一个node。 具体设置多少,需要根据集群结点数量和一个index shard总数量(包含主和副复制片)来定。
 
例如10个node,  index设置 5 primary + 5 replica。 设置index.routing.allocation.total_shards_per_node:1 可以保证这个索引在每个node上只分配一个shard。  这样设置好处是数据分布最均匀, 但是也有负面影响,比如如果有一个node挂了,就会有一个shard无法分配,变成UNASSIGNED状态。  如果设置index.routing.allocation.total_shards_per_node:2 ,则可能数据均衡状态不如设置为1那么理想,但是可以容忍一个node挂掉,因为shard可以再分配到其他node。   这个设置结合shard balancing heuristics做全局调配应该比较理想。

elasticsearch能不能进行分组聚合的同时对聚合结果进行分页?求助!!!

回复

Elasticsearchbingyuf2012 回复了问题 • 5 人关注 • 4 个回复 • 346 次浏览 • 3 天前 • 来自相关话题

求复杂业务下数据导入elasticsearch的解决方案

回复

Elasticsearchbingyuf2012 回复了问题 • 2 人关注 • 1 个回复 • 303 次浏览 • 3 天前 • 来自相关话题

【新人求助】kibana-5.4.1错误Cannot assign to read only property '__esModule'

回复

Kibanadbnaxlc 回复了问题 • 1 人关注 • 1 个回复 • 229 次浏览 • 4 天前 • 来自相关话题

logstash-input-jdbc 数据无法导入到已经存在的索引库?

回复

LogstashNovemberRain_Jack 回复了问题 • 3 人关注 • 2 个回复 • 240 次浏览 • 4 天前 • 来自相关话题

elasticsearch拼音提示指定字段问题

回复

Elasticsearchwengqiankun 回复了问题 • 3 人关注 • 2 个回复 • 440 次浏览 • 5 天前 • 来自相关话题

elasticsearch高亮关键词在原文中的位置

回复

Elasticsearchwcx945 发起了问题 • 2 人关注 • 0 个回复 • 262 次浏览 • 5 天前 • 来自相关话题

springboot集成elasticSearch问题

回复

Elasticsearchtoken01 回复了问题 • 3 人关注 • 3 个回复 • 309 次浏览 • 5 天前 • 来自相关话题

分组查询排序问题

回复

Elasticsearchhailang 回复了问题 • 2 人关注 • 2 个回复 • 267 次浏览 • 2017-06-19 17:03 • 来自相关话题

es节点load特别高,cpu等使用率基本为0,不可恢复。

回复

Elasticsearchmedcl 回复了问题 • 3 人关注 • 2 个回复 • 343 次浏览 • 2017-06-19 11:35 • 来自相关话题

elasticsearch问题 急急

回复

Elasticsearchmedcl 回复了问题 • 3 人关注 • 3 个回复 • 328 次浏览 • 2017-06-19 11:17 • 来自相关话题

模糊查询导致Elasticsearch服务宕机

Elasticsearchkennywu76 发表了文章 • 1 个评论 • 477 次浏览 • 2017-06-15 10:32 • 来自相关话题

之前我在社区里写过 《ElasticSearch集群故障案例分析: 警惕通配符查询》一文,讲的是关于通配符查询可能引起ES集群负载过高的问题。 当时提到wildcard query构造的non-deterministic automaton要经历一个determinize的过程,其间如果生成的状态数量过高,可能引起集群负载彪高,影响对外服务。 但因为determinize的过程中,Lucene对生成的状态数量做了限制,因此在问题查询过去以后,集群还是可以恢复常态。
 
然而近期我们线上的另外一起故障,使我意识到,Prefix/Regex/Fuzzy一类的模糊查询可能直接让整个集群直接挂掉。
 
问题出现时,ES服务端日志有如下报错:

[2017-06-14T21:06:39,330][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [xx.xx.xx.xx] fatal error in thread [elasticsearch[xx.xx.xx.xx][search][T#29]], exiting
java.lang.StackOverflowError
        at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
        at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
        at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
        at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]

调查后发现,Prefix/Regex/Fuzzy一类的Query,是直接构造的deterministic automaton,如果查询字符串过长,或者pattern本身过于复杂,构造出来的状态过多,之后一个isFinite的Lucene方法调用可能产生堆栈溢出。
 
一个可以复现问题的regex query如下:$(document).ready(function() {$('pre code').each(function(i, block) { hljs.highlightBlock( block); }); });POST /test/_search
{
"query": {
"regexp": {
"test": "t{1,9500}"
}
}
}Github上的issue链接: issues/24553。 

对于我们这次特定的问题,是因为prefix Query里没有限制用户输入的长度。 看ES的源码,PrefixQuery继承自Lucene的AutomatonQuery,在实例化的时候,maxDeterminizedStates传的是Integer.MAX_VALUE, 并且生成automaton之前,prefix的长度也没有做限制。 个人认为这里可能应该限制一下大小,避免产生过多的状态:public class PrefixQuery extends AutomatonQuery {

/** Constructs a query for terms starting with <code>prefix</code>. */
public PrefixQuery(Term prefix) {
// It's OK to pass unlimited maxDeterminizedStates: the automaton is born small and determinized:
super(prefix, toAutomaton(prefix.bytes()), Integer.MAX_VALUE, true);
if (prefix == null) {
throw new NullPointerException("prefix must not be null");
}




 最终抛出异常的代码是
org.apache.lucene.util.automaton.Operations.isFinite,  
可以看到这段代码里用了递归,递归的深度取决于状态转移的数量。根据注释的说明,这是一段待完善的代码,因为使用了递归,可能导致堆栈溢出: // TODO: not great that this is recursive... in theory a
// large automata could exceed java's stack
private static boolean isFinite(Transition scratch, Automaton a, int state, BitSet path, BitSet visited) {
path.set(state);
int numTransitions = a.initTransition(state, scratch);
for(int t=0;t<numTransitions;t++) {
a.getTransition(state, t, scratch);
if (path.get(scratch.dest) || (!visited.get(scratch.dest) && !isFinite(scratch, a, scratch.dest, path, visited))) {
return false;
}
}
path.clear(state);
visited.set(state);
return true;
}
由此可见,在项目里使用了模糊查询的同学,一定一定要注意限制用户输入长度,否则可能导致集群负载过高或者整个挂掉。 
 
虽然Lucene/Elasticsearch应该在代码层面做一些限制,确保有问题的query不会导致stack overflow,但是当用到这类查询的时候,程序员的思维方式还局限在RDBMS开发的时代。 我们应该多在数据索引阶段下功夫,确保尽量用最高效的term query来完成绝大多数的查询。  查看全部
之前我在社区里写过 《ElasticSearch集群故障案例分析: 警惕通配符查询》一文,讲的是关于通配符查询可能引起ES集群负载过高的问题。 当时提到wildcard query构造的non-deterministic automaton要经历一个determinize的过程,其间如果生成的状态数量过高,可能引起集群负载彪高,影响对外服务。 但因为determinize的过程中,Lucene对生成的状态数量做了限制,因此在问题查询过去以后,集群还是可以恢复常态。
 
然而近期我们线上的另外一起故障,使我意识到,Prefix/Regex/Fuzzy一类的模糊查询可能直接让整个集群直接挂掉。
 
问题出现时,ES服务端日志有如下报错:


[2017-06-14T21:06:39,330][ERROR][o.e.b.ElasticsearchUncaughtExceptionHandler] [xx.xx.xx.xx] fatal error in thread [elasticsearch[xx.xx.xx.xx][search][T#29]], exiting
java.lang.StackOverflowError
        at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
        at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
        at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]
        at org.apache.lucene.util.automaton.Operations.isFinite(Operations.java:1053) ~[lucene-core-6.2.1.jar:6.2.1 43ab70147eb494324a1410f7a9f16a896a59bc6f - shalin - 2016-09-15 05:15:20]


调查后发现,Prefix/Regex/Fuzzy一类的Query,是直接构造的deterministic automaton,如果查询字符串过长,或者pattern本身过于复杂,构造出来的状态过多,之后一个isFinite的Lucene方法调用可能产生堆栈溢出。
 
一个可以复现问题的regex query如下:
POST /test/_search
{
"query": {
"regexp": {
"test": "t{1,9500}"
}
}
}
Github上的issue链接: issues/24553。 

对于我们这次特定的问题,是因为prefix Query里没有限制用户输入的长度。 看ES的源码,PrefixQuery继承自Lucene的AutomatonQuery,在实例化的时候,maxDeterminizedStates传的是Integer.MAX_VALUE, 并且生成automaton之前,prefix的长度也没有做限制。 个人认为这里可能应该限制一下大小,避免产生过多的状态:
public class PrefixQuery extends AutomatonQuery {

/** Constructs a query for terms starting with <code>prefix</code>. */
public PrefixQuery(Term prefix) {
// It's OK to pass unlimited maxDeterminizedStates: the automaton is born small and determinized:
super(prefix, toAutomaton(prefix.bytes()), Integer.MAX_VALUE, true);
if (prefix == null) {
throw new NullPointerException("prefix must not be null");
}




 最终抛出异常的代码是
org.apache.lucene.util.automaton.Operations.isFinite,  
可以看到这段代码里用了递归,递归的深度取决于状态转移的数量。根据注释的说明,这是一段待完善的代码,因为使用了递归,可能导致堆栈溢出:
  // TODO: not great that this is recursive... in theory a
// large automata could exceed java's stack
private static boolean isFinite(Transition scratch, Automaton a, int state, BitSet path, BitSet visited) {
path.set(state);
int numTransitions = a.initTransition(state, scratch);
for(int t=0;t<numTransitions;t++) {
a.getTransition(state, t, scratch);
if (path.get(scratch.dest) || (!visited.get(scratch.dest) && !isFinite(scratch, a, scratch.dest, path, visited))) {
return false;
}
}
path.clear(state);
visited.set(state);
return true;
}

由此可见,在项目里使用了模糊查询的同学,一定一定要注意限制用户输入长度,否则可能导致集群负载过高或者整个挂掉。 
 
虽然Lucene/Elasticsearch应该在代码层面做一些限制,确保有问题的query不会导致stack overflow,但是当用到这类查询的时候,程序员的思维方式还局限在RDBMS开发的时代。 我们应该多在数据索引阶段下功夫,确保尽量用最高效的term query来完成绝大多数的查询。 

Elasticsearch 5.4.1 和 5.3.3 发布

资讯动态medcl 发表了文章 • 0 个评论 • 570 次浏览 • 2017-06-02 09:46 • 来自相关话题

昨日 Elastic 正式发布针对 5.4 Bug 的修复版本 Elasticsearch 5.4.1(基于 Lucene6.5.1 ),以及基于 Lucene6.4.2的 Elasticsearch 5.3.3。 Elasticsearch 5.4.1 是目前最新的稳定版本,在官方的 Elastic Cloud 上已可以直接部署和升级。此次发布包括两个安全补丁-- 所有 X-Pack Security 用户都应该升级。

5.4.x 相关链接:
Elasticsearch 5.4.1 下载地址
Elasticsearch 5.4.1 发行说明
Elasticsearch 5.4 重要改变
X-Pack 5.4.1 发行说明

5.3.x 相关链接:
Elasticsearch 5.3.3 下载地址
Elasticsearch 5.3.3 发行说明
Elasticsearch 5.3.3 重要改变
X-Pack 5.3.3 发行说明

你可以通过阅读上面的详细的发行说明来了解具体的发布内容,下面是一些重点摘要:

X-Pack Document Level Security and Aliases (ESA-2017-09) 

X-Pack 安全组件在版本 5.4.1 和 5.3.3 之前对于索引别名的文档层面的安全设置存在漏洞,这个 bug 允许单个用户在特定的操作下能通过别名查看未经允许的数据。

影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。

解决方案
所有 X-Pack 安全组件的用户升级到 5.3.3 或者 5.4.1。如果不能升级,通过禁用索引层面的 request cache 可以临时解决这个问题。

CVE ID: CVE-2017-8441

 
X-Pack Privilege Escalation (ESA-2017-06)

修复 run_as 功能存在的一个特权扩大的bug。正常情况下,当使用run_as执行某些操作会以特定的身份来执行,这个bug 让用户无法正常转换为 run_as 指定的用户身份,从而导致查询失败和结果异常。

如果你不使用 run_as 功能或 _user 属性,则不受此bug影响。

影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。

解决方案
建议升级 Elastic Stack 到 5.4.1,如果不能升级,请移除模板里面的 {{_user.username}} 占位符并确保 run_as 设置不会被不可信用户修改。

CVE ID: CVE-2017-8438


其它重要变化:
修复 bug,单分片进行 scroll 操作可能引起 X-Pack Security 造成节点僵死及 OOM。Elasticsearch 5.4.0 启用 TLS 不能对 5.3.x 和之前的节点进行认证。LDAP 认证用户在撤销认证之后后可能任然驻留在缓存。现在,Netty在处理线程池、缓冲池和其他资源时,尊重处理器的设置,而不是在其他容器上运行时,可能会对这些资源进行过度的调整。对关闭的索引进行 Index setting 修改将进行验证,保护因为错误的配置造成索引无法打开的问题。修复 TransportClient 关于嗅探可能造成客户端挂起的异常。修复在KERBEROS安全模式,HDFS repository 插件与 Java Security Manager 发生的冲突。修复 Snapshot/restore 在 Elasticsearch 5.2.x 及之前的版本在取回所有快照时异常缓慢的问题。

 
最后,请下载和试用最新的 Elasticsearch 5.4.1,欢迎前往GitHub issue反馈任何遇到的问题。 查看全部
昨日 Elastic 正式发布针对 5.4 Bug 的修复版本 Elasticsearch 5.4.1(基于 Lucene6.5.1 ),以及基于 Lucene6.4.2的 Elasticsearch 5.3.3。 Elasticsearch 5.4.1 是目前最新的稳定版本,在官方的 Elastic Cloud 上已可以直接部署和升级。此次发布包括两个安全补丁-- 所有 X-Pack Security 用户都应该升级。

5.4.x 相关链接:
Elasticsearch 5.4.1 下载地址
Elasticsearch 5.4.1 发行说明
Elasticsearch 5.4 重要改变
X-Pack 5.4.1 发行说明

5.3.x 相关链接:
Elasticsearch 5.3.3 下载地址
Elasticsearch 5.3.3 发行说明
Elasticsearch 5.3.3 重要改变
X-Pack 5.3.3 发行说明

你可以通过阅读上面的详细的发行说明来了解具体的发布内容,下面是一些重点摘要:

X-Pack Document Level Security and Aliases (ESA-2017-09) 

X-Pack 安全组件在版本 5.4.1 和 5.3.3 之前对于索引别名的文档层面的安全设置存在漏洞,这个 bug 允许单个用户在特定的操作下能通过别名查看未经允许的数据。

影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。

解决方案
所有 X-Pack 安全组件的用户升级到 5.3.3 或者 5.4.1。如果不能升级,通过禁用索引层面的 request cache 可以临时解决这个问题。

CVE ID: CVE-2017-8441

 
X-Pack Privilege Escalation (ESA-2017-06)

修复 run_as 功能存在的一个特权扩大的bug。正常情况下,当使用run_as执行某些操作会以特定的身份来执行,这个bug 让用户无法正常转换为 run_as 指定的用户身份,从而导致查询失败和结果异常。

如果你不使用 run_as 功能或 _user 属性,则不受此bug影响。

影响版本
X-Pack Security 从 5.0.0 到 5.4.0 都受影响。

解决方案
建议升级 Elastic Stack 到 5.4.1,如果不能升级,请移除模板里面的 {{_user.username}} 占位符并确保 run_as 设置不会被不可信用户修改。

CVE ID: CVE-2017-8438


其它重要变化:
  1. 修复 bug,单分片进行 scroll 操作可能引起 X-Pack Security 造成节点僵死及 OOM。
  2. Elasticsearch 5.4.0 启用 TLS 不能对 5.3.x 和之前的节点进行认证。
  3. LDAP 认证用户在撤销认证之后后可能任然驻留在缓存。
  4. 现在,Netty在处理线程池、缓冲池和其他资源时,尊重处理器的设置,而不是在其他容器上运行时,可能会对这些资源进行过度的调整。
  5. 对关闭的索引进行 Index setting 修改将进行验证,保护因为错误的配置造成索引无法打开的问题。
  6. 修复 TransportClient 关于嗅探可能造成客户端挂起的异常。
  7. 修复在KERBEROS安全模式,HDFS repository 插件与 Java Security Manager 发生的冲突。
  8. 修复 Snapshot/restore 在 Elasticsearch 5.2.x 及之前的版本在取回所有快照时异常缓慢的问题。


 
最后,请下载和试用最新的 Elasticsearch 5.4.1,欢迎前往GitHub issue反馈任何遇到的问题。

GZIP造成JAVA Native Memory泄漏案例

Elasticsearchkennywu76 发表了文章 • 8 个评论 • 701 次浏览 • 2017-05-24 12:33 • 来自相关话题

[携程旅行网  吴晓刚]

近期公司某个线上JAVA应用出现内存泄漏问题,整个排查过程颇费周折,前后耗费了近2周才定位到问题根源并予以修复。排查问题过程中在网上翻查了大量的资料,发现国内几乎没有文章能对同类问题做透彻的分析和找到问题真正根源的。即使国外的各类博客和文章,也少有正确的分析。因此感觉有必要对问题根源和相关案例做一个总结,希望能为国内开发者避免踩上同类陷阱提供一些帮助。

开门见山,先列一下收集到的同类问题案例集:
Debugging Java Native Memory LeaksTracking Down Native Memory Leaks in ElasticsearchCompressingStoredFieldsFormat should reclaim memory more aggressivelyClose InputStream when receiving cluster state in PublishClusterStateActionKafka OOM During Log Recovery Due to Leaked Native Memory

这些案例涉及到的不乏一些流行的开源软件如Lucene, Elasticsearch, Kafka,并且某些Bug版本在大量公司有线上部署。这些案例的问题根源都惊人的一致,即在JAVA里使用GZIP库进行数据流的压缩/解压之后,忘记调用流的close()方法,从而造成native memory的泄漏。

关于这类问题的分析方法和工具,上面收集的案例集里有非常详尽的描述,这里就不再班门弄斧一一赘述了。只结合我们自己的案例,做一个比较简短的介绍和总结。

我们公司这个案例的排查之所以花了近2个礼拜,其中一个重要原因是这个应用是通过Docker部署的。应用上线运行一段时间后,会被Docker的OOM killer给Kill掉,查看JVM监控数据却发现Heap使用得很少,甚至都没有old GC发生过,top里看这个JAVA进程的RSS内存占用远高于分配的Heap大小。很自然的,研发人员第一反应是底层系统的问题,注意力被转移到研究各种Docker内存相关的参数上。 而我知道ElasticCloud曾经也被某些版本的linux内核bug困扰,docker可能会误杀JVM (参见 Memory Issues We'll Remember),bug的内核版本和docker版本和我们线上部署的又很接近,因此这个内核bug也被加入到了怀疑列表中。 事后证明这个方向是错误的,浪费了一些时间。

在一段时间排查无果后,为了缩小排查范围,我们决定将这个应用部署到VM上做对比测试。结果内存泄漏问题依然存在,因而排除掉了Linux内核和docker本身的问题。

同期也参考过一篇关于DirectByteByffer造成堆外内存泄漏问题的分析博客,JVM源码分析之堆外内存完全解读 ,考虑到问题现象和我们类似,我们的应用也有用到netty,DBB泄漏也被列为怀疑对象。然而在JVM启动里参数里对MaxDirectMemorySize做了限制后,经过一段时间对外服务,JAVA进程的RSS仍然会远超过HEAP + MDM设置的大小。

这期间我们也使用过NMT 工具分析HEAP内存占用情况,然而这个工具报告出来的内存远小于RSS,也就是说这多出来的内存并没有被JVM本身用到,泄漏的是native memory。 JAVA应用产生native memory泄漏通常是在使用某些native库时造成的,因此注意力转移到JNI。

最终帮助我们找到正确方向的是开头列的 Debugging Java Native Memory Leaks 这篇由Twitter工程师写的博客。 博客里介绍了如何使用jemalloc来替换glibc的malloc,通过拦截和追踪JVM对native memory的分配申请,从而可以分析出HEAP以外的内存分配由哪些方法调用产生的。博客里提到产生泄漏的原因是忘记关闭GZIPOutputStream,巧合的是我们线上应用也使用了gzip压缩服务请求数据,于是查看了一下相关的代码,果然发现有忘记关闭的stream。 找到根源后,解决问题就简单了,一行代码修复。
 
对于ElasticSearch用户,要注意的是某些版本存在这个泄漏问题,对于小内存机器上运行的ES服务可能会有较大的影响。 可是官方没有明确列出所有受影响的版本,只在博客里提到5.2.1修复了这些问题。 因此如果你有顾虑的话,可以用top命令看一下ES JAVA进程的RSS消耗,如果大大于分配的HEAP,有可能就是中招啦。  查看全部
[携程旅行网  吴晓刚]

近期公司某个线上JAVA应用出现内存泄漏问题,整个排查过程颇费周折,前后耗费了近2周才定位到问题根源并予以修复。排查问题过程中在网上翻查了大量的资料,发现国内几乎没有文章能对同类问题做透彻的分析和找到问题真正根源的。即使国外的各类博客和文章,也少有正确的分析。因此感觉有必要对问题根源和相关案例做一个总结,希望能为国内开发者避免踩上同类陷阱提供一些帮助。

开门见山,先列一下收集到的同类问题案例集:


这些案例涉及到的不乏一些流行的开源软件如Lucene, Elasticsearch, Kafka,并且某些Bug版本在大量公司有线上部署。这些案例的问题根源都惊人的一致,即在JAVA里使用GZIP库进行数据流的压缩/解压之后,忘记调用流的close()方法,从而造成native memory的泄漏。

关于这类问题的分析方法和工具,上面收集的案例集里有非常详尽的描述,这里就不再班门弄斧一一赘述了。只结合我们自己的案例,做一个比较简短的介绍和总结。

我们公司这个案例的排查之所以花了近2个礼拜,其中一个重要原因是这个应用是通过Docker部署的。应用上线运行一段时间后,会被Docker的OOM killer给Kill掉,查看JVM监控数据却发现Heap使用得很少,甚至都没有old GC发生过,top里看这个JAVA进程的RSS内存占用远高于分配的Heap大小。很自然的,研发人员第一反应是底层系统的问题,注意力被转移到研究各种Docker内存相关的参数上。 而我知道ElasticCloud曾经也被某些版本的linux内核bug困扰,docker可能会误杀JVM (参见 Memory Issues We'll Remember),bug的内核版本和docker版本和我们线上部署的又很接近,因此这个内核bug也被加入到了怀疑列表中。 事后证明这个方向是错误的,浪费了一些时间。

在一段时间排查无果后,为了缩小排查范围,我们决定将这个应用部署到VM上做对比测试。结果内存泄漏问题依然存在,因而排除掉了Linux内核和docker本身的问题。

同期也参考过一篇关于DirectByteByffer造成堆外内存泄漏问题的分析博客,JVM源码分析之堆外内存完全解读 ,考虑到问题现象和我们类似,我们的应用也有用到netty,DBB泄漏也被列为怀疑对象。然而在JVM启动里参数里对MaxDirectMemorySize做了限制后,经过一段时间对外服务,JAVA进程的RSS仍然会远超过HEAP + MDM设置的大小。

这期间我们也使用过NMT 工具分析HEAP内存占用情况,然而这个工具报告出来的内存远小于RSS,也就是说这多出来的内存并没有被JVM本身用到,泄漏的是native memory。 JAVA应用产生native memory泄漏通常是在使用某些native库时造成的,因此注意力转移到JNI。

最终帮助我们找到正确方向的是开头列的 Debugging Java Native Memory Leaks 这篇由Twitter工程师写的博客。 博客里介绍了如何使用jemalloc来替换glibc的malloc,通过拦截和追踪JVM对native memory的分配申请,从而可以分析出HEAP以外的内存分配由哪些方法调用产生的。博客里提到产生泄漏的原因是忘记关闭GZIPOutputStream,巧合的是我们线上应用也使用了gzip压缩服务请求数据,于是查看了一下相关的代码,果然发现有忘记关闭的stream。 找到根源后,解决问题就简单了,一行代码修复。
 
对于ElasticSearch用户,要注意的是某些版本存在这个泄漏问题,对于小内存机器上运行的ES服务可能会有较大的影响。 可是官方没有明确列出所有受影响的版本,只在博客里提到5.2.1修复了这些问题。 因此如果你有顾虑的话,可以用top命令看一下ES JAVA进程的RSS消耗,如果大大于分配的HEAP,有可能就是中招啦。 

ELK学习资料整理

经验分享lsyoung 发表了文章 • 0 个评论 • 1333 次浏览 • 2017-04-14 10:17 • 来自相关话题

刚开始学习使用ELK,整理一个学习资料列表,当做备忘录。
 
1.第一个当然是官方文档
ElasticSearch参考手册,学习 DSL查询语法,包括查找(query)、过滤(filter)和聚合(aggs)等。Logstash参考手册,学习数据导入,包括输入(input)、过滤(filter)和输出( output)等,主要是filter中如何对复杂文本 进行拆分和类型 转化。Kibana参考手册,使用Kibana提供的前端界面对数据进行快速展示,主要是对Visulize 模块的使
2.中文文档
ElasticSearchLogstash:Logstash 最佳实践,ELKStack中文指南Kibana:ELKStack中文指南
 
欢迎补充…… 查看全部
刚开始学习使用ELK,整理一个学习资料列表,当做备忘录。
 
1.第一个当然是官方文档
  • ElasticSearch参考手册,学习 DSL查询语法,包括查找(query)、过滤(filter)和聚合(aggs)等。
  • Logstash参考手册,学习数据导入,包括输入(input)、过滤(filter)和输出( output)等,主要是filter中如何对复杂文本 进行拆分和类型 转化。
  • Kibana参考手册,使用Kibana提供的前端界面对数据进行快速展示,主要是对Visulize 模块的使

2.中文文档

 
欢迎补充……

100种让ES宕机的方法,请详细描述过程,且可复现的。

ElasticsearchRicky_Lau 发表了文章 • 6 个评论 • 881 次浏览 • 2017-04-05 10:47 • 来自相关话题

大家好,最近这个客题需要大家的帮忙啦,后面会专门录个视频来汇总讲解这些 bad case.
 
OOM:
  方式1:
       版本: all
       深度分页和大数据量数据返回会导致OOM。  
  方式2:
       版本: es 1.x
       使用delete_by_query删除海量数据时,由于内部没有使用scroll模块,会由深度分页导致OOM
  方式3:
       版本: all
       使用scroll返回大量数据导致OOM
  查看全部
大家好,最近这个客题需要大家的帮忙啦,后面会专门录个视频来汇总讲解这些 bad case.
 
OOM:
  方式1:
       版本: all
       深度分页和大数据量数据返回会导致OOM。  
  方式2:
       版本: es 1.x
       使用delete_by_query删除海量数据时,由于内部没有使用scroll模块,会由深度分页导致OOM
  方式3:
       版本: all
       使用scroll返回大量数据导致OOM
 

Elasticsearch 2.x mapping tips

Elasticsearchnodexy 发表了文章 • 2 个评论 • 931 次浏览 • 2017-01-10 21:04 • 来自相关话题

elasticsearch 2.x mapping tips

作者:杨振涛  首发于:Elasticsearch 中文社区  日期:2017-1-10

如果把elasticsearch中的mapping类比为关系型数据库中的schema的话,那么我们可能重点强调了两者之间的共性,而忽略了elasticsearch里mapping很不相同的部分 —— 这恰恰是实践中最容易被坑的地方。这里总结了几点实践中的小心得,希望对你所有帮助。

mapping 基础
创建索引库indexcurl -XPOST "http://192.168.9.19:9200/vivo_vimc&quot;
查看指定索引库的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
curl -XPOST "http://192.168.9.19:9200/vivo_vimc&quot;

查看指定索引库的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移动互联网 搜索架构师,关注实时搜索,搜索广告,以及大数据的存储、索引、搜索和可视化。

ES5.0.0 安装记录

Elasticsearchsunping 发表了文章 • 1 个评论 • 1252 次浏览 • 2016-12-05 09:42 • 来自相关话题

创建用户:adduser elasticsearch
可查看创建结果:
##########/etc/passwd
##########/etc/shadow
##########/etc/group
配置环境变量
修改文件:/home/elasticsearch/.profile
追加内容:
export JAVA_HOME=/home/elasticsearch/java/jdk1.8.0_73
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$CLASSPATH
export PATH
配置elasticsearch5.0.0
tar -xf elasticsearch-5.0.0.tar.gz -C /home/elasticsearch/
cd /home/elasticsearch/
ln -sv elasticsearch-5.0.0 elasticsearch
mkdir -pv /esdata/elasticsearch/{data,logs}
chown -R elasticsearch.elasticsearch /esdata/elasticsearch
修改ES配置文件
/home/elasticsearch/elasticsearch-5.0.0/config/elasticsearch.yml
http.cors.enabled: true
http.cors.allow-origin: "*"
path.data: /esdata/elasticsearch/data
path.logs: /esdata/elasticsearch/logs
network.host: 192.168.25.57
http.port: 8201
transport.tcp.port: 8301
bootstrap.memory_lock: true
/home/elasticsearch/elasticsearch-5.0.0/config/jvm.options
-Xms8g
-Xmx8g
修改系统参数
/etc/security/limits.conf
elasticsearch soft nproc 65536
elasticsearch hard nproc 65536
elasticsearch soft nofile 65536
elasticsearch hard nofile 65536
elasticsearch - memlock unlimited
/etc/sysctl.conf
vm.max_map_count = 262144
加载更新:sysctl -p
启动ES服务
su - elasticsearch -c "/home/elasticsearch/elasticsearch/bin/elasticsearch &"
  查看全部

创建用户:adduser elasticsearch
可查看创建结果:
##########/etc/passwd
##########/etc/shadow
##########/etc/group
配置环境变量
修改文件:/home/elasticsearch/.profile
追加内容:
export JAVA_HOME=/home/elasticsearch/java/jdk1.8.0_73
export PATH=$JAVA_HOME/bin:$PATH
export CLASSPATH=.:$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar:$CLASSPATH
export PATH
配置elasticsearch5.0.0
tar -xf elasticsearch-5.0.0.tar.gz -C /home/elasticsearch/
cd /home/elasticsearch/
ln -sv elasticsearch-5.0.0 elasticsearch
mkdir -pv /esdata/elasticsearch/{data,logs}
chown -R elasticsearch.elasticsearch /esdata/elasticsearch
修改ES配置文件
/home/elasticsearch/elasticsearch-5.0.0/config/elasticsearch.yml
http.cors.enabled: true
http.cors.allow-origin: "*"
path.data: /esdata/elasticsearch/data
path.logs: /esdata/elasticsearch/logs
network.host: 192.168.25.57
http.port: 8201
transport.tcp.port: 8301
bootstrap.memory_lock: true
/home/elasticsearch/elasticsearch-5.0.0/config/jvm.options
-Xms8g
-Xmx8g
修改系统参数
/etc/security/limits.conf
elasticsearch soft nproc 65536
elasticsearch hard nproc 65536
elasticsearch soft nofile 65536
elasticsearch hard nofile 65536
elasticsearch - memlock unlimited
/etc/sysctl.conf
vm.max_map_count = 262144
加载更新:sysctl -p
启动ES服务
su - elasticsearch -c "/home/elasticsearch/elasticsearch/bin/elasticsearch &"
 

Pandasticsearch: An Elasticsearch client exposing DataFrame API

Elasticsearchonesuper 发表了文章 • 0 个评论 • 716 次浏览 • 2016-11-08 18:02 • 来自相关话题

https://github.com/onesuper/pandasticsearch
 
# Create a DataFrame object
from pandasticsearch import DataFrame
df = DataFrame.from_es('http://localhost:9200', index='people')

# Print the schema(mapping) of the index
df.print_schema()
# company
# |-- employee
# |-- name: {'index': 'not_analyzed', 'type': 'string'}
# |-- age: {'type': 'integer'}
# |-- gender: {'index': 'not_analyzed', 'type': 'string'}

# Inspect the columns
df.columns
#['name', 'age', 'gender']

# Get the column
df.name
# Column('name')

# Filter
df.filter(df.age < 13).collect()
# [Row(age=12,gender='female',name='Alice'), Row(age=11,gender='male',name='Bob')]

# Project
df.filter(df.age < 25).select('name', 'age').collect()
# [Row(age=12,name='Alice'), Row(age=11,name='Bob'), Row(age=13,name='Leo')]

# Print the rows into console
df.filter(df.age < 25).select('name').show(3)
# +------+
# | name |
# +------+
# | Alice|
# | Bob |
# | Leo |
# +------+

# Sort
df.sort(df.age.asc).select('name', 'age').collect()
#[Row(age=11,name='Bob'), Row(age=12,name='Alice'), Row(age=13,name='Leo')]

# Aggregate
df[df.gender == 'male'].agg(df.age.avg).collect()
# [Row(avg(age)=12)]

# Groupby
df.groupby('gender').collect()
# [Row(doc_count=1), Row(doc_count=2)]

# Groupby and then aggregate
df.groupby('gender').agg(df.age.max).collect()
# [Row(doc_count=1, max(age)=12), Row(doc_count=2, max(age)=13)]

# Convert to Pandas object for subsequent analysis
df[df.gender == 'male'].agg(df.age.avg).to_pandas()
# avg(age)
# 0 12 查看全部
https://github.com/onesuper/pandasticsearch
 
# Create a DataFrame object
from pandasticsearch import DataFrame
df = DataFrame.from_es('http://localhost:9200', index='people')

# Print the schema(mapping) of the index
df.print_schema()
# company
# |-- employee
# |-- name: {'index': 'not_analyzed', 'type': 'string'}
# |-- age: {'type': 'integer'}
# |-- gender: {'index': 'not_analyzed', 'type': 'string'}

# Inspect the columns
df.columns
#['name', 'age', 'gender']

# Get the column
df.name
# Column('name')

# Filter
df.filter(df.age < 13).collect()
# [Row(age=12,gender='female',name='Alice'), Row(age=11,gender='male',name='Bob')]

# Project
df.filter(df.age < 25).select('name', 'age').collect()
# [Row(age=12,name='Alice'), Row(age=11,name='Bob'), Row(age=13,name='Leo')]

# Print the rows into console
df.filter(df.age < 25).select('name').show(3)
# +------+
# | name |
# +------+
# | Alice|
# | Bob |
# | Leo |
# +------+

# Sort
df.sort(df.age.asc).select('name', 'age').collect()
#[Row(age=11,name='Bob'), Row(age=12,name='Alice'), Row(age=13,name='Leo')]

# Aggregate
df[df.gender == 'male'].agg(df.age.avg).collect()
# [Row(avg(age)=12)]

# Groupby
df.groupby('gender').collect()
# [Row(doc_count=1), Row(doc_count=2)]

# Groupby and then aggregate
df.groupby('gender').agg(df.age.max).collect()
# [Row(doc_count=1, max(age)=12), Row(doc_count=2, max(age)=13)]

# Convert to Pandas object for subsequent analysis
df[df.gender == 'male'].agg(df.age.avg).to_pandas()
# avg(age)
# 0 12

在一个Elasticsearch集群中可以使用过个版本数据节点共存吗?

Elasticsearchbong 发表了文章 • 3 个评论 • 844 次浏览 • 2016-07-21 10:35 • 来自相关话题

我们现在Elasticsearch的版本较老,然后数据量比较大,我不知道有平滑升级的方案不?如果有,该怎么做?如果没有,我是否可以把新版本的节点加入到老版本的集群中使用,两个版本共存,然后最后老数据删除,老版本的数据节点也就删除了,想问一下我想的方案是否可行?
 
两个版本共存在一个集群中,会出现哪些可预知的问题?还希望了解的同学回答一下?谢谢! 查看全部
我们现在Elasticsearch的版本较老,然后数据量比较大,我不知道有平滑升级的方案不?如果有,该怎么做?如果没有,我是否可以把新版本的节点加入到老版本的集群中使用,两个版本共存,然后最后老数据删除,老版本的数据节点也就删除了,想问一下我想的方案是否可行?
 
两个版本共存在一个集群中,会出现哪些可预知的问题?还希望了解的同学回答一下?谢谢!

尝试翻译 ElasticSearch 官方文档

Elasticsearchpangpang 发表了文章 • 9 个评论 • 1613 次浏览 • 2016-07-08 10:13 • 来自相关话题

最近有翻译官网文档的念头,从上周开始陆陆续续的抽时间翻译,因为工作比较忙,都是晚上熬夜开始翻译的。想要翻译官方文档的原因主要有这几点:
官方文档写的比较好,例子多,容易理解;已有的翻译资料感觉并不是很完善,要么只翻译了一部分,要么版本很旧,很久没人维护(有人翻译 ElasticSearch 权威指南,这个还是不错);自己在工作中经常用到 ElasticSearch,感觉 ElasticSearch 非常强大,帮助我们解决了很多问题,让我有激情去更深入的探索;希望可以帮助到别人;
 
github:  https://github.com/liuzxc/Elas ... ce_cn
 
read online :   https://liuzxc.gitbooks.io/ela ... tent/
 
我现在基本上每天翻译 1- 2 节的样子,会持续更新下去,有兴趣的伙伴可以加入进来一起搞! 查看全部
最近有翻译官网文档的念头,从上周开始陆陆续续的抽时间翻译,因为工作比较忙,都是晚上熬夜开始翻译的。想要翻译官方文档的原因主要有这几点:
  1. 官方文档写的比较好,例子多,容易理解;
  2. 已有的翻译资料感觉并不是很完善,要么只翻译了一部分,要么版本很旧,很久没人维护(有人翻译 ElasticSearch 权威指南,这个还是不错);
  3. 自己在工作中经常用到 ElasticSearch,感觉 ElasticSearch 非常强大,帮助我们解决了很多问题,让我有激情去更深入的探索;
  4. 希望可以帮助到别人;

 
github:  https://github.com/liuzxc/Elas ... ce_cn
 
read online :   https://liuzxc.gitbooks.io/ela ... tent/
 
我现在基本上每天翻译 1- 2 节的样子,会持续更新下去,有兴趣的伙伴可以加入进来一起搞!