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 search 服务供应商需要招聘培训师/项目经理

薪酬： 月工资20k +
公司基本福利：五险一金、绩效奖金、年终奖金、节日福利、专业培训
工作地点：北京/上海/深圳                     愿意出差，因工作情况会全国飞

任职要求：

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

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

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

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

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

昨日 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。
有高并发，分布式，大数据挖掘的业务场景。
我们将为你提供跟身边大牛接触学习的机会。
我们将为你提供一个开放的技术环境，一个自由高效的团队，和一个改变现有技术的机会。
分享、自由、协作是我们的处事法则。

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