杭州网站开发企业,wordpress oss压缩,网站开发公司的销售方式,适用的深圳网站定制开发官网文档#xff1a;ILM: Manage the index lifecycle | Elasticsearch Guide [7.12] | Elastic
ILM#xff1a;管理 index 的生命周期
可以根据你的性能、弹性、保存时长需求#xff0c;使用ILM策略来自动管理你的index#xff1b;比如
1. 当一个index达到确定的大小ILM: Manage the index lifecycle | Elasticsearch Guide [7.12] | Elastic
ILM管理 index 的生命周期
可以根据你的性能、弹性、保存时长需求使用ILM策略来自动管理你的index比如
1. 当一个index达到确定的大小或者一定数量的documents的时候启动一个新索引
2. 按照每天、每周、每月创建新index并归档之前的index
3. 删除过期index来执行数据保留标准
可以通过kibana 管理界面或者ILM 的API来创建和配置ILM策略当你给Beats或Logstash Elasticsearch的输出插件启用了ILM默认的策略会自动配置
自动备份你的index和管理你的snapshots使用snapshot lifecycle policies ILM 可以触发哪些动作
Rollover当当前index达到确定的大小确定数量的docsdocument或者期限创建一个新的index
Shrink减少索引中主分片的数量
Force merge手动触发发一个merge 来减少index shards 中的segments数量
Freeze 使index 制度并且最小化内存占用
Delete永久删除一个index包括元数据metadata和数据data
ILM 使管理在hot-warm-cold架构中的索引变得简单当你处理日志和指标metrics)等时间序列数据是这很常见
你可以指定 1. 你想要滚动到新索引的最大分片大小、文档数量或期限 2. 不再更小索引并可以减少主分片数量的点 3. 何时强制合并并永久删除标记为删除的文档 4. 可以将索引移至性能较低的硬件的点 5. 可用性不那么重要并且可以减少副本数量的点 6. 何时index 可以被安全删除
举个例子如果您要将 ATM 机群中的指标数据索引到 Elasticsearch 中您可以定义一个策略 1. 当index 的主分片大小达到50GBroll over滚动到一个新索引 2. 将旧的index移动到warm 阶段phase标记制度并且将其缩小为单个shard 3. 7天后移动到cold阶段phase并且移动到更便宜less expensive的硬件上 4. 达到要求的30天保留期后删除索引
使用ILM的注意事项使用ILM一个集群中的所有节点都必须运行相同的版本version),隋岩可能会在混合的版本中创建和应用策略但是不保证按照预期执行。尝试使用非所有节点都支持的的策略可能会导致错误
ILM 概念
index 生存周期lifecycle)
ILM 定义了五个index生存周期阶段phases
Hot该索引正在积极的更新和查询
Warm该索引不再被更新但是仍然被查询
Cold该索引不再更新查询也不再频繁信息仍然需要可搜索但如果这些查询速度较慢也没关系
Frozen该索引不再被更新很少查询信息仍然需要被搜索但如果这些查询速度特别慢也没关系
Delete该索引不再被需要并可以被安全删除
一个index 生存周期管理策略指定了哪些阶段适用在每个阶段什么动作被执行以及何时在阶段之间转换。
你可以在你创建一个index 的时候手动应用一个lLM策略对于时间序列索引你需要关联ILM策略到用于创建新的时序index的index template。当一个index 滚动roll over创建一个手动应用的策略不会自动应用到新的index。
如果你使用Elasticsearch安全特性ILM以上次更新策略的用户身份执行操作ILM 仅具有上次策略更新时分配给用户的角色权限
阶段转换Phase transitions
ILM通过他们的存在期限来移动index为了控制他们的转换时间你可以为每个阶段设置一个最小期限minimum age对于一个移动到下一阶段的index所有在当前阶段的action动作必须完成并且索引必须早于下一阶段的最小期限minimum age
默认最小期限minimum age默认是0 这会导致ILM在当前阶段的所有操作完成后立即将索引移动到下一阶段
如果一个index 存在未分配unallocated分片shard或者集群状态cluster health status是yellowindex仍能够根据ILM策略转换到下一个节点。然而因为Elasticsearch只能在Green的状态下才能执行确认的清理任务这可能造成想不到的副作用side effects
避免增加磁盘使用率和可靠性问题及时in timely fashion)定位所有集群健康问题
阶段执行Phase execution
ILM控制阶段中操作的执行顺序以及执行哪些步骤来执行每个所需的索引操作。
当一个index 进入一个阶段phaseILM 在index 的元数据metadata中缓存这个阶段phase定义。这样确保策略更新不会使索引陷入到永远无法退出阶段的状态如果修改changes能够被安全的应用ILM更新缓存的阶段定义如果他们不能阶段执行继续使用缓存的定义。
ILM周期性运行检查是否有index 满足策略标准criteria并执行所需的任何步骤。避免竞争race条件ILM可能需要运行多次才能执行完成操作所需的所有步骤。例如如果ILM确定一个索引已经满足了rollover滚动更新标准criteria),ILM开始执行完成rollover滚动更新所需的所有步骤如果达到无法安全进入下一步的程度则执行停止下一次ILM运行时ILM将从中断处继续运行。这意味着即使indices.lifecycle.poll_interval 是设置的是10分钟并且一个index满足rollover滚动更新criteria标准可能会花费20分钟来完成rollover
阶段动作Phase actions
在每个阶段ILM支持的动作action如下
Hot Set Priority Unfollow Rollover Read-Only Shrink Force Merge
Warm Set Priority Unfollow Read-Only Allocate Migrate Shrink Force Merge
Cold Set Priority Unfollow Allocate Freeze Searchable Snapshot
Frozen Searchable Snapshot
Delete Wait for Snapshot Delete
Rollover(滚动更新
当你索引indexing像日志log或者指标metrics你不可能无限期indefinitely写入到一个单独的index中。为了满足你的indexing和查询性能要求以及管理资源使用率当你写入的index达到一个阈值的时候创建一个新的index并开始往新的index 中写入。使用滚动创建indices是你能够做
优化活动索引以实现高效能hot节点上的高摄取率ingest rates优化warm节点上的搜索性能将旧的访问频率较低的数据转移shift)到成本较低的cold节点通过删除整个索引根据你的保留策略删除数据
我们推荐你使用data streams 来管理时序数据。Data streams自动跟踪写入索引同时将配置保持在最低限度
每个data streams要求一个index template包括
数据流的名称或通配符*模式wildcard pattern数据流时间戳字段这个字段必须映射为date或者date_nanos字段数据类型并且必须包含在index到data stream的每个文档中创建每个支持backingindex的映射mapping和设置setting
Data streams专为附加数据append-only而设计其中data stream 名称可用作读、写、滚动更新rollover、收缩shrink 等目标如果你的用例需要就地更新数据你可以使用索引别名index aliases来管理时序数据然而这里有一些额外的配置步骤和概念
索引模版指定时序中每个新索引的配置你可以优化此配置以进行摄取ingest通常使用与hot节点数量一样多的分片。引用整个索引集的索引别名指定为写索引的单个索引这是处理所有写入请求的活动index每次rollover是新索引将会成为写入索引
自动滚动更新Automatic rollover
ILM使你能够基于index 大小document数量保存时间age自动滚动更新automatic rollover当一个rollover 被触发一个新的index 被创建一个写别名write alias被更新执行新索引索引后续的更新被写入到新的index
TIP根据大小、文档计数或期限age滚动到新索引比基于时间的滚动更可取。在任意时间arbitrary timerollover通常会产生许多小索引这可能会对性能和资源使用产生负面影响。
Policy updates策略更新
你可以通过修改当前策略或切换到不同的策略来更改索引或滚动索引集合的生命周期的管理方式。
为了确保策略更新不会将索引置于无法退出当前阶段的状态阶段定义在进入该阶段时会缓存在索引元数据中。如果可以安全地应用更改ILM 会更新缓存的阶段定义。如果不能阶段执行将继续使用缓存的定义。
当索引前进到下一阶段时它使用更新策略中的阶段定义
如何应用修改How changes are applied
当策略最初应用于索引时索引获取最新版本的策略如果更新策略策略版本会发生变化bumped并且 ILM 可以检测到索引正在使用需要更新的早期版本。
对 min_age 的更改不会传播到缓存的定义。更改阶段的 min_age 不会影响当前正在执行该阶段的索引
例如如果您创建的策略具有未指定 min_age 的热阶段则应用该策略时索引会立即进入热阶段。如果您随后更新策略以将热阶段的 min_age 指定为 1 天则这对已处于热阶段的索引没有影响。策略更新后创建的index要到一天后才会进入热门阶段 。
如何应用新策略How new policies are applied
当您将不同的策略应用于托管索引时索引将使用先前策略中的缓存定义来完成当前阶段。该指数在进入下一阶段时开始使用新政策。
