第7期 ElasticTalk 直播已经结束，我们主要讨论了 ElasticStack 6.7 的新特性 ，感兴趣的同学可去如下网址观看回放。
ElasticTalk #7 ElasticStack 6.7 功能概览
 
ElasticTalk 是一个社区的 Webinar 活动，也欢迎感兴趣的伙伴加入，我们的目标如下：
1.研讨 Elastic Stack 的新功能、原理等，使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场，形式主要以在线直播为主。
 
如果你对这个项目感兴趣，欢迎联系我！
 
招聘时间
我司在大力招聘 Elastic 技术专家，欢迎感兴趣的同学来投简历，地址如下：
http://www.elastictech.cn/jobs
 
想在 Elasticsearch 领域精进的同学，不妨来看看机会，作为 Elastic 官方战略级合作伙伴，我们的培训都是和 Elastic 官方同步的，机不可失！
而我们服务的客户遍布金融、证券、零售、制造业，充满挑战，感兴趣的你快来投递简历吧！
 
 
 

直播时间：
4月6日（周六） 14:00~15:00

直播内容：
Elastic Stack 迭代速度是令人咂舌的，这不 6.6 发布没多久，6.7 就来了，7.0 已经 RC2 了!

我们本期直播就来聊聊 6.7 的那些新功能：

• Elastic Maps
• Elastic Uptime
• CCR
• ILM
• Freeze Index
• Canvas
• Kibana 中文版

 

• ......

 

 
直播方式: 
直播链接会在开始前发送到讨论群中。
点击下方网站链接，选择对应 Webinar 注册即可
 Webinar 注册链接
 

第6期 ElasticTalk 直播已经结束，我们主要讨论了 Elasticsearch multi-fields 多字段的相关知识 ，感兴趣的同学可去如下网址观看回放。
 
ElasticTalk #6 Multi-Fields 理解与实践
 
ElasticTalk 是一个社区的 Webinar 活动，也欢迎感兴趣的伙伴加入，我们的目标如下：
1.研讨 Elastic Stack 的新功能、原理等，使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场，形式主要以在线直播为主。
 
如果你对这个项目感兴趣，欢迎联系我！
 
招聘时间
我司在大力招聘 Elastic 技术专家，欢迎感兴趣的同学来投简历，地址如下：
http://www.elastictech.cn/jobs

直播时间：
3月30日（周六） 14:00~15:00

直播内容：
你听说过 multi-fields 吗？了解过它的应用场景吗？快来注册报名吧！



直播方式: 
直播链接会在开始前发送到讨论群中。
点击下方网站链接，选择对应 Webinar 注册即可
 
Webinar 注册链接

直播时间：
3月23日（本周六） 14:00~15:00


直播内容：
Elasticsearch 冷热架构可以帮助用户以较低硬件成本实现同等规模的数据存储，解决成本支出。
本次直播我们就来好好讨论下 冷热架构那些事儿！
​



直播方式: 

直播链接会在开始前发送到讨论群中。
 
点击下方网站链接，选择对应 Webinar 注册即可
 
Webinar 注册链接 
 

Shay 的一篇文章，分享一下，关于 Elastic、开源及社区。
https://www.elastic.co/blog/on ... mpany
Elastic 关注的焦点始终是：开发强大的产品，围绕这些产品构建社区，并帮助用户实现成功。

我在 2009 年坐下来编写了 Elasticsearch 最初的几行代码，并以开源方式提供给用户。因此我放弃了原来的工作，花了两年时间开发产品并围绕这些产品打造杰出的社区。在 2012 年，我们围绕所开发的产品创建了公司：Elastic。我们投入巨大精力维持用户社区，并且采用围绕这一社区而开发的开源产品生态系统。我们向 Apache Lucene 中新添了多得数不清的功能，将其打造成无比坚固的基石，以方便所有人在其基础上进行开发。我们增加了 Kibana（由 Rashid 开发）、Logstash（由 Jordan 开发）和 PacketBeat（由 Monica 和 Tudor 开发）等等，不胜枚举。我们开发产品，围绕这些产品打造社区，并专注于为用户提供最大价值。现在，我们有数百名 Elastic 的开发人员每天都在努力工作，致力于实现这一承诺。每天都有数十万名社区用户帮助我们取得共同成功。对于我们为打造强大社区而创建的这家公司，我感到无比自豪。

我们与用户群体之间已经建立了很大程度的信任，我对此既感到骄傲，也感到自己身负重任。我们从成立之初就是一家开源公司，并且我们在所有事务中也一直坚持全心全意为社区和广大用户服务。我们同时还专注于确保任何事情都不能让我们偏离初衷。

公司成立多年以来，我们一直面临着来自外界的担忧、不确定性和质疑。如果开发的产品大获成功，这种事情肯定会发生。这种担忧、不确定性和质疑主要来自大型（超大型）公司，因为他们担心这一发展势头会对他们不利。这是很自然的事情。“千万别使用这款产品，它就是个玩具罢了。” “这款产品只有这么几个开发人员，如果他们遭遇车祸，接下来怎么办呢？” “他们根本不知道‘企业’的需求。” “他们关于 X、Y 或 Z（插入适用于您的时下热门词汇）的说法根本不对。” 我们绝不会被这些言论左右，也不会介意这些说法。这些言论的目的就是为了分散我们和我们社区的精力，让我们偏离初衷，让我们不能继续开发用户喜欢的优秀产品，让我们不能专注于打造用户热爱的卓越社区。如果我们纠结于这些言论，那就愧对了用户对我们的期望，而我们绝对不会让用户失望。

