https://www.elastic.co/blog/we ... amily
https://techcrunch.com/2017/06 ... tion/
 
 
Today, at Elastic’s customer event in London, the company announced it has acquired Opbeat, a SaaS-application performance management vendor for an undisclosed amount. All 15 employees have already joined the Elastic team.

Opbeat focuses on monitoring applications written in Javascript. What’s more, it maps production application issues directly to the relevant developer source code, making it easier to fix the problem without having to hunt in the code to find the problem area.

Elastic is probably best known for its search product, Elasticsearch, an open source search tool that runs on some of the world’s biggest properties including Wikipedia, Yelp and eBay. In recent years, the company has moved beyond straight search and into analytics, particularly focusing on log data that puts them squarely in competition with companies like Splunk. Last year, it pulled all of the products together into a platform play they called Elastic Stack.

Elastic CEO Shay Banon sees today’s acquisition through a strategic lens, giving his company a leg up on the competition by offering not only a way to search log data, but also giving insights into the applications that are generating the data and why they may be performing poorly.

Rasmus Makwarth, who was CEO at Opbeat says joining Elastic allows the company to speed up the product roadmap and take advantage of the breadth of the Elastic platform. “We’ve been running a SaaS platform for some time now, giving application insights to developers, but haven’t been able to give customers insight into the entire application,” he explained. Joining Elastic lets his company take advantage of the search tool, as well as analytics, logging and data visualization available on the Elastic platform to greatly expand the vision.

Opbeat’s employees have already joined Elastic and are working with the Elastic team to build an on-prem application to go with the existing SaaS piece. Banon said that the company hopes to take advantage of Opbeat’s cloud background to expand its cloud offerings.

Taking a cloud-native application and engineering it to be on-prem is no simple task, but the two companies hope to have an on-prem version ready in several month. It’s worth noting that Opbeat was using Elasticsearch in its product, but as Banon pointed out using a product and making it part of the stack are two different matters, and it will take a significant engineering effort to incorporate the new company into the fold as both a cloud and on-prem product.

You may recall that Cisco bought APM vendor AppDynamics earlier this year for $3.7 billion right before the company was about to IPO. While Banon wouldn’t reveal today’s purchase price, he joked that it was substantially less than that.

Given that Opbeat was founded in 2013 in Copenhagen, Denmark and has raised approximately $2.8 million, that’s a fair bet. The company will remain in Denmark. 收起阅读 »

ELK入门搭建参考文章

报名链接：http://elasticsearch.mikecrm.com/O6o0yq3 
 
1.举办方
主办：Elastic 中文社区  
 
协办：魔蝎科技



独家直播：
 
IT大咖说




2. 时间地点
 活动时间：2017年6月25日 13:30 - 18:00 
 活动地点：杭州市西湖区文一西路767号西溪国际商务中心E座1楼会议室

3. 主题

分享一：基于ElasticSearch构建搜索云服务



演讲者简介：
陈超，七牛云技术总监，Spark Summit China 出品人， 专注于大规模分布式计算与机器学习领域。

主题简介：
介绍七牛基于 Elasticsearch 如何构建大规模搜索云服务的经验和思考。

分享二：采用Elasticsearch构建大规模通用搜索平台的经验分享


 
演讲者简介：
马华标 - 城破 蚂蚁金服中间件搜索负责人， 12年加入阿里巴巴任职于B2B中文站架构部、数据仓库架构组组长，14年加入蚂蚁金服担任中间件搜索负责人， 从事搜索方面的团队建设与产品研发工作。
 
主题简介：
介绍蚂蚁金服采用Elasticsearch构建大规模通用搜索平台的经验分享。
 
分享三：垂直搜索引擎系统架构



演讲者简介：
吴英昊  花名：丰坚

蚂蚁金服数据中间件技术专家，曾任职于当当网，担任搜索架构师（兼开发经理）职位，负责当当网的搜索后台的技术架构和技术团队的管理，包括搜索引擎架构，搜索排序和 Query 分析，后在一创业公司负责推荐和广告系统架构和算法相关工作。 目前在蚂蚁金服数据中间件搜索组技术专家。
主题简介： 
主题 “垂直搜索引擎系统架构”，介绍如何采用 Elasticsearch 构建大规模通用搜索平台。会穿插一些关于ES在垂直搜索中的应用和优化方向。


