ElasticTalk

ElasticTalk

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

资讯动态rockybean 发表了文章 • 8 个评论 • 147 次浏览 • 1 天前 • 来自相关话题

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

【直播报名】ElasticTalk #9 Elasticsearch 分词器那些事儿

资料分享rockybean 发表了文章 • 0 个评论 • 163 次浏览 • 2 天前 • 来自相关话题

直播时间: 4月20日(周六) 14:00~15:00 直播内容: 对于刚接触 ES 的新手来说,分词器是个坎儿,如何正确理解分词以及如何正确使用分词器,是很重要的一项基础功,这次我们就来聊聊分词器的那些事儿~
analysis-chain.png
直播方式:  直播链接会在开始前发送到讨论群中。 点击下方网站链接,选择对应 Webinar 注册即可 Webinar 注册链接
直播时间: 4月20日(周六) 14:00~15:00 直播内容: 对于刚接触 ES 的新手来说,分词器是个坎儿,如何正确理解分词以及如何正确使用分词器,是很重要的一项基础功,这次我们就来聊聊分词器的那些事儿~
analysis-chain.png
直播方式:  直播链接会在开始前发送到讨论群中。 点击下方网站链接,选择对应 Webinar 注册即可 Webinar 注册链接

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

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

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

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

资讯动态rockybean 发表了文章 • 0 个评论 • 117 次浏览 • 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 注册即可 Webinar 注册链接  
直播时间: 4月13日(周六) 14:00~15:00 直播内容: 如果你正在为运维多个 Elasticsearch 集群苦恼,比如升级、扩缩容、备份、冷热架构实施等伤透脑筋,那么快来参加本次的直播吧!来了解下 Elastic 官方提供的私有云解决方案(ECE,Elastic Cloud Enterprise),一步到位,Elasticsearch As A Service 不是梦!
webinar_picture.png
直播方式:  直播链接会在开始前发送到讨论群中。 点击下方网站链接,选择对应 Webinar 注册即可 Webinar 注册链接  

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

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

第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 官方同步的,机不可失! 而我们服务的客户遍布金融、证券、零售、制造业,充满挑战,感兴趣的你快来投递简历吧!      

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

资讯动态rockybean 发表了文章 • 0 个评论 • 164 次浏览 • 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 注册即可  Webinar 注册链接  

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

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

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

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

资讯动态rockybean 发表了文章 • 0 个评论 • 183 次浏览 • 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 注册即可   Webinar 注册链接
直播时间: 3月30日(周六) 14:00~15:00 直播内容: 你听说过 multi-fields 吗?了解过它的应用场景吗?快来注册报名吧!
Screen_Shot_2019-02-21_at_7.58_.55_AM_.jpg
直播方式:  直播链接会在开始前发送到讨论群中。 点击下方网站链接,选择对应 Webinar 注册即可   Webinar 注册链接

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

资讯动态rockybean 发表了文章 • 1 个评论 • 221 次浏览 • 2019-03-22 09:34 • 来自相关话题

直播时间: 3月23日(本周六) 14:00~15:00 直播内容: Elasticsearch 冷热架构可以帮助用户以较低硬件成本实现同等规模的数据存储,解决成本支出。 本次直播我们就来好好讨论下 冷热架构那些事儿!
hot-warm_cluster.png
直播方式:  直播链接会在开始前发送到讨论群中。   点击下方网站链接,选择对应 Webinar 注册即可   Webinar 注册链接   
直播时间: 3月23日(本周六) 14:00~15:00 直播内容: Elasticsearch 冷热架构可以帮助用户以较低硬件成本实现同等规模的数据存储,解决成本支出。 本次直播我们就来好好讨论下 冷热架构那些事儿!
hot-warm_cluster.png
直播方式:  直播链接会在开始前发送到讨论群中。   点击下方网站链接,选择对应 Webinar 注册即可   Webinar 注册链接   

ElasticTalk #4 ILM 索引生命周期管理直播回放

资料分享rockybean 发表了文章 • 0 个评论 • 173 次浏览 • 2019-03-17 15:19 • 来自相关话题

第4期 ElasticTalk 直播已经结束,我们主要讨论了 Elasticsearch 6.6 新增的 Index Lifecycle Management 功能,感兴趣的同学可去如下网址观看回放。   ElasticTalk #4 ILM   ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下: 1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能 2.锻炼参与者的选题、语言表达及沟通能力   目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。   如果你对这个项目感兴趣,欢迎联系我!    
第4期 ElasticTalk 直播已经结束,我们主要讨论了 Elasticsearch 6.6 新增的 Index Lifecycle Management 功能,感兴趣的同学可去如下网址观看回放。   ElasticTalk #4 ILM   ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下: 1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能 2.锻炼参与者的选题、语言表达及沟通能力   目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。   如果你对这个项目感兴趣,欢迎联系我!    

【ElasticTalk 直播来袭】Elasticsearch 6.6 之 Index Lifecycle Management Practice

资料分享rockybean 发表了文章 • 0 个评论 • 221 次浏览 • 2019-03-14 17:41 • 来自相关话题

直播时间: 3月16日(本周六) 14:00~15:00 直播内容: Elastic Stack 已经更新到 6.6 版本,该版本带来很多新功能,比如:
  • Index Lifecycle Management
  • Frozen Index
  • Geoshape based on Bkd Tree
  • SQL adds support for Date histograms
  • ......
在这些众多功能中,Index Lifecycle Management(索引生命周期管理,后文简称 ILM) 是最受社区欢迎的功能,我们此次研讨会将聚焦该功能,为大家讲解关于 ILM 的概念、原理及实践。
ilm_summary.png
直播方式: 待定(B站或者斗鱼) 直播链接会在开始前发送到讨论群中。 点击我报名吧!

【最新】Elasticsearch 6.6 Index Lifecycle Management 尝鲜

资讯动态rockybean 发表了文章 • 2 个评论 • 1749 次浏览 • 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

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 界面来设置这些策略,如下所示:

kibana ilm

从上图看下来 ILM 的设置是不是一目了然呢?

当然,ILM 是有自己的 api 的,比如上面图片对应的 api 请求如下:

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 请求如下:

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

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

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 如下:

PUT nginx_logs-000001
{
  "aliases": {
    "nginx_logs": {
      "is_write_index":true
    }
  }
}

此时索引分布如下所示:

修改 ILM Polling Interval

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

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

开始吧

一切准备就绪,我们开始吧!

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

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

之后 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

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

参考资料:

  1. https://www.elastic.co/guide/en/elasticsearch/reference/6.6/index-lifecycle-management.html
  2. https://www.elastic.co/blog/hot-warm-architecture-in-elasticsearch-5-x

ET007 ElasticStack 6.5 介绍

ElasticsearchLeon J 发表了文章 • 1 个评论 • 1178 次浏览 • 2018-11-19 09:18 • 来自相关话题

就在 11月14日,ElasticStack 6.5.0 发布了,此次发布带来了许多激动人心的特性,我们一起来体验一下:

WX20181118-120551@2x

如果没有任何数据,kibana会提示我们导入sample数据,这边我选择Try our sample data, 然后导入全部3个样例数据,这可以让我们在没有数据的情况下快速体验新特性。

Infrastructure & Logs UI

很多用户使用 ElasticStack 收集基础架构的日志和指标,比如系统日志、安全日志、CPU指标,内存指标等等。在6.5中,kibana 侧边栏中增加了 Infrastructure 和 Logs 两个新的 tab,让用户更简单地查看自己的基础架构,和每台主机或者容器里的日志。

logs

进入logs标签页,如果当前没有数据,kibana会引导我们添加数据

WX20181118-121032@2x

我们选择 system logs

WX20181118-121047@2x

根据指示,我们安装部署好filebeat并启动,再次进入 logs 标签页便可以看到收集到的系统日志了