我们的产品被不断地复刻、重新分发和重新打包，次数多到我都数不清了。这代表我们的产品十分成功，使用范围越来越广泛。这些复刻、重新分发和重新打包的公司各式各样，既有各家供应商，也有大型中国企业，而这次就是 Amazon。凡事皆有“原因”，但有时这些原因会被蒙上“大公无私”或“造福公众”的虚伪面具。这些复刻、重新分发和重新打包的产品却没有一个能维持长久。这些公司开发此类产品是为了达到自己的目的，混淆视听，并分裂社区。我们致力于开发用户喜欢的优秀产品并打造用户热爱的卓越社区，正是这一承诺和专注支持我们发展到今天，广大用户对这一点也十分认同。我们已经和您建立了极大的信任，创新速度能够满足您的期望，并且彼此之间的配合也都十分融洽，这一点毫无疑问，大家都看到了。

我们坚信开源理念，也坚信这一理念所赋予的力量。同时，我们从一开始就与大家沟通过，某些功能将是商用功能，并且说明了原因。我相信，我们公司之所以能够取得共同成功，这与我们坚守诚信密不可分。我们编写开源代码时坚持这样的方式：可以向其中添加插件，并允许用户干净地加以实施。我们的这一方式从最初一直不曾改变，多年以来，我们之所以能与广大用户建立信任，正是因为我们一直坚守承诺并努力服务于用户。

我们的商用代码一直都是其他公司的“灵感来源”，有很多公司直接复制我们的代码，甚至将这些代码用于特定的分发包或者复刻版本中，最新推出的 Amazon 产品就是一个例子，很不幸，其中包括多个关键故障，会给用户造成巨大麻烦。我们一直专注于开发用户喜欢的优秀产品，并打造用户热爱的卓越社区。我们并未因为其他公司的这些行为而偏离初衷，这一专注给我们带来了十倍的回报。

我们的品牌已经很多次遭滥用、盗用和不实呈现。很多公司都故意错误地声称他们与我们公司之间有合作，其中就包括 Amazon。然而这些行为并未让我们偏离初衷，我们一直专注于开发用户喜欢的优秀产品，并打造用户热爱的卓越社区。不能专心行事是公司发展的大忌，所以我们绝不会让这些公司的举动左右我们。最重要的是您，我们的用户，而不是围绕产品周围的熙攘噪音。

如果收购其他公司的话，我们会开放源码。当开始看到用户将 Elastic 产品用于 APM 用例时，我们所有人都感到无比兴奋。我们曾收购 OpBeat（APM 领域一家专门从事 SaaS 业务的公司），这是我们公司的一项重大商业投资，然后我们将大部分内容都开源提供给用户，并让用户能够自由使用全部这些内容。决策过程就这么简单，因为我们专注于开发用户喜欢的产品，并打造用户热爱的社区，所以作为我们的用户，您理应使用这些产品。

在其他公司封闭源码的同时，我们却在开放源码。我们的开源代码一直都是一样的，而且都基于同样的许可证，同时我们还加大力度争取在公司层面越来越开放。我们针对现有商用代码使用了另外一套更加宽容的许可证，并且开放了源码。我们希望在从事的所有事情中，都能打造与我们的开源代码相同程度的协作和透明度。与用户进行过多场讨论后，我们决定通过这种方式来直接满足用户的需求，看到大家对此种做法如此认同，我感到十分高兴。自此之后，我们在开源方面的投入一直在增加，同时也致力于提供更多免费功能和体验（已明确地进行标志和分发）。

其他公司看到我们取得成功，便与我们联系要求建立特殊的合作关系以就代码进行协作，要求获得优待以便凌驾于我们的用户之上，这时我们的答案很简单：不行。这些年来，这样的事情发生了很多次，最近又发生了一次，那就是 Amazon。有些公司遵守我们的宗旨，并成为了我们和社区的优秀合作伙伴。很遗憾，其他公司则未能做到。我们承诺：我们会同等对待每一位帮助我们开发产品的开发人员。任何人都没有优先权，如果有人要求优先权，我们会断然拒绝所有此类要求。我们的答案从始至终只有一个：发送提取请求，和所有其他人一样。质量将会说明一切。

我之所以写下上面这些内容，主要有下列几项原因。首先，我们所有人有时都需要自我反省，取得成功靠的是什么，背后的原因又是什么，从而确保我们坚持正确的发展路线。这一点适用于作为我们广大用户的您，适用于我们的社区，也适用于我们公司。第二，我想告诉其他公司，虽然有很多理由会让你们偏离初衷，但还请保持专注，并真正服务于用户，这才是唯一重要的事。最后一点，我想重申我们的承诺：继续开发用户喜爱的产品并打造用户热爱的社区。这是我们的真正目标。

在 Elastic，每一天都是第 0 天（与我们所服务的开发人员一样，我们也使用从零开始的计数方法）。从我写下第一行代码，到我们和所有用户经过的 10 年历程，再到未来，我们一直坚守初心。谨此代表 Elastic 向大家表示真诚的感谢。

Elasticsearch 目前被大家广泛使用，也越来越受到大家欢迎，大家在工作中是否需要经常用到？想要系统的学习 Elasticsearch 么？那么可以参加 Elasticsearch 的官方培训。这也是 Elastic 官方第一次在国内开展的培训。本课程以普通话授课。所有资料均为英语。
 
课程：Elasticsearch 工程师培训 I
时间：
2019 年 4 月 8 日星期一，上午 9：00 - 下午 5:00 
2019 年 4 月 9 日星期二，上午 9：00 - 下午 5:00 
地点：中国北京
详情及报名，请访问：https://training.elastic.co/ENGI/Beijing/April2019
 