分享四：Metricbeat 在容器监控方面的应用



演讲者简介：
曾勇（Medcl） Elastic 工程师与布道师
Elasticsearch 爱好者，2015年加入 Elastic，Elastic 中文社区的发起人，Elastic 公司在中国的首位员工。

主题简介：
使用 Docker 或者其他的容器方案来进行部署已经成为热门，今天的分享将介绍如何使用 Metricbeat 来收集和监控您的容器化部署环境，结合 Elasticsearch 和 Kibana 对容器的性能进行全方位的了解。 收起阅读 »

POST /test/_search

{

  "query": {

    "regexp": {

      "test": "t{1,9500}"

    }

  }

}

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");

    }

  // 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;

  }

之前我在社区里写过 《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来完成绝大多数的查询。  收起阅读 »

ElasticHD 是一款 ElasticSearch的可视化应用。不依赖ES的插件安装，更便捷；导航栏直接填写对应的ES IP和端口就可以操作Es了。目前支持如下功能：

•  ES Real time data search
•  ES Dashboard data visualization
•  ES Index Template (在线修改、查看、上传）
•  ES Indices Index deletion and search
•  SQL Converts to Elasticsearch DSL
•  ES 基本查询文档

Install elasticHD
Precompiled binaries for supported operating systems are available.
Basic Usage

•   linux and MacOs use ElasticHD

1. 下载对应的elasticHD版本，unzip xxx_elasticHd_xxx.zip 
2. 修改权限 chmod 0777 ElasticHD 
3. 可指定ip端口运行elastichd ./ElasticHD -p 127.0.0.1:9800 默认 ip和端口也是这个

•  windows use ElasticHD 
• 直接下载对应windows版本,解压，双击运行。当然想指定端口的话同linux

  

 Application Info
  收起阅读 »

昨日 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反馈任何遇到的问题。 收起阅读 »

去年我们社区一起翻译了一本书《Elasticsearch权威指南》，并且已经在官方上线了，链接：
https://www.elastic.co/guide/cn/index.html 
 
撒花~ ???????????????????
 
我想给大家分享一些这本书后面的故事：
 
大家在浏览到前言章节里面有一节“鸣谢”，里面可以看到很多熟悉的名字：
 
薛杰，骆朗，彭秋源，魏喆，饶琛琳， 风虎，路小磊，michealzh，nodexy，sdlyjzh，落英流离， sunyonggang，Singham，烧碱，龙翔，陈思，陈华， 追风侃侃，Geolem，卷发，kfypmqqw，袁伟强，yichao， 小彬，leo，tangmisi，Alex，baifan，Evan，fanyer， wwb，瑞星，刘碧琴，walker，songgl， 吕兵，东，杜宁，秦东亮，biyuhao，刘刚， yumo，王秀文，zcola，gitqh，blackoon，David，韩炳辰， 韩陆，echolihao，Xargin，abel-sun，卞顺强， bsll，冬狼，王琦，Medcl。
 
是的，这些就是我们权威指南的核心的译者了，虽然只是列了一个名字，但是其实背后付出了很多，有一些同学是在此之前就已经做过部分翻译的同学，如：路小磊，有一些是早就出版了多本书的资深作家了，如：饶琛琳，还有很多是社区里面一直就非常活跃的同学，各种线上线下活动都能看到你们的身影，感谢你们。
 
记得去年刚刚开始这个翻译的计划的时候，短短几天时间就收到了很多同学的报名，一下子累积人数多达80人，
正所谓人多就是力量，不过任务的分配和管理也就成了一个问题，要知道权威指南纸质版有650多页，
很厚的一本书，内容也真是非常多。我记得项目应该是3月份启动，到了5月份还没什么大的进展，大家都在摸索怎么去翻译，大家都无从下手，我也着急啊??，这个时候要感谢社区的热心成员：龙翔，?，他把他老婆Claire拉到我们翻译计划里面来了，?，这个翻译的事情总算有了转机，Claire在翻译项目的管理这块很专业?，提出了很多建设性意见，✍️，我们成立了一个翻译小组委员会，?，然后形成了5个翻译小组，?，每个小组由一个小组长来负责（大家积极踊跃）：
A组：薛杰；
B组：骆朗；
C组：彭秋源；
D组：饶琛琳；
E组：魏喆；
这样，几十个翻译志愿者分别分到了不同的翻译小组，然后以翻译小组为单位进行翻译计划的分配和认领，任务也比较具体，小组成员再内部进行协调，有问题大家一起讨论，小组内部内也可以讨论，然后翻译就开始顺利的进行了！?
 
所以在这里要特别感谢龙翔两口子和几位翻译小组的小组长，当然还有各组的小组成员，如果没有你们，翻译工作估计要到进行到猴年马月啦，?，大家官网上面现在也看不到这些中文的资料啦！?
 
顺便值得一提的是，同时期还有另外一个开源社区也在翻译权威指南（韩文），并且比我们早开始，然后我们在去年12月份的时候就完成了，赶在Elastic{ON}DevChina大会之前完成的，而现在我们的已经上线了，也不知道他们的完成了没有，?。
 
权威指南的原作者Clinton和Zachary听说了我们的翻译的事情，都很兴奋，本来打算要来中国参加Elastic{ON}DevChina大会的，不过很遗憾，因为种种原因都没能过来，不过他们很支持我们，帮忙解决了后面上线的很多技术细节。
 
相信很多人想了解具体是怎么做的，我再给大家具体介绍一下，任务的管理和分配，我们使用GoogleDocs来进行协助，大家都有修改权限，常见的术语和FAQ也都会放在里面。
链接：[url=https://docs.google.com/spreadsheets/d/1vzPqcYJfz6ouY053E6WUdvS9WR8XqcHPyB7_U-72b_Q/edit?pref=2&pli=1#gid=1600884528]https://docs.google.com/spread ... 84528[/url]
 
另外关于本书翻译的项目管理，我们直接使用的是GitHub（https://github.com/elasticsear ... guide ），以asciidoc源文件为最小提交单元，每翻译完成一个文件，提交一个PR，每个PR单独Review，每个PR正常需要两个同学Review确认，正常的GitHub操作流程，和提交代码一样（文档其实本来也是和代码一样），翻译完成一篇之后，提交一个PR，打上标签“to be review”，表示翻译完了可以被Review了，Reviewer如果认可了就留言"LGTM", 然后打上标签“To be merged”，如果有不同意见，可以在PR上面留言讨论，PR提交人可以结合意见探讨或者修改，有些PR可以要讨论和修改很多次，比如这个：[url=https://github.com/elasticsearch-cn/elasticsearch-definitive-guide/pull/4]https://github.com/elasticsear ... ull/4[/url]，真的是不厌其烦，截止目前为止，总共提交了470多个翻译相关的PR。
 
为什么要以Asciidoc源文件作为翻译的基础，而不是gitdoc、wiki、markdown等等呢，因为我们可以保证后续的样式和官网一致，翻译审核完成之后就能够直接的放到官网上面，以提供给更多的人去访问和学习，同时官方的docs工具链也很完善，也支持编译输出成各种格式，如PDF等。另外文档和英文格式保持一致且也是托管在GitHub上面，方便后续的更新和维护，现在权威指南英文版正在更新到最新，到时候我们可以很方便的检测变化然后同步更新，文档即源码，文档是开源重要的一部分，参与开源的方式其实也有很多种，贡献代码和贡献文档都是同等重要的啦。可持续性更新也很重要。
 
是不是权威指南翻译完了之后就结束了呢，答案是：NO！
文档和代码一样，也有Bug，也要不断完善，虽然我们在提交翻译和Review的过程中有反复进行过修改和进行过多轮的Review，（先是小组内部进行第一轮Review，打上标签“To be final review”，然后再由另外一个组的同学进行Review，然后在打上“To be merge”），但是由于大家水平有限，难免会出现各种翻译不准确、格式、表达等问题，所有希望大家能够继续帮忙改进，可以继续提交PR来完善修改，如果说嫌麻烦，可以发Issue说明哪里有问题或者觉得可以再讨论的地方，提供建设性意见。
 
后续也会有新的翻译，也希望大家踊跃参加，为Elastic中文的社区贡献力量。
 
一直想写这篇文章，今天终于完成啦！
最后来一张上次来参加Elastic{ON}DevChina的译者合影！


 
收起阅读 »

 
1、深入详解Elasticearch：http://blog.csdn.net/column/de ... .html
 
2、这个专栏，起初主要用来研究关系型数据mysql/oracle非关系型数据库mongo与Elaticsearch的实时同步问题，随着延伸和项目需要，还会路线拓展ES java开发等问题；
 
3、之前的研究都是基于Elasticsearch2.3.4版本。基础原理想通。 5.X，6.X版本后续也会跟进。
 
欢迎大家品鉴，多提不足！
 
终生学习者：铭毅天下，博客地址：http://blog.csdn.net/laoyang360 收起阅读 »

职位描述：
岗位描述：
1、负责商城网站的设计、开发工作，制定和落实解决方案。
2、 保证平台的稳定性，并不断提升平台性能，协助解决系统中的问题和技术难题。

任职资格：
1、对高并发、多线程、缓存等技术和业务场景有实际操作经验；
2、JAVA基础扎实，对于中间件、SOA框架等原理有一定理解；
3、熟悉Linux下的常用操作，熟悉MySQL、Redis、MongoDB、elasticsearch、等开源数据库；
4、熟悉互联网产品架构，有大型分布式、高并发、高负载、高可用性系统设计开发经验者优先。
5、强烈的责任心与主动性，对所负责工作有owner意识，并能自我驱动成长；

在这里：
有最前沿技术的最佳实践场景：golang，nginx+lua，java，redis，docker，hadoop，storm，机器学习、elasticsearch。
有高并发，分布式，大数据挖掘的业务场景。
我们将为你提供跟身边大牛接触学习的机会。
我们将为你提供一个开放的技术环境，一个自由高效的团队，和一个改变现有技术的机会。
分享、自由、协作是我们的处事法则。

福利：
弹性工作时间，巨大的发展空间。
年假，双休，法定节假日。
六险一金，补充商业保险，丰厚的餐补，全面保障。
绝对竞争力的薪资及年终奖金，股票激励机制。
伴随公司发展的升职机会，及每年两次的调薪机会。 收起阅读 »

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，性能更强更简单。 收起阅读 »

[携程旅行网  吴晓刚]

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

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

• Debugging Java Native Memory Leaks
• Tracking Down Native Memory Leaks in Elasticsearch
• CompressingStoredFieldsFormat should reclaim memory more aggressively
• Close InputStream when receiving cluster state in PublishClusterStateAction
• Kafka 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，有可能就是中招啦。  收起阅读 »

Elastic search 服务供应商需要招聘培训师/项目经理

薪酬： 月工资20k +
工作地点：北京/上海/深圳                     愿意出差，因工作情况会全国飞

任职要求：

1、计算机相关专业，本科以上学历，具有3年以上搜索引擎及相关开发经验；

2、较强的java编程基础，熟悉Git代码管理，有多分支并行开发经验；

3、熟练使用开源搜索工具Logstash，ElasticSearch，熟悉其原理和源代码，能熟练的修改开源工具以适合业务场景的需求；

4、熟悉Lucene以及Kibana，有实际的产品使用经历；

5、具有良好的沟通能力和责任心。
  收起阅读 »

1.下面简述下如何根据explain解释TFIDF和BM25的评分计算
2.首先是TFIDF
使用ik_smart分词器，ES为2.3.3
文档是：分词结果是
"伟业我爱我家"     分词结果：【伟业，我，爱我，家】
"我爱我家"     【我，爱我，家】
这两个。
multi_match  匹配，query=我爱我家
排名如下
-----------------------------------------------------------
"伟业我爱我家"    "_score": 6.8563557,
详细参数 
"我"：tf=1,idf=6.7638364,fieldNorm=0.5，queryNorm=0.07292504,
“爱我”： tf=1,idf=6.7638364,fieldNorm=0.5，queryNorm=0.07292504
“家”： tf=1,idf=6.278329,fieldNorm=0.5，queryNorm=0.07292504
----------------------------------------------------------
"我爱我家"          "_score": 6.7839246,
"我"：tf=1,idf=6.9336233,fieldNorm=0.5，queryNorm=0.07370365,
“爱我”： tf=1,idf=6.9336233,fieldNorm=0.5，queryNorm=0.07370365
“家”： tf=1,idf=6.9336233,fieldNorm=0.5，queryNorm=0.07370365
---------------------------------------------------------
其中queryNorm是由每个term词项的idf综合计算而来，所以在每个文档中，他都是一样的。
然后仔细比较得分，觉得每个得分都可以被推算出来
但是排序结果不符合期望：
queryNorm 官方文档也说了基本没有什么用
tf=1没什么可说
idf有些问题，比如"爱我"在这两个文档中是不同的(这是因为这两个文档在不同的分片中引起的)
那这么说来，TFIDF的得分就仅仅受tf,idf，fieldNorm控制，
而idf因为分片不均匀可能会出现一点差异，fieldNorm又犹由于精度让长度为3或者4 的文档值都为0.5
。综上：tfidf在这种量不多(200万)的短文本检索下，效果很差。
这种情况下，我该怎么优化这个排序呢（让“我爱我家”，排在"伟业我爱我家"前面呢？）
 
 
 
------------------BM25的详情稍后补上-------------------------
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
  收起阅读 »

一直想找一个数据库用于存储各种的代码片段

mysql会一点 mongodb也看过

但是最终都没有弄成（或许是我性格的原因，想的太多，做的太少（算是过度设计的一种吧））

后来发现了ElasticSearch

觉得他能够实现我的想法（或许只是他简介里的一句话，大致的意思是：多看看数据，而非让他们躺在仓库里）

我会将过程记录下来，希望对后来人有帮助

（不过一切都是在Emacs环境下的，知道的人应该不多，所以能帮到的人也就更少了（其实他们也不用我帮）） 收起阅读 »

      大家好，我是重构人生，很开心能在这里和大家分享我的免费Elasticsearch 视频教程。 我是一个Elasticsearch 的DevOps ，使用了很久的开源软件，在开源社区也获得过很多小伙伴的帮助。我希望自己能为社区贡献自己的一份力。
 
      我应该算是个热心肠的人吧，喜欢乐于助人，不过有些人的提问方式让我非常反感，甚至是厌恶，什么样的人呢，第一种，官方文档，或者百度，或者GOOGLE，等方式轻易的就可以找到解决方案却仍然拿出来提问的人。 第二种就是什么条件、环境都不描述，背景也不说上来就问，怎么样最好，如何性能最快，怎么做才能最稳定的人，我说话比较直，勿怪，对于这类人，你至少要让他知道一些概念，不然根本没法交流。  
 
       为了解决这些问题，我想提供一种快速让一些没有经验或者经验不足的朋友去快速了解Elasticsearch，了解ES能做什么，了解ES怎么做才能达到你的要求，带着这些问题，我在头脑里构思了 两个系列的视频，第一个是ES-教程篇， 第二个是ES-实战篇,把实际的生产环境中的一些场景，剥离业务相关的，保密性的东西，以纯技术的方式与大家分享下，看我们是如何踩坑，填坑的。

由于视频是个人行为，非商业性质，所以不可能做到定时更新，这点还请大家见谅，不过我肯定会用心去做。
 
所有的视频会以两个方式去提供，一个是百度云盘里下载完整的压缩包，里面包含了视频、PPT、以及配置文件信息。另一种是通过优库视频直接看视频，PPT和配置文件到百度云上去下载。
 
 
百度云： https://pan.baidu.com/s/1i4ZsORF
优酷：http://i.youku.com/rickywag
 
 
感谢你们的支持，如果觉得不错可以打赏我哟。 收起阅读 »