ElasticHD: ElasticSearch Dashboard Application


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
     
    继续阅读 »


    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 +

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

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

      任职要求:

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

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

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

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

      5、具有良好的沟通能力和责任心。
      继续阅读 »
      Elastic search 服务供应商需要招聘培训师/项目经理

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

      任职要求:

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

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

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

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

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

      Elasticsearch 5.4.1 和 5.3.3 发布

      昨日 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反馈任何遇到的问题。
      继续阅读 »
      昨日 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权威指南》中文版背后的故事

      去年我们社区一起翻译了一本书《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的译者合影!

      IMG_5300.jpg

       
      继续阅读 »
      去年我们社区一起翻译了一本书《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的译者合影!

      IMG_5300.jpg

       
      收起阅读 »

      写了个深入详解Elasticsearch专栏,欢迎大家品鉴!

       
      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、深入详解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 收起阅读 »

      java招聘

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

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

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

      福利:
      弹性工作时间,巨大的发展空间。
      年假,双休,法定节假日。
      六险一金,补充商业保险,丰厚的餐补,全面保障。
      绝对竞争力的薪资及年终奖金,股票激励机制。
      伴随公司发展的升职机会,及每年两次的调薪机会。
      继续阅读 »
      职位描述:
      岗位描述:
      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 Debugger 国内镜像

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

      Snip20170526_6.png

       
      PS: 
      1. Kibana后续将提供Grok Debug的功能;
      2.如果你的日志每一行都遵循固定格式,你可以考虑使用 dissect filter,性能更强更简单。
      继续阅读 »
      Grok 是一个常用的对日志进行结构化的一个工具,
      可以通过在线工具进行调试:
      http://grokdebug.herokuapp.com
      http://grokconstructor.appspot.com
       
      不过有时候比较慢,甚至不能访问,所以现在为大家搭好了一个国内的镜像,方便使用:
      http://grok.elasticsearch.cn/
       
      目前还是英文,源码fork至:https://github.com/elasticsear ... uctor
      欢迎提交PR来进行翻译。

      Snip20170526_6.png

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

      GZIP造成JAVA Native Memory泄漏案例

      [携程旅行网  吴晓刚]

      近期公司某个线上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,有可能就是中招啦。 
      继续阅读 »
      [携程旅行网  吴晓刚]

      近期公司某个线上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,有可能就是中招啦。  收起阅读 »

      招聘 Elastic search 培训师/项目经理 20k +

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

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

      任职要求:

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

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

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

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

      5、具有良好的沟通能力和责任心。
       
      继续阅读 »
      Elastic search 服务供应商需要招聘培训师/项目经理

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

      任职要求:

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

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

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

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

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

      找寻TF_IDF和BM25的评分计算优化排序

      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的详情稍后补上-------------------------
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
      继续阅读 »
      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的详情稍后补上-------------------------
       
       
       
       
       
       
       
       
       
       
       
       
       
       
       
        收起阅读 »