资讯动态

【直播回放】ElasticTalk #8 ECE - 即刻实现 Elasticsearch 私有云

rockybean 发表了文章 • 0 个评论 • 3204 次浏览 • 2019-04-13 19:53 • 来自相关话题

【直播报名】ElasticTalk #8 ECE - 即刻实现 Elasticsearch 私有云

rockybean 发表了文章 • 0 个评论 • 1891 次浏览 • 2019-04-13 08:59 • 来自相关话题

Elastic Stack 7.0.0 正式版已经发布

medcl 发表了文章 • 3 个评论 • 3655 次浏览 • 2019-04-11 09:18 • 来自相关话题

【直播回放】ElasticTalk #7 ElasticStack 6.7 功能概览

rockybean 发表了文章 • 0 个评论 • 2015 次浏览 • 2019-04-06 19:36 • 来自相关话题

【直播】ElasticTalk #7 ElasticStack 6.7 功能概览

rockybean 发表了文章 • 0 个评论 • 2009 次浏览 • 2019-04-05 20:56 • 来自相关话题

【直播回放】ElasticTalk #6 Multi-Fields 理解与实践

rockybean 发表了文章 • 2 个评论 • 2417 次浏览 • 2019-03-30 17:28 • 来自相关话题

【直播】ElasticTalk #6 Multi-Fields 多字段理解与实践

rockybean 发表了文章 • 0 个评论 • 2279 次浏览 • 2019-03-29 13:46 • 来自相关话题

【直播】Elasticsearch Hot-Warm 冷热架构那些事儿

rockybean 发表了文章 • 3 个评论 • 3501 次浏览 • 2019-03-22 09:34 • 来自相关话题

Shay Banon: 关于“Open” Distro、开源和公司建设的几点思考

medcl 发表了文章 • 1 个评论 • 4430 次浏览 • 2019-03-13 10:19 • 来自相关话题

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 向大家表示真诚的感谢。

Elastic 官方培训来中国啦

medcl 发表了文章 • 6 个评论 • 8272 次浏览 • 2019-02-26 08:08 • 来自相关话题

【最新】Elasticsearch 6.6 Index Lifecycle Management 尝鲜

rockybean 发表了文章 • 8 个评论 • 22601 次浏览 • 2019-02-06 11:32 • 来自相关话题

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 阶段
  
  如果我们拿一个人的生命周期来做类比的话，大概如下图所示：
  
  ![Index Lifecycle](https://ws1.sinaimg.cn/large/6 ... 7y.jpg)
  
  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，后文会详细讲解。
  
  ![](https://ws1.sinaimg.cn/large/6 ... ux.jpg)
  
  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 界面来设置这些策略，如下所示：
 
 ![kibana ilm](https://ws1.sinaimg.cn/large/6 ... ug.jpg)
 
 从上图看下来 ILM 的设置是不是一目了然呢？
 
 当然，ILM 是有自己的 api 的，比如上面图片对应的 api 请求如下：
 
 json PUT /_ilm/policy/test_ilm2 { "policy": { "phases": { "hot": { "actions": { "rollover": { "max_age": "30d", "max_size": "50gb" } } }, "warm": { "min_age": "3d", "actions": { "allocate": { "require": { "box_type": "warm" }, "number_of_replicas": 0 }, "forcemerge": { "max_num_segments": 1 }, "shrink": { "number_of_shards": 1 } } }, "cold": { "min_age": "7d", "actions": { "allocate": { "require": { "box_type": "cold" } } } }, "delete": { "min_age": "30d", "actions": { "delete": {} } } } } } 
 
 这里不展开讲了，感兴趣的同学可以自行查看官方手册。
 
 现在管理策略(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 的属性，如下所示：

 GET _cat/nodeattrs?s=attr es01_hot 172.24.0.5 172.24.0.5 box_type hot es02_warm 172.24.0.4 172.24.0.4 box_type warm es03_cold 172.24.0.3 172.24.0.3 box_type cold 

由上可见我们有 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 PUT /_ilm/policy/nginx_ilm_policy { "policy": { "phases": { "hot": { "actions": { "rollover": { "max_docs": "10" } } }, "warm": { "min_age": "5s", "actions": { "allocate": { "include": { "box_type": "warm" } } } }, "cold": { "min_age": "20s", "actions": { "allocate": { "include": { "box_type": "cold" } } } }, "delete": { "min_age": "40s", "actions": { "delete": {} } } } } } 

创建 Index Template

我们基于索引模板来创建所需的索引，如下所示：

json PUT /_template/nginx_ilm_template { "index_patterns": ["nginx_logs-*"], "settings": { "number_of_shards": 1, "number_of_replicas": 0, "index.lifecycle.name": "nginx_ilm_policy", "index.lifecycle.rollover_alias": "nginx_logs", "index.routing.allocation.include.box_type": "hot" } } 

上述配置解释如下：
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 PUT nginx_logs-000001 { "aliases": { "nginx_logs": { "is_write_index":true } } } 

此时索引分布如下所示：

![](https://ws1.sinaimg.cn/large/6 ... fr.jpg)

修改 ILM Polling Interval

ILM Service 会在后台轮询执行 Policy，默认间隔时间为 10 分钟，为了更快地看到效果，我们将其修改为 1 秒。

json PUT _cluster/settings { "persistent": { "indices.lifecycle.poll_interval":"1s" } } 

开始吧

一切准备就绪，我们开始吧！

首先执行下面的新建文档操作 10 次。

json POST nginx_logs/_doc { "name":"abbc" } 

之后 Rollover 执行，新的索引创建，如下所示:

![](https://ws1.sinaimg.cn/large/6 ... 5c.jpg)

5 秒后，nginx_logs-000001 转到 Warm 阶段

![](https://ws1.sinaimg.cn/large/6 ... 78.jpg)

15 秒后(20 秒是指距离 Rollover 的时间，因为上面已经过去5秒了，所以这里只需要15秒)，nginx_logs-00001转到 Cold 阶段

![](https://ws1.sinaimg.cn/large/6 ... k1.jpg)

25 秒后，nginx_logs-00001删除

![](https://ws1.sinaimg.cn/large/6 ... 98.jpg)

至此，一个完整的 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

通知设置新通知

【直播回放】ElasticTalk #8 ECE - 即刻实现 Elasticsearch 私有云

【直播报名】ElasticTalk #8 ECE - 即刻实现 Elasticsearch 私有云

Elastic Stack 7.0.0 正式版已经发布

【直播回放】ElasticTalk #7 ElasticStack 6.7 功能概览

【直播】ElasticTalk #7 ElasticStack 6.7 功能概览

【直播回放】ElasticTalk #6 Multi-Fields 理解与实践

【直播】ElasticTalk #6 Multi-Fields 多字段理解与实践

【直播】Elasticsearch Hot-Warm 冷热架构那些事儿

Shay Banon: 关于“Open” Distro、开源和公司建设的几点思考

Elastic 官方培训来中国啦

【最新】Elasticsearch 6.6 Index Lifecycle Management 尝鲜

1. Index Lifecycle 索引生命周期

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

Hot 阶段

Warm 阶段

Cold 阶段

Delete 阶段

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

4. 实战

目标

ES 集群架构

创建 ILM Policy

创建 Index Template

创建初始索引 Index

修改 ILM Polling Interval

开始吧

总结

在线研讨会

参考资料：

Elastic Stack 6.5 最新功能

Elasticsearch v6.4.1 发布

【视频】ElasticTalk#4 Elastic认证考试那些事儿

X-Pack 代码已公开并上线

活动推荐

热门话题

通知设置 新通知