课程：Elasticsearch 工程师培训 II
时间：
2019 年 4 月 11 日星期四，上午 9：00 - 下午 5:00 
2019 年 4 月 12 日星期五，上午 9：00 - 下午 5:00 
地点：中国北京
详情及报名，请访问：https://training.elastic.co/EN ... l2019
 
名额有限，有兴趣的同学可以关注一下。

1月29日，Elastic Stack 迎来 6.6 版本的发布，该版本带来很多新功能，比如：

• Index Lifecycle Management
  
• Frozen Index
  
• Geoshape based on Bkd Tree
  
• SQL adds support for Date histograms
  
• ......
  
  在这些众多功能中，Index Lifecycle Management(索引生命周期管理，后文简称 ILM) 是最受社区欢迎的。今天我们从以下几方面来快速了解下该功能：
  
  
  1. 为什么索引会有生命？什么是索引生命周期？
     
  2. ILM 是如何划分索引生命周期的？
     
  3. ILM 是如何管理索引生命周期的？
     
  4. 实战
     
     

     1. Index Lifecycle 索引生命周期
     

     
     先来看第一个问题：
     
     

     为什么索引有生命？
     
     索引(Index)是 Elasticsearch 中数据组织的一个逻辑概念，是具有相同或相似字段的文档组合。它由众多分片(Shard)组成，比如 book、people都可以用作索引名称，可以简单类比为关系型数据库的表(table)。
     
     所谓生命，即生与死；索引的生与死便是创建与删除了。
     
     在我们日常使用 Elasticsearch 的时候，索引的创建与删除似乎是很简单的事情，用的时候便创建，不用了删除即可，有什么好管理的呢？
     
     这就要从 Elasticsearch 的应用场景来看了。
     
     在业务搜索场景，用户会将业务数据存储在 Elasticsearch 中，比如商品数据、订单数据、用户数据等，实现快速的全文检索功能。像这类数据基本都是累加的，不会删除。一般删除的话，要么是业务升级，要么是业务歇菜了。此种场景下，基本只有生，没有死，也就不存在管理一说。
     
     而在日志业务场景中，用户会将各种日志，如系统、防火墙、中间件、数据库、web 服务器、应用日志等全部实时地存入 Elasticsearch 中，进行即席日志查询与分析。这种类型的数据都会有时间维度，也就是时序性的数据。由于日志的数据量过大，用户一般不会存储全量的数据，一般会在 Elasticsearch 中存储热数据，比如最近7天、30天的数据等，而在7天或者30天之前的数据都会被删除。为了便于操作，用户一般会按照日期来建立索引，比如 nginx 的日志索引名可能为 nginx_log-2018.11.12、nginx_log-2018.11.13等，当要查询或删除某一天的日志时，只需要针对对应日期的索引做操作就可以了。那么在该场景下，每天都会上演大量索引的生与死。
     
     一个索引由生到死的过程，即为一个生命周期。举例如下：
     
     

• 生：在 2019年2月5日 创建 nginx_log-2019.02.05的索引，开始处理日志数据的读写请求
  
• 生：在 2019年2月6日 nginx_log-2019.02.05 索引便不再处理写请求，只处理读请求
  
• 死：在 2019年3月5日 删除 nginx_log-2018.02.05的索引
  
  其他的索引，如 nginx_log-2019.02.06 等也会经过相同的一个生命周期。
  
  

  2. ILM 是如何划分索引生命周期的？
  

  
  我们现在已经了解何为生命周期了，而最简单的生命周期只需要生与死两个阶段即可。但在实际使用中生命周期是有多个阶段的，我们来看下 ILM 是如何划分生命周期的。
  
  ILM 一共将索引生命周期分为四个阶段(Phase)：
  
  

  1. Hot 阶段
     
  2. Warm 阶段
     
  3. Cold 阶段
     
  4. Delete 阶段
     
     如果我们拿一个人的生命周期来做类比的话，大概如下图所示：
     
     
     
     

     Hot 阶段
     

     
     Hot 阶段可类比为人类婴儿到青年的阶段，在这个阶段，它会不断地进行知识的输入与输出(数据读写)，不断地长高长大(数据量增加)成有用的青年。
     
     由于该阶段需要进行大量的数据读写，因此需要高配置的节点，一般建议将节点内存与磁盘比控制在 32 左右，比如 64GB 内存搭配 2TB 的 SSD 硬盘。
     
     

     Warm 阶段
     

     
     Warm 阶段可类比为人类青年到中年的阶段，在这个阶段，它基本不会再进行知识的输入(数据写入)，主要进行知识输出(数据读取)，为社会贡献价值。
     
     由于该阶段主要负责数据的读取，中等配置的节点即可满足需求，可以将节点内存与磁盘比提高到 64~96 之间，比如 64GB 内存搭配 4~6TB 的 HDD 磁盘。
     
     

     Cold 阶段
     

     
     Cold 阶段可类别比为人类中年到老年的阶段，在这个阶段，它退休了，在社会有需要的时候才出来输出下知识(数据读取)，大部分情况都是静静地待着。
     
     由于该阶段只负责少量的数据读取工作，低等配置的节点即可满足要求，可以将节点内存与磁盘比进一步提高到 96 以上，比如128，即 64GB 内存搭配 8 TB 的 HDD 磁盘。
     
     

     Delete 阶段
     

     
     Delete 阶段可类比为人类寿终正寝的阶段，在发光发热之后，静静地逝去，Rest in Peace~
     
     ILM 对于索引的生命周期进行了非常详细的划分，但它并不强制要求必须有这个4个阶段，用户可以根据自己的需求组合成自己的生命周期。
     
     

     3. ILM 是如何管理索引生命周期的？
     

     
     所谓生命周期的管理就是控制 4 个生命阶段转换，何时由 Hot 转为 Warm，何时由 Warm 转为 Cold，何时 Delete 等。
     
     阶段的转换必然是需要时机的，而对于时序数据来说，时间必然是最好的维度，而 ILM 也是以时间为转换的衡量单位。比如下面这张转换的示意图，即默认是 Hot 阶段，在索引创建 3 天后转为 Warm 阶段，7 天后转为 Cold 阶段，30 天后删除。这个设置的相关字段为 min_age，后文会详细讲解。
     
     
     
     ILM 将不同的生命周期管理策略称为 Policy，而所谓的 Policy 是由不同阶段(Phase)的不同动作(Action)组成的。
     
     Action是一系列操作索引的动作，比如 Rollover、Shrink、Force Merge等，不同阶段可用的 Action 不同，详情如下：
     
     

