ELK,萌萌哒

Elastic 中国开发者大会 2021 演讲报名开放申请中

活动medcl 发布了置顶文章 • 0 个评论 • 529 次浏览 • 2021-11-27 11:17 • 来自相关话题

【直播回放】ElasticTalk #11 用 ELK 来分析 Elastic 的版本发布情况

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

第11期 ElasticTalk 直播已经结束,我们主要分享了如何基于 ELK 来分析 Elastic 的版本发布情况,内容如下:
  • Logstash 是什么以及主要组成?
  • 如何使用 Logstash 来爬取 github 上的 elastic 版本数据?
  • 如何使用 Kibana 来动态分析 elastic 发布数据? 


如果你没来的及参加直播,来看下回放吧!
 


 
ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下:
1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。
 
如果你对这个项目感兴趣,欢迎联系我!
 

招聘时间
我司在大力招聘 Elastic 技术专家,欢迎感兴趣的同学来投简历,地址如下:

 
想在 Elasticsearch 领域精进的同学,不妨来看看机会,作为 Elastic 官方战略级合作伙伴,我们的培训都是和 Elastic 官方同步的,机不可失!
而我们服务的客户遍布金融、证券、零售、制造业,充满挑战,感兴趣的你快来投递简历吧!

ElasticTalk #11 用 ELK 来分析 Elastic 的版本发布情况

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

直播时间:
5月4日(周六) 14:00~15:00

直播内容:
elastic 产品的一大特点就是版本迭代更新速度超级快,那么他们产品发布有无什么规律呢?比如多久会发一个大版本?我们能从历史数据中分析出些规律吗?本次直播我们就用 ELK 来分析下他们的发版情况吧!

cover.jpg

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

【直播报名】ElasticTalk #10 Kibana Canvas Intro

rockybean 发表了文章 • 0 个评论 • 1692 次浏览 • 2019-04-27 12:09 • 来自相关话题

直播时间:
4月27日(周六) 14:00~15:00

直播内容:
Kibana Canvas 是 ElasticStack 最新的大屏可视化展示方案,允许用户以更高的灵活性实现数据信息图的效果,而且其数据都是实时的,快来了解下吧~

dc.png


boston_workpad.png


flight_analysis.png


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

 

【直播回放】ElasticTalk #9 Elasticsearch 分词器那些事儿

rockybean 发表了文章 • 9 个评论 • 1438 次浏览 • 2019-04-21 09:14 • 来自相关话题

第9期 ElasticTalk 直播已经结束,我们主要讨论了 Elasticsearch 分词的那些事儿。
  • 分词是什么?
  • 分词器是什么?有哪些组成
  • analyze api 如何使用
  • 常见的场景

 
如果你没来的及参加直播,来看下回放吧!
 

 
ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下:
1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。
 
如果你对这个项目感兴趣,欢迎联系我!
 
招聘时间
我司在大力招聘 Elastic 技术专家,欢迎感兴趣的同学来投简历,地址如下:

 
想在 Elasticsearch 领域精进的同学,不妨来看看机会,作为 Elastic 官方战略级合作伙伴,我们的培训都是和 Elastic 官方同步的,机不可失!
而我们服务的客户遍布金融、证券、零售、制造业,充满挑战,感兴趣的你快来投递简历吧!

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

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

第8期 ElasticTalk 直播已经结束,我们主要讨论了 ECE Elasticsearch 私有云的解决方案 ,感兴趣的同学可去如下网址观看回放。

 
ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下:
1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。
 
如果你对这个项目感兴趣,欢迎联系我!
 
招聘时间
我司在大力招聘 Elastic 技术专家,欢迎感兴趣的同学来投简历,地址如下:

 
想在 Elasticsearch 领域精进的同学,不妨来看看机会,作为 Elastic 官方战略级合作伙伴,我们的培训都是和 Elastic 官方同步的,机不可失!
而我们服务的客户遍布金融、证券、零售、制造业,充满挑战,感兴趣的你快来投递简历吧!

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

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

直播时间:
4月13日(周六) 14:00~15:00

直播内容:
如果你正在为运维多个 Elasticsearch 集群苦恼,比如升级、扩缩容、备份、冷热架构实施等伤透脑筋,那么快来参加本次的直播吧!来了解下 Elastic 官方提供的私有云解决方案(ECE,Elastic Cloud Enterprise),一步到位,Elasticsearch As A Service 不是梦!

webinar_picture.png


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


 

Elastic Stack 7.0.0 正式版已经发布

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

Elastic Stack 7.0.0 正式版已经发布了,包含很多新的功能,大家可以去下载使用了。
 
 