image-20181118185158451

  1. 搜索过滤框:在这里可以像在 discover 里一样写query string,并且会有输入提示
  2. 时间选择框:可以选择需要查看的时间点,如果点了 Stream live,会持续监听尾部新输出的日志内容,类似 linux 命令中的tail -f
  3. 日志时间轴:高亮的部位是当前查看日志所在的时间范围,对应的区域图标识了日志量

假如我想实现 tail -f /var/log/system.log | grep google.com 一样的效果,可以打开 Stream live,并在搜索过滤框中这样输入:

WX20181118-173432@2x

很简单,很方便有木有?

Infrastructure

同样在kibana的引导下安装 Metric beat,并开启system模块,启动后进入 infrastructure 标签页:

image-20181118190614385

这里可以直观地看到所有基础架构的指标状况,深色的内层代表主机,颜色代表了健康状况。浅灰色的外层代表了group,因为我只在自己的笔记本上做了部署,所以只能看到一个host。

image-20181118191527060

点击主机会弹出菜单

  • View logs : 跳转到 logs 标签页,并通过搜索过滤框指定host,只查看这台主机的日志。
  • View metrics : 跳转到这台主机的指标详情,可以查看历史数据 shoot

APM

Java 和 Go

不负众望,继 Nodejs、Python、Ruby、Javascript 之后,Elastic APM 5.6.0 新增了对 Java 和 Golang 的支持!

Distributed Tracing

在 SOA 和 MSA 大行其道的年代,如何追踪请求在各个系统之间的流动成为了apm的关键问题。

Elastic APM 支持 OpenTracing 标准,并在各个agent里内置了 OpenTracing 兼容的bridge

以下是官网上该特性的截图:

distributed_tracing

APM Server 监控

如 ElasticStack的其他产品一般,APM也支持了监控,并可以在 Kinbana Montoring下查看监控信息:

apm_monitoring

APM Server 内存占用优化

通过新的基于NDJSON的协议,agent可以在采集信息后通过事件流立即发往APM server,这样 APM Server可以一个接一个地处理接收到的事件,而不是一次性地收到一大块(chunk),这样在很大程度上减少了APM Server的内存占用。

Elasticsearch

Cross-cluster replication

这里的副本并非我们平时常见的分片副本,而是通过在集群B配置一个副本indexB来追随集群A中的indexA,indexA中发生的任何变化都会同步到indexB中来。另外也可以配置一个pattern,当集群A出现符合pattern的索引,自动在集群B创建他的副本,这听起来很酷。值得一提的是,这将是白金版里新增的一个特性。

Minimal Snapshots

snapshot 是 es 中用来创建索引副本的特性,在之前的版本中,snapshot会把完整的 index 都保存下来,包括原始数据和索引数据等等。新的 Minimal Snapshots 提供了一种只备份 _source 内容和 index metadata,当需要恢复时,需要通过 reindex 操作来完成。最小快照最多可能帮你节省50%的磁盘占用,但是会花费更多的时间来恢复。这个特性可能并不适合所有人,但给恢复窗口比较长,且磁盘容量有限的用户多了一种选择。

SQL / ODBC

现在可以使用 支持 ODBC 的第三方工具来连接 elasticsearch 了!我想可以找时间试试用 tableau 直连 elasticsearch会是啥效果。

Java 11

Java11 是一个 LTS 版本,相信会有越来越多的用户升级到 java11

G1GC支持

经过无数的测试,Elasticsearch官方宣布了在 JDK 10+ 上支持 G1GC。G1GC 相比 CMS有诸多优势,如今可以放心地使用G1GC了。(期待对ZGC的支持!)

Authorization realm

X-Pack Security中的新特性,可以对用户认证和用户授权分别配置 realm,比如使用内置的用户体系来认证,再去ldap中获取用户的角色、权限等信息。这也是白金版新增的特性。

机器学习的新特性

  • 支持在同一个机器学习任务中分析多个时间系列
  • 为机器学习任务添加了新的多分桶(multi-bucket) 分析

Kibana

Canvas

Canvas ! 我在做数据分析师的同学看到之后说太酷了,像 PPT。

点击侧边栏的 canvas 标签,可以看到我们先前导入的样本数据也包含了 canvas 样例:

WX20181118-210126@2x

在 11月的 深圳开发者大会上,上海普翔 也用 canvas 对填写调查问卷的参会人员做了分析:

UNADJUSTEDNONRAW_thumb_1adc

https://github.com/alexfrancoeur/kibana_canvas_examples 这里有很多非常不错的 canvas 样例供大家学习,把json文件直接拖到 canvas 页面就可以导入学习了!

Spaces

把 kibana 对象(比如 visualizations、dashboards)组织到独立的 space 里,并且通过 RBAC 来控制哪些用户可以访问哪些 space。这实在是太棒了,想象在一个企业里,多个部门通过kibana查询、分析数据,大家关注的dashboard肯定是不一样的,在6.5之前,我们只能通过社区插件来实现这样的需求,而大版本的升级可能直接导致插件不可用,有了 Space,我们不必再担心!

image-20181118212404768

Rollups UI

Rollup 是 es6.4 中新增的一个特性,用来把一些历史数据压缩归档,用作以后的分析。6.5.0 中 kibana 增加了一个界面用来查看和管理 Rollup 任务。

image9

Data visualizer for files

通过可视化的方式查看文件的结构,查看其中出现最频繁的内容:

highlights_6_5_viz-logs

Beats

Beats Central Management

Beats 终于也支持中心化配置管理了!我们只需按照往常一样安装filebeat、metricbeat,然后使用 filebeat enroll <kibana-url> <token>,便可以通过kibana来管理beats的配置、甚至给他们打上tag:

Image from iOS

想一想,假如我们在上千台机器上部署filebeat,如果哪天需要批量变更配置文件,只需要通过脚本调用配置管理的API就可以了

Functionbeat

Functionbeat是一种新的beat类型,可以被部署为一个方法,而不需要跑在服务器环境上,比如 AWS Lambda function。

以上就是 6.5.0 版本的主要特性,更详细的内容可以查看 https://www.elastic.co/blog/elastic-stack-6-5-0-released ,希望通过我的介绍,可以让大家了解到新版本所带来的激动人心的特性。

Image from iOS

你看懂 Elasticsearch Log 中的 GC 日志了吗?

Elasticsearchrockybean 发表了文章 • 0 个评论 • 1148 次浏览 • 2018-09-22 23:29 • 来自相关话题

如果你关注过 elasticsearch 的日志,可能会看到如下类似的内容:

[2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent [2.2s] collecting in the last [2.3s]

[2018-06-30T17:57:29,020][INFO ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][old][228385][160772] duration [5s], collections [1]/[5.1s], total [5s]/[4.4d], memory [945.4mb]->[958.5mb]/[1007.3mb], all_pools {[young] [87.8mb]->[100.9mb]/[133.1mb]}{[survivor] [0b]->[0b]/[16.6mb]}{[old] [857.6mb]->[857.6mb]/[857.6mb]}

看到其中的[gc]关键词你也猜到了这是与 GC 相关的日志,那么你了解每一部分的含义吗?如果不了解,你可以继续往下看了。

我们先从最简单的看起:

  1. 第一部分是日志发生的时间
  2. 第二部分是日志级别,这里分别是WARNINFO
  3. 第三部分是输出日志的类,我们后面也会讲到这个类
  4. 第四部分是当前 ES 节点名称
  5. 第五部分是 gc 关键词,我们就从这个关键词聊起。

友情提示:对 GC 已经了如指掌的同学,可以直接翻到最后看答案。

1. 什么是 GC?

GC,全称是 Garbage Collection (垃圾收集)或者 Garbage Collector(垃圾收集器)。

在使用 C语言编程的时候,我们要手动的通过 mallocfree来申请和释放数据需要的内存,如果忘记释放内存,就会发生内存泄露的情况,即无用的数据占用了宝贵的内存资源。而Java 语言编程不需要显示的申请和释放内存,因为 JVM 可以自动管理内存,这其中最重要的一部分就是 GC,即 JVM 可以自主地去释放无用数据(垃圾)占用的内存。

我们研究 GC 的主要原因是 GC 的过程会有 Stop The World(STW)的情况发生,即此时用户线程会停止工作,如果 STW 的时间过长,则应用的可用性、实时性等就下降的很厉害。

GC主要解决如下3个问题:

  1. 如何找到垃圾?
  2. 如何回收垃圾?
  3. 何时回收垃圾?

我们一个个来看下。

1.1 如何找到垃圾?

所谓垃圾,指的是不再被使用(引用)的对象。Java 的对象都是在堆(Heap)上创建的,我们这里默认也只讨论堆。那么现在问题就变为如何判定一个对象是否还有被引用,思路主要有如下两种:

  1. 引用计数法,即在对象被引用时加1,去除引用时减1,如果引用值为0,即表明该对象可回收了。
  2. 可达性分析法,即通过遍历已知的存活对象(GC Roots)的引用链来标记出所有存活对象

方法1简单粗暴效率高,但准确度不行,尤其是面对互相引用的垃圾对象时无能为力。

方法2是目前常用的方法,这里有一个关键是 GC Roots,它是判定的源头,感兴趣的同学可以自己去研究下,这里就不展开讲了。

1.2 如何回收垃圾?

垃圾找到了,该怎么回收呢?看起来似乎是个很傻的问题。直接收起来扔掉不就好了?!对应到程序的操作,就是直接将这些对象占用的空间标记为空闲不就好了吗?那我们就来看一下这个基础的回收算法:标记-清除(Mark-Sweep)算法。

1.2.1 标记-清除 算法(Mark Sweep)

该算法很简单,使用通过可达性分析分析方法标记出垃圾,然后直接回收掉垃圾区域。它的一个显著问题是一段时间后,内存会出现大量碎片,导致虽然碎片总和很大,但无法满足一个大对象的内存申请,从而导致 OOM,而过多的内存碎片(需要类似链表的数据结构维护),也会导致标记和清除的操作成本高,效率低下,如下图所示:

1.2.2 复制算法(Copying)

为了解决上面算法的效率问题,有人提出了复制算法。它将可用内存一分为二,每次只用一块,当这一块内存不够用时,便触发 GC,将当前存活对象复制(Copy)到另一块上,以此往复。这种算法高效的原因在于分配内存时只需要将指针后移,不需要维护链表等。但它最大的问题是对内存的浪费,使用率只有 50%。

但这种算法在一种情况下会很高效:Java 对象的存活时间极短。据 IBM 研究,Java 对象高达 98% 是朝生夕死的,这也意味着每次 GC 可以回收大部分的内存,需要复制的数据量也很小,这样它的执行效率就会很高。

1.2.3 标记-整理算法(Mark Compact)

该算法解决了第1中算法的内存碎片问题,它会在回收阶段将所有内存做整理,如下图所示:

但它的问题也在于增加了整理阶段,也就增加了 GC 的时间。

1.2.4 分代收集算法(Generation Collection)

既然大部分 Java 对象是朝生夕死的,那么我们将内存按照 Java 生存时间分为 新生代(Young)老年代(Old),前者存放短命僧,后者存放长寿佛,当然长寿佛也是由短命僧升级上来的。然后针对两者可以采用不同的回收算法,比如对于新生代采用复制算法会比较高效,而对老年代可以采用标记-清除或者标记-整理算法。这种算法也是最常用的。JVM Heap 分代后的划分一般如下所示,新生代一般会分为 Eden、Survivor0、Survivor1区,便于使用复制算法。

将内存分代后的 GC 过程一般类似下图所示:

  1. 对象一般都是先在 Eden区创建
  2. Eden区满,触发 Young GC,此时将 Eden中还存活的对象复制到 S0中,并清空 Eden区后继续为新的对象分配内存
  3. Eden区再次满后,触发又一次的 Young GC,此时会将 EdenS0中存活的对象复制到 S1中,然后清空EdenS0后继续为新的对象分配内存
  4. 每经过一次 Young GC,存活下来的对象都会将自己存活次数加1,当达到一定次数后,会随着一次 Young GC 晋升到 Old
  5. Old区也会在合适的时机进行自己的 GC

1.2.5 常见的垃圾收集器

前面我们讲了众多的垃圾收集算法,那么其具体的实现就是垃圾收集器,也是我们实际使用中会具体用到的。现代的垃圾收集机制基本都是分代收集算法,而 YoungOld区分别有不同的垃圾收集器,简单总结如下图:

从上图我们可以看到 YoungOld区有不同的垃圾收集器,实际使用时会搭配使用,也就是上图中两两连线的收集器是可以搭配使用的。这些垃圾收集器按照运行原理大概可以分为如下几类:

  • Serial GC串行,单线程的收集器,运行 GC 时需要停止所有的用户线程,且只有一个 GC 线程
  • Parallel GC并行,多线程的收集器,是 Serial 的多线程版,运行时也需要停止所有用户线程,但同时运行多个 GC 线程,所以效率高一些
  • Concurrent GC并发,多线程收集器,GC 分多阶段执行,部分阶段允许用户线程与 GC 线程同时运行,这也就是并发的意思,大家要和并行做一个区分。
  • 其他

我们下面简单看一下他们的运行机制。

1.2.5.1 Serial GC

该类 Young区的为 Serial GCOld区的为Serial Old GC。执行大致如下所示:

1.2.5.2 Parallel GC

该类Young 区的有 ParNewParallel ScavengeOld 区的有Parallel Old。其运行机制如下,相比 Serial GC ,其最大特点在于 GC 线程是并行的,效率高很多:

1.2.5.3 Concurrent Mark-Sweep GC

该类目前只是针对 Old 区,最常见就是CMS GC,它的执行分为多个阶段,只有部分阶段需要停止用户进程,这里不详细介绍了,感兴趣可以去找相关文章来看,大体执行如下:

1.2.5.4 其他

目前最新的 GC 有G1GCZGC,其运行机制与上述均不相同,虽然他们也是分代收集算法,但会把 Heap 分成多个 region 来做处理,这里不展开讲,感兴趣的可以参看最后参考资料的内容。

1.2.6 Elasticsearch 的 GC 组合

Elasticsearch 默认的 GC 配置是CMS GC ,其 Young 区ParNewOld 区CMS,大家可以在 config/jvm.options中看到如下的配置:

## GC configuration
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly

1.3 何时进行回收?

现在我们已经知道如何找到和回收垃圾了,那么什么时候回收呢?简单总结如下:

  1. Young 区的GC 都是在 Eden 区满时触发
  2. Serial Old 和 Parallel Old 在 Old 区是在 Young GC 时预测Old 区是否可以为 young 区 promote 到 old 区 的 object 分配空间,如果不可用则触发 Old GC。这个也可以理解为是 Old区满时。
  3. CMS GC 是在 Old 区大小超过一定比例后触发,而不是 Old 区满。这个原因在于 CMS GC 是并发的算法,也就是说在 GC 线程收集垃圾的时候,用户线程也在运行,因此需要预留一些 Heap 空间给用户线程使用,防止由于无法分配空间而导致 Full GC 发生。

2. GC Log 如何阅读?

前面讲了这么多,终于可以回到开篇的问题了,我们直接来看答案

[2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent [2.2s] collecting in the last [2.3s]

[gc][这是第228384次GC 检查] 在最近 2.3 s 内花了 2.2s 用来做垃圾收集,这占比似乎有些过了,请抓紧来关注下。

[2018-06-30T17:57:29,020][INFO ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][old][228385][160772] duration [5s], collections [1]/[5.1s], total [5s]/[4.4d], memory [945.4mb]->[958.5mb]/[1007.3mb], all_pools {[young] [87.8mb]->[100.9mb]/[133.1mb]}{[survivor] [0b]->[0b]/[16.6mb]}{[old] [857.6mb]->[857.6mb]/[857.6mb]}

我们直接来看具体的含义好了,相信有了前面的 GC 基础知识,大家在看这里解释的时候就非常清楚了。

  • [gc][本次是 old GC][这是第228385次 GC 检查][从 JVM 启动至今发生的第 160772次 GC]

  • duration [本次检查到的 GC 总耗时 5 秒,可能是多次的加和],

  • collections [从上次检查至今总共发生1次 GC]/[从上次检查至今已过去 5.1 秒],

  • total [本次检查到的 GC 总耗时为 5 秒]/[从 JVM 启动至今发生的 GC 总耗时为 4.4 天],

  • memory [ GC 前 Heap memory 空间]->[GC 后 Heap memory 空间]/[Heap memory 总空间],

  • all_pools(分代部分的详情) {[young 区][GC 前 Memory ]->[GC后 Memory]/[young区 Memory 总大小] } {[survivor 区][GC 前 Memory ]->[GC后 Memory]/[survivor区 Memory 总大小] }{[old 区][GC 前 Memory ]->[GC后 Memory]/[old区 Memory 总大小] }

3. 看看源码

从日志中我们可以看到输出这些日志的类名叫做JvmGcMonitorService,我们去源码中搜索很快会找到它/Users/rockybean/code/elasticsearch/core/src/main/java/org/elasticsearch/monitor/jvm/JvmGcMonitorService.java,这里就不详细展开讲解源码了,它执行的内容大概如下图所示:

关于打印日志的格式在源码也有,如下所示:

private static final String SLOW_GC_LOG_MESSAGE =
"[gc][{}][{}][{}] duration [{}], collections [{}]/[{}], total [{}]/[{}], memory [{}]->[{}]/[{}], all_pools {}";
private static final String OVERHEAD_LOG_MESSAGE = "[gc][{}] overhead, spent [{}] collecting in the last [{}]";

另外细心的同学会发现输出的日志中 gc 只分了 young 和 old ,原因在于 ES 对 GC Name 做了封装,封装的类为:org.elasticsearch.monitor.jvm.GCNames,相关代码如下:

    public static String getByMemoryPoolName(String poolName, String defaultName) {
        if ("Eden Space".equals(poolName) || "PS Eden Space".equals(poolName) || "Par Eden Space".equals(poolName) || "G1 Eden Space".equals(poolName)) {
            return YOUNG;
        }
        if ("Survivor Space".equals(poolName) || "PS Survivor Space".equals(poolName) || "Par Survivor Space".equals(poolName) || "G1 Survivor Space".equals(poolName)) {
            return SURVIVOR;
        }
        if ("Tenured Gen".equals(poolName) || "PS Old Gen".equals(poolName) || "CMS Old Gen".equals(poolName) || "G1 Old Gen".equals(poolName)) {
            return OLD;
        }
        return defaultName;
    }

    public static String getByGcName(String gcName, String defaultName) {
        if ("Copy".equals(gcName) || "PS Scavenge".equals(gcName) || "ParNew".equals(gcName) || "G1 Young Generation".equals(gcName)) {
            return YOUNG;
        }
        if ("MarkSweepCompact".equals(gcName) || "PS MarkSweep".equals(gcName) || "ConcurrentMarkSweep".equals(gcName) || "G1 Old Generation".equals(gcName)) {
            return OLD;
        }
        return defaultName;
    }

在上面的代码中,你会看到很多我们在上一节中提到的 GC 算法的名称。

至此,源码相关部分也讲解完毕,感兴趣的大家可以自行去查阅。

4. 总结

讲解 GC 的文章已经很多,本文又唠唠叨叨地讲一遍基础知识,是希望对于第一次了解 GC 的同学有所帮助。因为只有了解了这些基础知识,你才不至于被这些 GC 的输出吓懵。希望本文对你理解 ES 的 GC 日志 有所帮助。

5. 参考资料

  1. Java Hotspot G1 GC的一些关键技术(https://mp.weixin.qq.com/s/4ufdCXCwO56WAJnzng_-ow
  2. Understanding Java Garbage Collection(https://www.cubrid.org/blog/understanding-java-garbage-collection
  3. 《深入理解Java虚拟机:JVM高级特性与最佳实践》

6. 相关推荐

如果你想深入的了解 JAVA GC 的知识,可以关注 ElasticTalk 公众号,回复 GC关键词后即可获取作者推荐的电子书等资料。

elasticTalk,qrcode

通过 metadata 使logstash配置更简洁

LogstashLeon J 发表了文章 • 0 个评论 • 1120 次浏览 • 2018-09-04 13:17 • 来自相关话题

从Logstash 1.5开始,我们可以在logstash配置中使用metadata。metadata不会在output中被序列化输出,这样我们便可以在metadata中添加一些临时的中间数据,而不需要去删除它。

我们可以通过以下方式来访问metadata:

[@metadata][foo]

用例

假设我们有这样一条日志:

[2017-04-01 22:21:21] production.INFO: this is a test log message by leon

我们可以在filter中使用grok来做解析:

grok {
      match => { "message" => "\[%{TIMESTAMP_ISO8601:timestamp}\] %{DATA:env}\.%{DATA:log_level}: %{DATA:content}" }
    }

解析的结果为

{
      "env" => "production",
      "timestamp" => "2017-04-01 22:21:21",
      "log_level" => "INFO",
      "content" => "{\"message\":\"[2017-04-01 22:21:21] production.INFO: this is a test log message by leon\"}"
}

假设我们希望

  1. 能把log_level为INFO的日志丢弃掉,但又不想让该字段出现在最终的输出中
  2. 输出的索引名中能体现出env,但也不想让该字段出现在输出结果里

对于1,一种方案是在输出之前通过mutate插件把不需要的字段删除掉,但是一旦这样的处理多了,会让配置文件变得“不干净”。

通过 metadata,我们可以轻松地处理这些问题:

grok {
    match => { "message" => "\[%{TIMESTAMP_ISO8601:timestamp}\] %{DATA:[@metadata][env]}\.%{DATA:[@metadata][log_level]}: %{DATA:content}" }
}

if [@metadata][log_level] == "INFO"{
    drop{}    
}

output{
    elasticsearch {
        hosts => ["127.0.0.1:9200"]
        index => "%{[@metadata][env]}-log-%{+YYYY.MM}"
        document_type => "_doc"
    }
}

除了简化我们的配置文件、减少冗余字段意外,同时也能提高logstash的处理速度。

Elasticsearch input插件

有些插件会用到metadata这个特性,比如elasticsearch input插件:

input {
  elasticsearch {
    host => "127.0.0.1"
    # 把 ES document metadata (_index, _type, _id) 包存到 @metadata 中
    docinfo_in_metadata => true
  }
}

filter{
    ......
}

output {
  elasticsearch {
    document_id => "%{[@metadata][_id]}"
    index => "transformed-%{[@metadata][_index]}"
    type => "%{[@metadata][_type]}"
  }
}

调试

一般来说metadata是不会出现在输出中的,除非使用 rubydebug codec 的方式输出:

output { 
  stdout { 
    codec  => rubydebug {
      metadata => true
    }
  }
}

日志经过处理后输出中会包含:

{
    ....,
    "@metadata" => {
        "env" => "production",
        "log_level" => "INFO"
    }
}

总结

由上可见,metadata提供了一种简单、方便的方式来保存中间数据。这样一方面减少了logstash配置文件的复杂性:避免调用remove_field,另一方面也减少了输出中的一些不必要的数据。通过这篇对metadata的介绍,希望能对大家有所帮助。

elasticTalk,qrcode

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

资讯动态rockybean 发表了文章 • 8 个评论 • 147 次浏览 • 1 天前 • 来自相关话题

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

【直播报名】ElasticTalk #9 Elasticsearch 分词器那些事儿

资料分享rockybean 发表了文章 • 0 个评论 • 163 次浏览 • 2 天前 • 来自相关话题

直播时间: 4月20日(周六) 14:00~15:00 直播内容: 对于刚接触 ES 的新手来说,分词器是个坎儿,如何正确理解分词以及如何正确使用分词器,是很重要的一项基础功,这次我们就来聊聊分词器的那些事儿~
analysis-chain.png
直播方式:  直播链接会在开始前发送到讨论群中。 点击下方网站链接,选择对应 Webinar 注册即可 Webinar 注册链接
直播时间: 4月20日(周六) 14:00~15:00 直播内容: 对于刚接触 ES 的新手来说,分词器是个坎儿,如何正确理解分词以及如何正确使用分词器,是很重要的一项基础功,这次我们就来聊聊分词器的那些事儿~
analysis-chain.png
直播方式:  直播链接会在开始前发送到讨论群中。 点击下方网站链接,选择对应 Webinar 注册即可 Webinar 注册链接

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

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

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

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

资讯动态rockybean 发表了文章 • 0 个评论 • 117 次浏览 • 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 注册即可 Webinar 注册链接  
直播时间: 4月13日(周六) 14:00~15:00 直播内容: 如果你正在为运维多个 Elasticsearch 集群苦恼,比如升级、扩缩容、备份、冷热架构实施等伤透脑筋,那么快来参加本次的直播吧!来了解下 Elastic 官方提供的私有云解决方案(ECE,Elastic Cloud Enterprise),一步到位,Elasticsearch As A Service 不是梦!
webinar_picture.png
直播方式:  直播链接会在开始前发送到讨论群中。 点击下方网站链接,选择对应 Webinar 注册即可 Webinar 注册链接  

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

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

第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 官方同步的,机不可失! 而我们服务的客户遍布金融、证券、零售、制造业,充满挑战,感兴趣的你快来投递简历吧!      

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

资讯动态rockybean 发表了文章 • 0 个评论 • 164 次浏览 • 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 注册即可  Webinar 注册链接  

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

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

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

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

资讯动态rockybean 发表了文章 • 0 个评论 • 183 次浏览 • 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 注册即可   Webinar 注册链接
直播时间: 3月30日(周六) 14:00~15:00 直播内容: 你听说过 multi-fields 吗?了解过它的应用场景吗?快来注册报名吧!
Screen_Shot_2019-02-21_at_7.58_.55_AM_.jpg
直播方式:  直播链接会在开始前发送到讨论群中。 点击下方网站链接,选择对应 Webinar 注册即可   Webinar 注册链接

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

资讯动态rockybean 发表了文章 • 1 个评论 • 221 次浏览 • 2019-03-22 09:34 • 来自相关话题

直播时间: 3月23日(本周六) 14:00~15:00 直播内容: Elasticsearch 冷热架构可以帮助用户以较低硬件成本实现同等规模的数据存储,解决成本支出。 本次直播我们就来好好讨论下 冷热架构那些事儿!
hot-warm_cluster.png
直播方式:  直播链接会在开始前发送到讨论群中。   点击下方网站链接,选择对应 Webinar 注册即可   Webinar 注册链接   
直播时间: 3月23日(本周六) 14:00~15:00 直播内容: Elasticsearch 冷热架构可以帮助用户以较低硬件成本实现同等规模的数据存储,解决成本支出。 本次直播我们就来好好讨论下 冷热架构那些事儿!
hot-warm_cluster.png
直播方式:  直播链接会在开始前发送到讨论群中。   点击下方网站链接,选择对应 Webinar 注册即可   Webinar 注册链接   

ElasticTalk #4 ILM 索引生命周期管理直播回放

资料分享rockybean 发表了文章 • 0 个评论 • 173 次浏览 • 2019-03-17 15:19 • 来自相关话题

第4期 ElasticTalk 直播已经结束,我们主要讨论了 Elasticsearch 6.6 新增的 Index Lifecycle Management 功能,感兴趣的同学可去如下网址观看回放。   ElasticTalk #4 ILM   ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下: 1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能 2.锻炼参与者的选题、语言表达及沟通能力   目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。   如果你对这个项目感兴趣,欢迎联系我!    
第4期 ElasticTalk 直播已经结束,我们主要讨论了 Elasticsearch 6.6 新增的 Index Lifecycle Management 功能,感兴趣的同学可去如下网址观看回放。   ElasticTalk #4 ILM   ElasticTalk 是一个社区的 Webinar 活动,也欢迎感兴趣的伙伴加入,我们的目标如下: 1.研讨 Elastic Stack 的新功能、原理等,使更多的人以更直接的方式掌握其功能 2.锻炼参与者的选题、语言表达及沟通能力   目前是计划每周六下午 2:00 举行一场,形式主要以在线直播为主。   如果你对这个项目感兴趣,欢迎联系我!    

【ElasticTalk 直播来袭】Elasticsearch 6.6 之 Index Lifecycle Management Practice

资料分享rockybean 发表了文章 • 0 个评论 • 221 次浏览 • 2019-03-14 17:41 • 来自相关话题

直播时间: 3月16日(本周六) 14:00~15:00 直播内容: Elastic Stack 已经更新到 6.6 版本,该版本带来很多新功能,比如:
  • Index Lifecycle Management
  • Frozen Index
  • Geoshape based on Bkd Tree
  • SQL adds support for Date histograms
  • ......
在这些众多功能中,Index Lifecycle Management(索引生命周期管理,后文简称 ILM) 是最受社区欢迎的功能,我们此次研讨会将聚焦该功能,为大家讲解关于 ILM 的概念、原理及实践。
ilm_summary.png
直播方式: 待定(B站或者斗鱼) 直播链接会在开始前发送到讨论群中。 点击我报名吧!

【最新】Elasticsearch 6.6 Index Lifecycle Management 尝鲜

资讯动态rockybean 发表了文章 • 2 个评论 • 1749 次浏览 • 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

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 界面来设置这些策略,如下所示:

kibana ilm

从上图看下来 ILM 的设置是不是一目了然呢?

当然,ILM 是有自己的 api 的,比如上面图片对应的 api 请求如下:

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 请求如下:

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

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

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 如下:

PUT nginx_logs-000001
{
  "aliases": {
    "nginx_logs": {
      "is_write_index":true
    }
  }
}

此时索引分布如下所示:

修改 ILM Polling Interval

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

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

开始吧

一切准备就绪,我们开始吧!

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

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

之后 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

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

参考资料:

  1. https://www.elastic.co/guide/en/elasticsearch/reference/6.6/index-lifecycle-management.html
  2. https://www.elastic.co/blog/hot-warm-architecture-in-elasticsearch-5-x

ET007 ElasticStack 6.5 介绍

ElasticsearchLeon J 发表了文章 • 1 个评论 • 1178 次浏览 • 2018-11-19 09:18 • 来自相关话题

就在 11月14日,ElasticStack 6.5.0 发布了,此次发布带来了许多激动人心的特性,我们一起来体验一下:

WX20181118-120551@2x

如果没有任何数据,kibana会提示我们导入sample数据,这边我选择Try our sample data, 然后导入全部3个样例数据,这可以让我们在没有数据的情况下快速体验新特性。

Infrastructure & Logs UI

很多用户使用 ElasticStack 收集基础架构的日志和指标,比如系统日志、安全日志、CPU指标,内存指标等等。在6.5中,kibana 侧边栏中增加了 Infrastructure 和 Logs 两个新的 tab,让用户更简单地查看自己的基础架构,和每台主机或者容器里的日志。

logs

进入logs标签页,如果当前没有数据,kibana会引导我们添加数据

WX20181118-121032@2x

我们选择 system logs

WX20181118-121047@2x

根据指示,我们安装部署好filebeat并启动,再次进入 logs 标签页便可以看到收集到的系统日志了

image-20181118185158451

  1. 搜索过滤框:在这里可以像在 discover 里一样写query string,并且会有输入提示
  2. 时间选择框:可以选择需要查看的时间点,如果点了 Stream live,会持续监听尾部新输出的日志内容,类似 linux 命令中的tail -f
  3. 日志时间轴:高亮的部位是当前查看日志所在的时间范围,对应的区域图标识了日志量

假如我想实现 tail -f /var/log/system.log | grep google.com 一样的效果,可以打开 Stream live,并在搜索过滤框中这样输入:

WX20181118-173432@2x

很简单,很方便有木有?

Infrastructure

同样在kibana的引导下安装 Metric beat,并开启system模块,启动后进入 infrastructure 标签页:

image-20181118190614385

这里可以直观地看到所有基础架构的指标状况,深色的内层代表主机,颜色代表了健康状况。浅灰色的外层代表了group,因为我只在自己的笔记本上做了部署,所以只能看到一个host。

image-20181118191527060

点击主机会弹出菜单

  • View logs : 跳转到 logs 标签页,并通过搜索过滤框指定host,只查看这台主机的日志。
  • View metrics : 跳转到这台主机的指标详情,可以查看历史数据 shoot

APM

Java 和 Go

不负众望,继 Nodejs、Python、Ruby、Javascript 之后,Elastic APM 5.6.0 新增了对 Java 和 Golang 的支持!

Distributed Tracing

在 SOA 和 MSA 大行其道的年代,如何追踪请求在各个系统之间的流动成为了apm的关键问题。

Elastic APM 支持 OpenTracing 标准,并在各个agent里内置了 OpenTracing 兼容的bridge

以下是官网上该特性的截图:

distributed_tracing

APM Server 监控

如 ElasticStack的其他产品一般,APM也支持了监控,并可以在 Kinbana Montoring下查看监控信息:

apm_monitoring

APM Server 内存占用优化

通过新的基于NDJSON的协议,agent可以在采集信息后通过事件流立即发往APM server,这样 APM Server可以一个接一个地处理接收到的事件,而不是一次性地收到一大块(chunk),这样在很大程度上减少了APM Server的内存占用。

Elasticsearch

Cross-cluster replication

这里的副本并非我们平时常见的分片副本,而是通过在集群B配置一个副本indexB来追随集群A中的indexA,indexA中发生的任何变化都会同步到indexB中来。另外也可以配置一个pattern,当集群A出现符合pattern的索引,自动在集群B创建他的副本,这听起来很酷。值得一提的是,这将是白金版里新增的一个特性。

Minimal Snapshots

snapshot 是 es 中用来创建索引副本的特性,在之前的版本中,snapshot会把完整的 index 都保存下来,包括原始数据和索引数据等等。新的 Minimal Snapshots 提供了一种只备份 _source 内容和 index metadata,当需要恢复时,需要通过 reindex 操作来完成。最小快照最多可能帮你节省50%的磁盘占用,但是会花费更多的时间来恢复。这个特性可能并不适合所有人,但给恢复窗口比较长,且磁盘容量有限的用户多了一种选择。

SQL / ODBC

现在可以使用 支持 ODBC 的第三方工具来连接 elasticsearch 了!我想可以找时间试试用 tableau 直连 elasticsearch会是啥效果。

Java 11

Java11 是一个 LTS 版本,相信会有越来越多的用户升级到 java11

G1GC支持

经过无数的测试,Elasticsearch官方宣布了在 JDK 10+ 上支持 G1GC。G1GC 相比 CMS有诸多优势,如今可以放心地使用G1GC了。(期待对ZGC的支持!)

Authorization realm

X-Pack Security中的新特性,可以对用户认证和用户授权分别配置 realm,比如使用内置的用户体系来认证,再去ldap中获取用户的角色、权限等信息。这也是白金版新增的特性。

机器学习的新特性

  • 支持在同一个机器学习任务中分析多个时间系列
  • 为机器学习任务添加了新的多分桶(multi-bucket) 分析

Kibana

Canvas

Canvas ! 我在做数据分析师的同学看到之后说太酷了,像 PPT。

点击侧边栏的 canvas 标签,可以看到我们先前导入的样本数据也包含了 canvas 样例:

WX20181118-210126@2x

在 11月的 深圳开发者大会上,上海普翔 也用 canvas 对填写调查问卷的参会人员做了分析:

UNADJUSTEDNONRAW_thumb_1adc

https://github.com/alexfrancoeur/kibana_canvas_examples 这里有很多非常不错的 canvas 样例供大家学习,把json文件直接拖到 canvas 页面就可以导入学习了!

Spaces

把 kibana 对象(比如 visualizations、dashboards)组织到独立的 space 里,并且通过 RBAC 来控制哪些用户可以访问哪些 space。这实在是太棒了,想象在一个企业里,多个部门通过kibana查询、分析数据,大家关注的dashboard肯定是不一样的,在6.5之前,我们只能通过社区插件来实现这样的需求,而大版本的升级可能直接导致插件不可用,有了 Space,我们不必再担心!

image-20181118212404768

Rollups UI

Rollup 是 es6.4 中新增的一个特性,用来把一些历史数据压缩归档,用作以后的分析。6.5.0 中 kibana 增加了一个界面用来查看和管理 Rollup 任务。

image9

Data visualizer for files

通过可视化的方式查看文件的结构,查看其中出现最频繁的内容:

highlights_6_5_viz-logs

Beats

Beats Central Management

Beats 终于也支持中心化配置管理了!我们只需按照往常一样安装filebeat、metricbeat,然后使用 filebeat enroll <kibana-url> <token>,便可以通过kibana来管理beats的配置、甚至给他们打上tag:

Image from iOS

想一想,假如我们在上千台机器上部署filebeat,如果哪天需要批量变更配置文件,只需要通过脚本调用配置管理的API就可以了

Functionbeat

Functionbeat是一种新的beat类型,可以被部署为一个方法,而不需要跑在服务器环境上,比如 AWS Lambda function。

以上就是 6.5.0 版本的主要特性,更详细的内容可以查看 https://www.elastic.co/blog/elastic-stack-6-5-0-released ,希望通过我的介绍,可以让大家了解到新版本所带来的激动人心的特性。

Image from iOS

你看懂 Elasticsearch Log 中的 GC 日志了吗?

Elasticsearchrockybean 发表了文章 • 0 个评论 • 1148 次浏览 • 2018-09-22 23:29 • 来自相关话题

如果你关注过 elasticsearch 的日志,可能会看到如下类似的内容:

[2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent [2.2s] collecting in the last [2.3s]

[2018-06-30T17:57:29,020][INFO ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][old][228385][160772] duration [5s], collections [1]/[5.1s], total [5s]/[4.4d], memory [945.4mb]->[958.5mb]/[1007.3mb], all_pools {[young] [87.8mb]->[100.9mb]/[133.1mb]}{[survivor] [0b]->[0b]/[16.6mb]}{[old] [857.6mb]->[857.6mb]/[857.6mb]}

看到其中的[gc]关键词你也猜到了这是与 GC 相关的日志,那么你了解每一部分的含义吗?如果不了解,你可以继续往下看了。

我们先从最简单的看起:

  1. 第一部分是日志发生的时间
  2. 第二部分是日志级别,这里分别是WARNINFO
  3. 第三部分是输出日志的类,我们后面也会讲到这个类
  4. 第四部分是当前 ES 节点名称
  5. 第五部分是 gc 关键词,我们就从这个关键词聊起。

友情提示:对 GC 已经了如指掌的同学,可以直接翻到最后看答案。

1. 什么是 GC?

GC,全称是 Garbage Collection (垃圾收集)或者 Garbage Collector(垃圾收集器)。

在使用 C语言编程的时候,我们要手动的通过 mallocfree来申请和释放数据需要的内存,如果忘记释放内存,就会发生内存泄露的情况,即无用的数据占用了宝贵的内存资源。而Java 语言编程不需要显示的申请和释放内存,因为 JVM 可以自动管理内存,这其中最重要的一部分就是 GC,即 JVM 可以自主地去释放无用数据(垃圾)占用的内存。

我们研究 GC 的主要原因是 GC 的过程会有 Stop The World(STW)的情况发生,即此时用户线程会停止工作,如果 STW 的时间过长,则应用的可用性、实时性等就下降的很厉害。

GC主要解决如下3个问题:

  1. 如何找到垃圾?
  2. 如何回收垃圾?
  3. 何时回收垃圾?

我们一个个来看下。

1.1 如何找到垃圾?

所谓垃圾,指的是不再被使用(引用)的对象。Java 的对象都是在堆(Heap)上创建的,我们这里默认也只讨论堆。那么现在问题就变为如何判定一个对象是否还有被引用,思路主要有如下两种:

  1. 引用计数法,即在对象被引用时加1,去除引用时减1,如果引用值为0,即表明该对象可回收了。
  2. 可达性分析法,即通过遍历已知的存活对象(GC Roots)的引用链来标记出所有存活对象

方法1简单粗暴效率高,但准确度不行,尤其是面对互相引用的垃圾对象时无能为力。

方法2是目前常用的方法,这里有一个关键是 GC Roots,它是判定的源头,感兴趣的同学可以自己去研究下,这里就不展开讲了。

1.2 如何回收垃圾?

垃圾找到了,该怎么回收呢?看起来似乎是个很傻的问题。直接收起来扔掉不就好了?!对应到程序的操作,就是直接将这些对象占用的空间标记为空闲不就好了吗?那我们就来看一下这个基础的回收算法:标记-清除(Mark-Sweep)算法。

1.2.1 标记-清除 算法(Mark Sweep)

该算法很简单,使用通过可达性分析分析方法标记出垃圾,然后直接回收掉垃圾区域。它的一个显著问题是一段时间后,内存会出现大量碎片,导致虽然碎片总和很大,但无法满足一个大对象的内存申请,从而导致 OOM,而过多的内存碎片(需要类似链表的数据结构维护),也会导致标记和清除的操作成本高,效率低下,如下图所示:

1.2.2 复制算法(Copying)

为了解决上面算法的效率问题,有人提出了复制算法。它将可用内存一分为二,每次只用一块,当这一块内存不够用时,便触发 GC,将当前存活对象复制(Copy)到另一块上,以此往复。这种算法高效的原因在于分配内存时只需要将指针后移,不需要维护链表等。但它最大的问题是对内存的浪费,使用率只有 50%。

但这种算法在一种情况下会很高效:Java 对象的存活时间极短。据 IBM 研究,Java 对象高达 98% 是朝生夕死的,这也意味着每次 GC 可以回收大部分的内存,需要复制的数据量也很小,这样它的执行效率就会很高。

1.2.3 标记-整理算法(Mark Compact)

该算法解决了第1中算法的内存碎片问题,它会在回收阶段将所有内存做整理,如下图所示:

但它的问题也在于增加了整理阶段,也就增加了 GC 的时间。

1.2.4 分代收集算法(Generation Collection)

既然大部分 Java 对象是朝生夕死的,那么我们将内存按照 Java 生存时间分为 新生代(Young)老年代(Old),前者存放短命僧,后者存放长寿佛,当然长寿佛也是由短命僧升级上来的。然后针对两者可以采用不同的回收算法,比如对于新生代采用复制算法会比较高效,而对老年代可以采用标记-清除或者标记-整理算法。这种算法也是最常用的。JVM Heap 分代后的划分一般如下所示,新生代一般会分为 Eden、Survivor0、Survivor1区,便于使用复制算法。

将内存分代后的 GC 过程一般类似下图所示:

  1. 对象一般都是先在 Eden区创建
  2. Eden区满,触发 Young GC,此时将 Eden中还存活的对象复制到 S0中,并清空 Eden区后继续为新的对象分配内存
  3. Eden区再次满后,触发又一次的 Young GC,此时会将 EdenS0中存活的对象复制到 S1中,然后清空EdenS0后继续为新的对象分配内存
  4. 每经过一次 Young GC,存活下来的对象都会将自己存活次数加1,当达到一定次数后,会随着一次 Young GC 晋升到 Old
  5. Old区也会在合适的时机进行自己的 GC

1.2.5 常见的垃圾收集器

前面我们讲了众多的垃圾收集算法,那么其具体的实现就是垃圾收集器,也是我们实际使用中会具体用到的。现代的垃圾收集机制基本都是分代收集算法,而 YoungOld区分别有不同的垃圾收集器,简单总结如下图:

从上图我们可以看到 YoungOld区有不同的垃圾收集器,实际使用时会搭配使用,也就是上图中两两连线的收集器是可以搭配使用的。这些垃圾收集器按照运行原理大概可以分为如下几类:

  • Serial GC串行,单线程的收集器,运行 GC 时需要停止所有的用户线程,且只有一个 GC 线程
  • Parallel GC并行,多线程的收集器,是 Serial 的多线程版,运行时也需要停止所有用户线程,但同时运行多个 GC 线程,所以效率高一些
  • Concurrent GC并发,多线程收集器,GC 分多阶段执行,部分阶段允许用户线程与 GC 线程同时运行,这也就是并发的意思,大家要和并行做一个区分。
  • 其他

我们下面简单看一下他们的运行机制。

1.2.5.1 Serial GC

该类 Young区的为 Serial GCOld区的为Serial Old GC。执行大致如下所示:

1.2.5.2 Parallel GC

该类Young 区的有 ParNewParallel ScavengeOld 区的有Parallel Old。其运行机制如下,相比 Serial GC ,其最大特点在于 GC 线程是并行的,效率高很多:

1.2.5.3 Concurrent Mark-Sweep GC

该类目前只是针对 Old 区,最常见就是CMS GC,它的执行分为多个阶段,只有部分阶段需要停止用户进程,这里不详细介绍了,感兴趣可以去找相关文章来看,大体执行如下:

1.2.5.4 其他

目前最新的 GC 有G1GCZGC,其运行机制与上述均不相同,虽然他们也是分代收集算法,但会把 Heap 分成多个 region 来做处理,这里不展开讲,感兴趣的可以参看最后参考资料的内容。

1.2.6 Elasticsearch 的 GC 组合

Elasticsearch 默认的 GC 配置是CMS GC ,其 Young 区ParNewOld 区CMS,大家可以在 config/jvm.options中看到如下的配置:

## GC configuration
-XX:+UseConcMarkSweepGC
-XX:CMSInitiatingOccupancyFraction=75
-XX:+UseCMSInitiatingOccupancyOnly

1.3 何时进行回收?

现在我们已经知道如何找到和回收垃圾了,那么什么时候回收呢?简单总结如下:

  1. Young 区的GC 都是在 Eden 区满时触发
  2. Serial Old 和 Parallel Old 在 Old 区是在 Young GC 时预测Old 区是否可以为 young 区 promote 到 old 区 的 object 分配空间,如果不可用则触发 Old GC。这个也可以理解为是 Old区满时。
  3. CMS GC 是在 Old 区大小超过一定比例后触发,而不是 Old 区满。这个原因在于 CMS GC 是并发的算法,也就是说在 GC 线程收集垃圾的时候,用户线程也在运行,因此需要预留一些 Heap 空间给用户线程使用,防止由于无法分配空间而导致 Full GC 发生。

2. GC Log 如何阅读?

前面讲了这么多,终于可以回到开篇的问题了,我们直接来看答案

[2018-06-30T17:57:23,848][WARN ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][228384] overhead, spent [2.2s] collecting in the last [2.3s]

[gc][这是第228384次GC 检查] 在最近 2.3 s 内花了 2.2s 用来做垃圾收集,这占比似乎有些过了,请抓紧来关注下。

[2018-06-30T17:57:29,020][INFO ][o.e.m.j.JvmGcMonitorService] [qoo--eS] [gc][old][228385][160772] duration [5s], collections [1]/[5.1s], total [5s]/[4.4d], memory [945.4mb]->[958.5mb]/[1007.3mb], all_pools {[young] [87.8mb]->[100.9mb]/[133.1mb]}{[survivor] [0b]->[0b]/[16.6mb]}{[old] [857.6mb]->[857.6mb]/[857.6mb]}

我们直接来看具体的含义好了,相信有了前面的 GC 基础知识,大家在看这里解释的时候就非常清楚了。

  • [gc][本次是 old GC][这是第228385次 GC 检查][从 JVM 启动至今发生的第 160772次 GC]

  • duration [本次检查到的 GC 总耗时 5 秒,可能是多次的加和],

  • collections [从上次检查至今总共发生1次 GC]/[从上次检查至今已过去 5.1 秒],

  • total [本次检查到的 GC 总耗时为 5 秒]/[从 JVM 启动至今发生的 GC 总耗时为 4.4 天],

  • memory [ GC 前 Heap memory 空间]->[GC 后 Heap memory 空间]/[Heap memory 总空间],

  • all_pools(分代部分的详情) {[young 区][GC 前 Memory ]->[GC后 Memory]/[young区 Memory 总大小] } {[survivor 区][GC 前 Memory ]->[GC后 Memory]/[survivor区 Memory 总大小] }{[old 区][GC 前 Memory ]->[GC后 Memory]/[old区 Memory 总大小] }

3. 看看源码

从日志中我们可以看到输出这些日志的类名叫做JvmGcMonitorService,我们去源码中搜索很快会找到它/Users/rockybean/code/elasticsearch/core/src/main/java/org/elasticsearch/monitor/jvm/JvmGcMonitorService.java,这里就不详细展开讲解源码了,它执行的内容大概如下图所示:

关于打印日志的格式在源码也有,如下所示:

private static final String SLOW_GC_LOG_MESSAGE =
"[gc][{}][{}][{}] duration [{}], collections [{}]/[{}], total [{}]/[{}], memory [{}]->[{}]/[{}], all_pools {}";
private static final String OVERHEAD_LOG_MESSAGE = "[gc][{}] overhead, spent [{}] collecting in the last [{}]";

另外细心的同学会发现输出的日志中 gc 只分了 young 和 old ,原因在于 ES 对 GC Name 做了封装,封装的类为:org.elasticsearch.monitor.jvm.GCNames,相关代码如下:

    public static String getByMemoryPoolName(String poolName, String defaultName) {
        if ("Eden Space".equals(poolName) || "PS Eden Space".equals(poolName) || "Par Eden Space".equals(poolName) || "G1 Eden Space".equals(poolName)) {
            return YOUNG;
        }
        if ("Survivor Space".equals(poolName) || "PS Survivor Space".equals(poolName) || "Par Survivor Space".equals(poolName) || "G1 Survivor Space".equals(poolName)) {
            return SURVIVOR;
        }
        if ("Tenured Gen".equals(poolName) || "PS Old Gen".equals(poolName) || "CMS Old Gen".equals(poolName) || "G1 Old Gen".equals(poolName)) {
            return OLD;
        }
        return defaultName;
    }

    public static String getByGcName(String gcName, String defaultName) {
        if ("Copy".equals(gcName) || "PS Scavenge".equals(gcName) || "ParNew".equals(gcName) || "G1 Young Generation".equals(gcName)) {
            return YOUNG;
        }
        if ("MarkSweepCompact".equals(gcName) || "PS MarkSweep".equals(gcName) || "ConcurrentMarkSweep".equals(gcName) || "G1 Old Generation".equals(gcName)) {
            return OLD;
        }
        return defaultName;
    }

在上面的代码中,你会看到很多我们在上一节中提到的 GC 算法的名称。

至此,源码相关部分也讲解完毕,感兴趣的大家可以自行去查阅。

4. 总结

讲解 GC 的文章已经很多,本文又唠唠叨叨地讲一遍基础知识,是希望对于第一次了解 GC 的同学有所帮助。因为只有了解了这些基础知识,你才不至于被这些 GC 的输出吓懵。希望本文对你理解 ES 的 GC 日志 有所帮助。

5. 参考资料

  1. Java Hotspot G1 GC的一些关键技术(https://mp.weixin.qq.com/s/4ufdCXCwO56WAJnzng_-ow
  2. Understanding Java Garbage Collection(https://www.cubrid.org/blog/understanding-java-garbage-collection
  3. 《深入理解Java虚拟机:JVM高级特性与最佳实践》

6. 相关推荐

如果你想深入的了解 JAVA GC 的知识,可以关注 ElasticTalk 公众号,回复 GC关键词后即可获取作者推荐的电子书等资料。

elasticTalk,qrcode

通过 metadata 使logstash配置更简洁

LogstashLeon J 发表了文章 • 0 个评论 • 1120 次浏览 • 2018-09-04 13:17 • 来自相关话题

从Logstash 1.5开始,我们可以在logstash配置中使用metadata。metadata不会在output中被序列化输出,这样我们便可以在metadata中添加一些临时的中间数据,而不需要去删除它。

我们可以通过以下方式来访问metadata:

[@metadata][foo]

用例

假设我们有这样一条日志:

[2017-04-01 22:21:21] production.INFO: this is a test log message by leon

我们可以在filter中使用grok来做解析:

grok {
      match => { "message" => "\[%{TIMESTAMP_ISO8601:timestamp}\] %{DATA:env}\.%{DATA:log_level}: %{DATA:content}" }
    }

解析的结果为

{
      "env" => "production",
      "timestamp" => "2017-04-01 22:21:21",
      "log_level" => "INFO",
      "content" => "{\"message\":\"[2017-04-01 22:21:21] production.INFO: this is a test log message by leon\"}"
}

假设我们希望

  1. 能把log_level为INFO的日志丢弃掉,但又不想让该字段出现在最终的输出中
  2. 输出的索引名中能体现出env,但也不想让该字段出现在输出结果里

对于1,一种方案是在输出之前通过mutate插件把不需要的字段删除掉,但是一旦这样的处理多了,会让配置文件变得“不干净”。

通过 metadata,我们可以轻松地处理这些问题:

grok {
    match => { "message" => "\[%{TIMESTAMP_ISO8601:timestamp}\] %{DATA:[@metadata][env]}\.%{DATA:[@metadata][log_level]}: %{DATA:content}" }
}

if [@metadata][log_level] == "INFO"{
    drop{}    
}

output{
    elasticsearch {
        hosts => ["127.0.0.1:9200"]
        index => "%{[@metadata][env]}-log-%{+YYYY.MM}"
        document_type => "_doc"
    }
}

除了简化我们的配置文件、减少冗余字段意外,同时也能提高logstash的处理速度。

Elasticsearch input插件

有些插件会用到metadata这个特性,比如elasticsearch input插件:

input {
  elasticsearch {
    host => "127.0.0.1"
    # 把 ES document metadata (_index, _type, _id) 包存到 @metadata 中
    docinfo_in_metadata => true
  }
}

filter{
    ......
}

output {
  elasticsearch {
    document_id => "%{[@metadata][_id]}"
    index => "transformed-%{[@metadata][_index]}"
    type => "%{[@metadata][_type]}"
  }
}

调试

一般来说metadata是不会出现在输出中的,除非使用 rubydebug codec 的方式输出:

output { 
  stdout { 
    codec  => rubydebug {
      metadata => true
    }
  }
}

日志经过处理后输出中会包含:

{
    ....,
    "@metadata" => {
        "env" => "production",
        "log_level" => "INFO"
    }
}

总结

由上可见,metadata提供了一种简单、方便的方式来保存中间数据。这样一方面减少了logstash配置文件的复杂性:避免调用remove_field,另一方面也减少了输出中的一些不必要的数据。通过这篇对metadata的介绍,希望能对大家有所帮助。

elasticTalk,qrcode