• Hot Phase
  
  • Rollover 滚动索引操作，可用在索引大小或者文档数达到某设定值时，创建新的索引用于数据读写，从而控制单个索引的大小。这里要注意的一点是，如果启用了 Rollover，那么所有阶段的时间不再以索引创建时间为准，而是以该索引 Rollover 的时间为准。
    
• Warm Phase
  
  • Allocate 设定副本数、修改分片分配规则(如将分片迁移到中等配置的节点上)等
    
  • Read-Onlly 设定当前索引为只读状态
    
  • Force Merge 合并 segment 操作
    
  • Shrink 缩小 shard 分片数
    
• Cold Phase
  
  • Allocate 同上
    
• Delete Phase
  
  • Delete 删除
    
    从上面看下来整体操作还是很简单的，Kibana 也提供了一套 UI 界面来设置这些策略，如下所示：
    
    
    
    从上图看下来 ILM 的设置是不是一目了然呢？
    
    当然，ILM 是有自己的 api 的，比如上面图片对应的 api 请求如下：
    
    json<br /> PUT /_ilm/policy/test_ilm2<br /> {<br /> "policy": {<br /> "phases": {<br /> "hot": {<br /> "actions": {<br /> "rollover": {<br /> "max_age": "30d",<br /> "max_size": "50gb"<br /> }<br /> }<br /> },<br /> "warm": {<br /> "min_age": "3d",<br /> "actions": {<br /> "allocate": {<br /> "require": {<br /> "box_type": "warm"<br /> },<br /> "number_of_replicas": 0<br /> },<br /> "forcemerge": {<br /> "max_num_segments": 1<br /> },<br /> "shrink": {<br /> "number_of_shards": 1<br /> }<br /> }<br /> },<br /> "cold": {<br /> "min_age": "7d",<br /> "actions": {<br /> "allocate": {<br /> "require": {<br /> "box_type": "cold"<br /> }<br /> }<br /> }<br /> },<br /> "delete": {<br /> "min_age": "30d",<br /> "actions": {<br /> "delete": {}<br /> }<br /> }<br /> }<br /> }<br /> }<br />
    
    这里不展开讲了，感兴趣的同学可以自行查看官方手册。
    
    现在管理策略(Policy)已经有了，那么如何应用到索引(Index)上面呢？
    
    方法为设定如下的索引配置：
    
    
• index.lifecycle.name 设定 Policy 名称，比如上面的 test_ilm2
  