dark-mode.gif

 
 
下载链接:
Elasticsearch:

Logstash:

Kibana:

 
其他模块及产品的下载:

 

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

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

第7期 ElasticTalk 直播已经结束,我们主要讨论了 ElasticStack 6.7 的新特性 ,感兴趣的同学可去如下网址观看回放。

 
ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下:
1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。
 
如果你对这个项目感兴趣,欢迎联系我!
 

招聘时间
我司在大力招聘 Elastic 技术专家,欢迎感兴趣的同学来投简历,地址如下:

 
想在 Elasticsearch 领域精进的同学,不妨来看看机会,作为 Elastic 官方战略级合作伙伴,我们的培训都是和 Elastic 官方同步的,机不可失!
而我们服务的客户遍布金融、证券、零售、制造业,充满挑战,感兴趣的你快来投递简历吧!
 
 
 

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

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

直播时间:
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 足球版

 
  • ......

 

elastic-stack-blog-thumb.png

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

 
 

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

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

第6期 ElasticTalk 直播已经结束,我们主要讨论了 Elasticsearch multi-fields 多字段的相关知识 ,感兴趣的同学可去如下网址观看回放。
 

 
ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下:
1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能
2.锻炼参与者的选题、语言表达及沟通能力
 
目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。
 
如果你对这个项目感兴趣,欢迎联系我!
 
招聘时间
我司在大力招聘 Elastic 技术专家,欢迎感兴趣的同学来投简历,地址如下:

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

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

直播时间:
3月30日(周六) 14:00~15:00

直播内容:
你听说过 multi-fields 吗?了解过它的应用场景吗?快来注册报名吧!
Screen_Shot_2019-02-21_at_7.58_.55_AM_.jpg



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

 

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

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

直播时间:
3月23日(本周六) 14:00~15:00


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


hot-warm_cluster.png



直播方式: 

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

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

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

Shay 的一篇文章,分享一下,关于 Elastic、开源及社区。

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 个评论 • 6662 次浏览 • 2019-02-26 08:08 • 来自相关话题

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

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

【最新】Elasticsearch 6.6 Index Lifecycle Management 尝鲜

rockybean 发表了文章 • 8 个评论 • 17179 次浏览 • 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)组成,比如 bookpeople都可以用作索引名称,可以简单类比为关系型数据库的表(table)。

      所谓生命,即生与死;索引的便是创建删除了。

      在我们日常使用 Elasticsearch 的时候,索引的创建与删除似乎是很简单的事情,用的时候便创建,不用了删除即可,有什么好管理的呢?

      这就要从 Elasticsearch 的应用场景来看了。

      业务搜索场景,用户会将业务数据存储在 Elasticsearch 中,比如商品数据、订单数据、用户数据等,实现快速的全文检索功能。像这类数据基本都是累加的,不会删除。一般删除的话,要么是业务升级,要么是业务歇菜了。此种场景下,基本只有生,没有死,也就不存在管理一说。

      而在日志业务场景中,用户会将各种日志,如系统、防火墙、中间件、数据库、web 服务器、应用日志等全部实时地存入 Elasticsearch 中,进行即席日志查询与分析。这种类型的数据都会有时间维度,也就是时序性的数据。由于日志的数据量过大,用户一般不会存储全量的数据,一般会在 Elasticsearch 中存储热数据,比如最近7天、30天的数据等,而在7天或者30天之前的数据都会被删除。为了便于操作,用户一般会按照日期来建立索引,比如 nginx 的日志索引名可能为 nginx_log-2018.11.12nginx_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]( ... 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,后文会详细讲解。

      ![]( ... 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]( ... ug.jpg)

      从上图看下来 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 />

    此时索引分布如下所示:

    ![]( ... fr.jpg)

    修改 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 执行,新的索引创建,如下所示:

    ![]( ... 5c.jpg)

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

    ![]( ... 78.jpg)

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

    ![]( ... k1.jpg)

    25 秒后,nginx_logs-00001删除

    ![]( ... 98.jpg)



    至此,一个完整的 ILM Policy 执行的流程就结束了,而后续 nginx_logs-000002 也会按照这个设定进行流转。

    总结


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

    在线研讨会


    一篇文章所能承载的信息量和演示效果终究是有限的,2月份我们会针对 ILM 做一次线上研讨会,感兴趣的同学可以点击下面的链接注册报名。



    [](x)



    为了提高研讨会的质量,我们本次引入了审核机制,报名的同学请耐心等待,待我们审核通过后,您会收到我们的邮件邀请。



    参考资料:


    1. ... .html
    2. ... h-5-x