• index.lifecycle.rollover_alias 如果使用了 Rollover，那么还需要指定该别名
  
  修改索引配置可以直接修改(`PUT index_name/_settings)或者通过索引模板(Index Template)来实现。
  
  我们这里不展开讲了，大家参考下面的实战就明白了。
  
  

  4. 实战
  

  
  下面我们来实际演练一把！
  
  

  目标
  

  
  现在需要收集 nginx 日志，只需保留最近30天的日志，但要保证最近7天的日志有良好的查询性能，搜索响应时间在 100ms 以内。
  
  为了让大家可以快速看到效果，下面实际操作的时候会将 30天、7天 替换为 40秒、20秒。
  
  

  ES 集群架构
  

  
  这里我们简单介绍下这次实战所用 ES 集群的构成。该 ES 集群一共有 3个节点组成，每个节点都有名为 box_type 的属性，如下所示：
  
  <br /> GET _cat/nodeattrs?s=attr<br /> es01_hot 172.24.0.5 172.24.0.5 box_type hot<br /> es02_warm 172.24.0.4 172.24.0.4 box_type warm<br /> es03_cold 172.24.0.3 172.24.0.3 box_type cold<br />
  
  由上可见我们有 1 个 hot 节点、1 个 warm 节点、1 个 cold 节点，分别用于对应 ILM 的阶段，即 Hot 阶段的索引都位于 hot 上，Warm 阶段的索引都位于 warm 上，Cold 阶段的索引都位于 cold 上。
  
  

  创建 ILM Policy
  

  
  根据要求，我们的 Policy 设定如下：
  
  

• 索引名以 nginx_logs 为前缀，且以每10个文档做一次 Rollover
  
• Rollover 后 5 秒转为 Warm 阶段
  
• Rollover 后 20 秒转为 Cold 阶段
  
• Rollover 后 40 秒删除
  
  API 请求如下：
  
  json<br /> PUT /_ilm/policy/nginx_ilm_policy<br /> {<br /> "policy": {<br /> "phases": {<br /> "hot": {<br /> "actions": {<br /> "rollover": {<br /> "max_docs": "10"<br /> }<br /> }<br /> },<br /> "warm": {<br /> "min_age": "5s",<br /> "actions": {<br /> "allocate": {<br /> "include": {<br /> "box_type": "warm"<br /> }<br /> }<br /> }<br /> },<br /> "cold": {<br /> "min_age": "20s",<br /> "actions": {<br /> "allocate": {<br /> "include": {<br /> "box_type": "cold"<br /> }<br /> }<br /> }<br /> },<br /> "delete": {<br /> "min_age": "40s",<br /> "actions": {<br /> "delete": {}<br /> }<br /> }<br /> }<br /> }<br /> }<br />
  
  

  创建 Index Template
  

  
  我们基于索引模板来创建所需的索引，如下所示：
  
  json<br /> PUT /_template/nginx_ilm_template<br /> {<br /> "index_patterns": ["nginx_logs-*"], <br /> "settings": {<br /> "number_of_shards": 1,<br /> "number_of_replicas": 0,<br /> "index.lifecycle.name": "nginx_ilm_policy", <br /> "index.lifecycle.rollover_alias": "nginx_logs",<br /> "index.routing.allocation.include.box_type": "hot"<br /> }<br /> }<br />
  
  上述配置解释如下：
  
  

• index.lifecycle.name 指明该索引应用的 ILM Policy
  
• index.lifecycle.rollover_alias 指明在 Rollover 的时候使用的 alias
  
• index.routing.allocation.include.box_type 指明新建的索引都分配在 hot 节点上
  
  

  创建初始索引 Index
  

  
  ILM 的第一个索引需要我们手动来创建，另外启动 Rollover 必须以数值类型结尾，比如 nginx_logs-000001。索引创建的 api 如下：
  
  json<br /> PUT nginx_logs-000001<br /> {<br /> "aliases": {<br /> "nginx_logs": {<br /> "is_write_index":true<br /> }<br /> }<br /> }<br />
  
  此时索引分布如下所示：
  
  
  
  

  修改 ILM Polling Interval
  

  
  ILM Service 会在后台轮询执行 Policy，默认间隔时间为 10 分钟，为了更快地看到效果，我们将其修改为 1 秒。
  
  json<br /> PUT _cluster/settings<br /> {<br /> "persistent": {<br /> "indices.lifecycle.poll_interval":"1s"<br /> }<br /> }<br />
  
  

  开始吧
  

  
  一切准备就绪，我们开始吧！
  
  首先执行下面的新建文档操作 10 次。
  
  json<br /> POST nginx_logs/_doc<br /> {<br /> "name":"abbc"<br /> }<br />
  
  之后 Rollover 执行，新的索引创建，如下所示:
  
  
  
  5 秒后，nginx_logs-000001 转到 Warm 阶段
  
  
  
  15 秒后(20 秒是指距离 Rollover 的时间，因为上面已经过去5秒了，所以这里只需要15秒)，nginx_logs-00001转到 Cold 阶段
  
  
  
  25 秒后，nginx_logs-00001删除
  
  
  
  
  
  至此，一个完整的 ILM Policy 执行的流程就结束了，而后续 nginx_logs-000002 也会按照这个设定进行流转。
  
  

  总结
  

  
  ILM 是 Elastic 团队将多年 Elasticsearch 在日志场景领域的最佳实践进行的一次总结归纳和落地实施，极大地降低了用好 Elasticsearch 的门槛。掌握了 ILM 的核心概念，也就意味着掌握了 Elasticsearch 的最佳实践。希望本文能对大家入门 ILM 有所帮助。
  
  

  在线研讨会
  

  
  一篇文章所能承载的信息量和演示效果终究是有限的，2月份我们会针对 ILM 做一次线上研讨会，感兴趣的同学可以点击下面的链接注册报名。
  
  
  
  [https://jinshuju.net/f/TjBbvx](https://jinshuju.net/f/TjBbvx)
  
  
  
  为了提高研讨会的质量，我们本次引入了审核机制，报名的同学请耐心等待，待我们审核通过后，您会收到我们的邮件邀请。
  
  
  
  

  参考资料：
  

  
  

  1. https://www.elastic.co/guide/e ... .html
     
  2. https://www.elastic.co/blog/ho ... h-5-x
     
     

中文字幕视频介绍，不用翻墙：https://jwp.io/s/mm39Gki9


 
这里也有一个围绕这些特性的电台访谈节目：
https://www.ximalaya.com/keji/14965410/139462151
 
下载地址：
https://www.elastic.co/downloads

今天 Elasticsearch 的小的bug 修复版本 v6.4.1 已经发布，主要修复了 rollover 的一个 bug，如果你在用 Rollover 功能，请尽快升级！
Elasticsearch can once again start if any shards on the node have been rolled over. #33394
 
下载地址：
https://www.elastic.co/downloads/elasticsearch
 
 
Elastic Stack 家族的其他部分也发布了，更新内容还不少哦。
Kibana v6.4.1：https://www.elastic.co/guide/e ... .html
Logstash v6.4.1: https://www.elastic.co/guide/e ... .html
Beats v6.4.1: https://www.elastic.co/guide/e ... .html
 
 

Elastic 在今年6月29日推出了面向 Elasticsearch 工程师的认证考试，官方描述如下：

The Elastic Certification Program was created to recognize individuals who have demonstrated a high-level of knowledge, competence and expertise with Elasticsearch. Elastic Certified Professionals demonstrate these skills by completing challenging and relevant real-world tasks on a live Elastic Stack cluster in our hands-on, performance-based certification exams.

我们此次直播便邀请中国第1位通过该认证的工程师 rockybean 来分享下认证考试的一些信息，通过这次直播，你可以了解如下信息：

1. 如何注册考试？费用？
2. 如何准备考试？
3. 考试的形式是怎样的？有哪些类型的考题？

本次直播由于设备问题，声音有些卡顿，大家见谅！
视频链接如下：
http://v.qq.com/x/page/f073779epxd.html
 

几个小时前, Elastic 商业插件 X-Pack 的源代码已正式 Merge 进 Master，作为一家开源软件公司，能够将商业部分的代码也公开，实在是需要很大的勇气（我深感自豪），这一切都是为了更好的打造一个更加好用的产品：Elastic Stack，只有开放才能走的更远！

想了解更多关于 X-Pack 代码公开背后的介绍，可以看 Elastic 创始人 Shay 的这篇博客：[https://elasticsearch.cn/article/513](https://elasticsearch.cn/article/513)

相关代码已在 github 上面可以找到：

[Elasticsearch](https://github.com/elastic/ela ... x-pack)

[Kibana](https://github.com/elastic/kib ... x-pack)

[Logstash](https://github.com/elastic/log ... x-pack)

[Beats](https://github.com/elastic/beats/tree/master/x-pack)

有关问题可以在此回复，我会一一解答。

by Elastic CEO Shay Banon [原文](https://www.elastic.co/blog/doubling-down-on-open)

我很高兴的宣布，我们将公开我们 X-Pack 特性的所有代码 - Security、Monitoring、Alerting、Graph、Reporting、专门的 APM UI、Canvas、Elasticsearch SQL、Search Profiler、Grok Debugger、Elastic Maps Service zoom levels 以及 Machine Learning - 为了促进我们与客户及社区的更大的协作，正如我们今天为我们的开源代码所做的一样。

我为我们公司围绕我们的开源产品而自豪，一直以来我们都没有破坏创新或放弃对开放的承诺。当我们展望未来的时候，我们看到了一个机会，让我们更加坚信开放，甚至更加彻底，同时引入一个新的、更加高效的模式来构建一个成功的、可持续的围绕开源的商业模式。

这篇博客概述了我们做出这些改变的想法和细节，不过，让我澄清一件事 - 我们是一家开源软件公司。我们将继续保持为一家开源软件公司。我们比以往任何时候都要更加开放，我个人，我的团队，整体而言，都致力于此。

为什么开源?

当我第一次开始写 Elasticsearch 的时候，我知道它必须是开源的。开源作为一种开发模式和分发方式，提供了接触更多人的机会。所有这些人都能做出贡献。当然，通过代码可以做出贡献，但也可以通过使用免费的软件，持续不断的推进可能的边界。

与社区的合作可以确保，当你的项目成功时，会有一群热情的、专门的开发者指导你的特性开发，并将产品推向新的有趣的方向。例如，将聚合功能引入 Elasticsearch 让其可被当做一个可扩展的用于数据分析的产品。而像 Kibana 和 Logstash 这样的项目，以及后来的 Beats 的加入，无不令人鼓舞。随着我们用户的需求变得更加深入和专业，我们总能找到新的方法来支持他们，有些是通过新的功能、有些是产品，比如机器学习、APM 和站内搜索。

我们对开源的承诺深入了。这是我们花费大部分工程力量投入的地方，我们的社区贡献者和用户对我们创新进程也同样至关重要。但是，像我们这样快速推进产品的发展，需要大量的投资，这也是我们围绕这些技术成立一家公司的原因。

为什么商业软件?

那么，如果我们对开源软件已有如此深的见解，那为什么还是编写了商业软件呢？

我们是一家企业。作为企业的一部分，我们相信那些能够付款给我们的企业，应该付款给我们。而那些不能的，他们也不必付款给我们。作为回报，我们有义务确保我们继续添加功能和价值给我们所有的用户，并确保与我们的商业关系对客户有益。这是一家健康的公司所需要的平衡。

销售支持订阅服务是一个常见的开源软件的商业模式。可悲的是，只有支持的商业模式会朝向关于什么对用户最好以及什么对公司最好这样的冲突之中。在这种情况下，公司将没有动力让他们的产品更加简单好用，更加稳固和可扩展，因为那意味着这将吞噬其技术支持的利益。我们从来没有，也永远不会忍受为了确保公司继续经营而不让我们的软件变的更好。我们想要继续改进，我们支持服务的目标是让你的项目成功，然后你能成为你自有 Elastic Stack 部署的专家。

另外一种办法 -- 如果你们听过我的演讲，你们可能听我讨论过这个问题 -- 即构建一个‘企业版’的软件。这种，从本质上来讲，导致了社区的分裂，并在客户和用户之间产生了分歧。它的结果就是创建一种版本 -- 要么企业版，要么社区版 -- 被认为是权威的，往往滞后 master 很多。一个缺少特性的版本。一个在不同周期测试和发布的版本。一个有效的关闭了源代码的版本，因为您无法知道为了支持商业特性而更改了哪些内容。在 Elastic，所有我们的客户同时也是我们开源软件用户，使用相同版本的软件产品。我们不会创建一个社区版与企业版的版本。

那还有什么？识别高价值特性并将其作为核心软件的商业扩展。这种商业模式，我们有时候叫它“open core”，这是我们创造 X-Pack 的最终产物。为了构建和集成由我们维护知识产权（IP）的特性和功能，并提供订阅服务或免费的基础授权。保持我们对知识产权的控制，使我们能够有能力投资我们大部分的工程资源和时间，可以继续改进我们的核心，我们的开源产品。

这种方法使我们能够在世界各地建立一个分布式的公司，让我们感到惊讶的是，Elastic Stack 是如何被用来解决各种实际的、具体的问题的。添加适用于我们用户的特性和功能，并开发一些使我们能够持续到未来的功能。

但是这种方法也存在挑战…

更加开放

你是否知道 X-Pack 提供了一层免费的功能？这些能力诸如 Monitoring、Search Profiler、Grok Debugger 以及额外的 Elastic Maps 缩放级别。你是否知道我们还将在这一层继续添加更多功能，如 Canvas 和 Elasticsearch SQL？

当我们往X-Pack 里添加免费功能的时候，我们这么做是因为我们知道这些功能可以帮助用户更好的使用 Elastic Stack。不幸的是，太多功能你都不知道 -- 也许知道 -- 或得益于这些功能。所以这意味着有很大一部分用户在使用我们软件的时候往往不是最佳实践。

我们也知道，获得这个免费软件的过程是一个糟糕的用户体验，涉及到一个完整的集群重启。并且如果你想查看代码，抱歉，不可以。尤其是这些免费功能和很大一部分用户相关，你会问我们一些很好但是很难的问题，比如：“我如何就这些免费功能与你们交互？”，“我如何开启一个 issue 或是贡献代码？”

而我们没有很好的答案。

通过公开 X-Pack 的代码，我们解决了这些我们部分产品开源以及部分产品不是的问题。很快，所有的免费的和商业的特性你都可以开启一个 issue、查看特性讨论、检查源代码、与我们协助和提交一个 pull request。

具体细节

这意味着什么，技术上来说？

自 6.3 版本起，所有 $PRODUCT（项目）仓库(Elasticsearch, Logstash, Kibana, Beats) ：

• 所有现存的 Apache 2.0 协议的代码都将保持相同的协议，什么都不用动。
  
• 我们会创建一个新的 X-Pack 目录，将 x-pack-$PRODUCT 的代码放入到该目录，基于 Elastic EULA 协议，允许相应的衍生和贡献。
  
• 我们将修改最顶层的协议为一个简单的 Elastic License，包含这个仓库里面那些文件是Apache 2.0，那些是 Elastic EULA 的详细细节。
  
  同时，X-Pack 功能将打包到默认的发行版里面。所有免费的功能都包含在里面且默认开启且永远不会出现‘过期’，而商业特性则可以通过试用证书可选的启用。因为免费的证书永远不会过期，所以你再也不用通过注册来就直接获取它了。除此以外，一个只包含 Apache 2.0 协议代码的包也会同样会创建并提供下载。
  
  更多信息以及常见问题，可以在 [Opening X-Pack](http://elastic.co/products/x-pack/open) 页找到。
  
  

  总结
  

  
  我们相信开源。作为一种分布模式。作为一种建立企业的方法。作为我们公司的未来。
  我们承诺并保持我们将保持开放，并对我们将在 6.3 比以往任何时候都更加开放而感到兴奋。
  
  
  感谢你们对我们的信任。

嘉奖 Elastic 社群促进全球福祉的杰出项目

旧金山，2018 年 2 月 27 日 - （GLOBE NEWSWIRE）--（Elastic{ON} 2018） - Elasticsearch 和 Elastic Stack 幕后公司 Elastic 今日在 Elastic {ON} 2018 开幕礼主题演讲中宣布第二届 Elastic Cause Awards 的获奖者。为表彰Elastic 社群的热情、创新和奉献精神，2018 年 Elastic Cause Awards 嘉奖了四个推动 Elastic 软件发展并造福全球的项目。今年的获奖者包括：Dimagi、Libraries Without Borders (Bibliothèques Sans Frontières) 、Refugee Datathon Munich 和 Thorn: Digital Defenders of Children。

Elastic Cause Awards 是 Elastic 不断扩展的慈善使命之一，该公司将继续致力于慈善事业，以进一步惠及使用Elastic Stack 的非牟利组织。第二届 Cause Awards 覆盖数十家组织提名，致力改善人类状况，改善环境或协助当地、地区或全球有需要的人口。评审包括 Elastic 创始人兼首席执行官 Shay Banon、人力资源部副总裁Leah Sutton，以及由 Elastic 开发人员、产品和客户专家组成的小组，他们根据其影响、利他主义和影响力评估入围者。每个获选的项目团队均可获得最多两位项目成员的免费会议门票和酒店住宿，并将在 Elastic {ON} 2018 的各项活动中亮相。
Banon 表示﹕“在我们开始使用 Elastic 时，我知道我们的软件产品可用来帮助开发人员解决组织内的重要实用范例，但我从来没有预料到它会对解决全球人道主义和环境问题带来影响。我的灵感来自我们通过今年的 Elastic Cause Awards 了解到改变生计的举措，并为我们实现这一目标所作出的微不足道的努力而感到谦卑。”

• Dimagi
  Dimagi 正在印度帮助打击肺结核（tuberculosis / TB）流行病，该流行病占全球肺结核病例的 23%，并通过集成的移动和网络应用程序帮助医护人员追踪结核病患者。在 Dimagi 的软件平台 CommCare 基础上，该应用程序利用 Elastic Stack 从初步诊断以至整个护理过程中追踪获治疗者，并在整个过程中提供可操作的数据。 该应用程序目前能够实时汇总数据，以追踪选定地区的 150,000 名患者。
  Dimagi 高级工程师 Farid Rener 表示﹕“印度每三分钟便有两人死于肺结核。这是一种需要实时关注和需要创新解决方案的流行病。我们相信移动解决方案可改变服务交付计划的效率、质量和影响力。通过将我们的移动数据收集平台与 Elastic Stack 的强大功能互相结合，我们正在提高医护人员追踪患者的效率，并让政府决策者更准确、及时地掌握当前计划的效果。”
  
  
• Libraries Without Borders (Bibliothèques Sans Frontières)
  Libraries Without Borders 促进自由开放的信息和教育，为全球弱势社群提供学习和发展的工具和技能。该组织正在推出数字图书馆（KoomBook）以及便携式“弹出式”数字媒体中心（Ideas Box），为需要帮助的小区提供教育和文化资源，包括全球难民和流离失所的人群，以及发达国家中服务不足的小区。通过 Elastic Stack 提供的日志分析和仪表板可实时了解数字资源的使用情况以及用户的浏览习惯和兴趣，从而令组织能更有效地评估影响和相关性，并改善用户体验。
  Bibliothèques Sans Frontières 数字项目经理 Steven Walliman 表示﹕“Elastic Stack 能够处理各种原始日志，同时也能产生具有吸引力的视觉效果，这种功能完全符合我们的需求。通过让 IT 团队更好地了解性能和稳定性，以及能够衡量图书馆员的选择的相关性，Elastic Stack 增强了我们项目的影响力。我们期待着深化两个组织之间的联系，因为我们具有实现增强弱势社群能力和改善全球数以百万计人口生计的愿景。”
  
  
• Refugee Datathon Munich
  Refugee Datathon Munich 于 2015 年秋季成立，在慕尼黑为难民提供大规模支持，并为欧洲难民活动家提供最新和可靠的数据。该组织的软件从官方网站提取寻求庇护者的统计数据，然后依靠 Elastic Stack 在发布信息之前分析数据。该软件帮助活动家实时掌握当前庇护趋势（如各原籍国的批准率），同时通过驳回错误陈述和难民偏见报告为公众提供服务。
  Refugee Datathon Munich 数据架构师 Suny Kim 表示﹕“当我们看到活动家难以使用 Excel 以解释难民情况时，我们意识到有必要给予他们更多的探索能力，为其提供更多最新的数据和减少工作量。Elastic Stack 帮助我们从欧盟统计局的统计数据中获取大量数据，并以交互方式来进行分析。对我们来说，这就是民主所在：获得信息，参与其中。全球难民形势是我们这个时代的重大挑战之一，我们的项目是通过体面和充分的方式应对这一挑战的民主进程的一部分。”
  
  
• Thorn: Digital Defenders of Children
  Thorn 由 Ashton Kutcher 和 Demi Moore 共同创立，通过技术开发来保护儿童免遭性虐待。对于寻找和救援更多孩子而言，必须做到分秒必争。Thorn 在其产品中使用 Elastic Stack 来简化功能，帮助执法机构搜索数以百万条记录，并快速找到识别儿童的小片信息。2016 年和 2017 年，加快识别性交易受害儿童的 Spotlight 帮助确定了 5,791 名儿童性贩运受害者（每天8名）。Thorn 的另一个产品 Solis 已被 17 个国家的执法部门使用，并已救出 72 名儿童性虐待受害者，这些儿童的照片在暗网上散布。
  Thorn 首席执行官 Julie Cordua 表示﹕“通过与 Elastic 这样的领先技术公司合作，我们成功建立了能更快找到儿童性虐待受害者的尖端工具，使网络环境更安全，并阻止犯罪行为。在通过技术打击儿童性虐待犯罪的过程中，我们意识到技术的强大之处，我们选择善用有关技术，以成功打击儿童性贩卖和其他网上贩卖活动。”
  
  Elastic Cause Award 最终入围名单包括﹕
  
  
• Action Network：帮助进步组织进行有针对性的宣传和外展
  
• CBC Radio：能发掘各类型的新兴音乐艺术家
  
• Factr：通过共建情报流促进解决全球问题
  
• Mark43：通过更好的软件减少暴力犯罪
  
• Internet of Things for Disaster Risk Reduction (IoT-DRR)：通过监测和分析智能雨水箱和河流水位来减少灾害风险
  
• University of Bristol：促进应用门德尔随机化
  
• US NAVY：通过网络安全保护美国海军的水兵和士兵
  
• 弗吉尼亚理工学院和州立大学（Virginia Polytechnic Institute and State University / Virginia Tech ）：为环境和农业利益相关者监测流域
  
• weblyzard Technology：为联合国环境规划署（UNEP）创建环境网页情报门户，以确定意见领袖并根据主题和地理位置构建公众辩论途径
  
• Zebra Medical Vision：策划临床和算法数据集
  
  
  

  关于Elastic
  

  Elastic 致力于构建大规模实时数据处理软件，场景主要涵盖搜索、日志、安全与数据分析等领域。公司成立于 2012 年，旗下拥有产品包括开源的 Elastic Stack（Elasticsearch、Kibana、Beats 和 Logstash）、 X-Pack （商业特性）和 Elastic Cloud （一种托管服务）。迄今为止，这些产品的累积下载次数已超过 2.25 亿。Elastic 由 Benchmark Capital、Index Ventures 及 NEA 投资，投资额超过 1 亿美金。Elastic 拥有超过 800 位员工，分布于世界上 30 多个国家和地区。欲了解详情请访问：elastic.co。
  
  

  媒体联系人：
  

  
  Michael Lindenberger
  
  Reidy Communications for Elastic
  
  Michael@reidycommunications.com
  
  (415) 531-1449
  
  亚太地区
  Jeff Yoshimura
  
  Communications @ Elastic
  
  pr@elastic.co