数据流生命周期
edit数据流生命周期
edit数据流生命周期是数据流用于管理其生命周期的内置机制。它使您能够根据保留要求轻松自动化数据流的管理。例如,您可以配置生命周期以:
- 确保数据流中索引的数据将至少保留您定义的保留时间。
- 确保早于保留期的数据将由Elasticsearch在稍后时间自动删除。
为了实现这一点,它支持:
数据流生命周期还支持对数据流支持索引进行降采样。 有关更多详细信息,请参阅降采样示例。
它是如何工作的?
edit在由 data_streams.lifecycle.poll_interval 配置的时间间隔内,Elasticsearch 会遍历每个数据流并执行以下步骤:
- 检查数据流是否配置了数据流生命周期,跳过任何不属于托管数据流的索引。
-
如果数据流的写索引满足由
cluster.lifecycle.default.rollover定义的条件,则对其进行翻转。 - 在一个索引不再是写索引之后(即数据流已被翻转),自动进行尾部合并。数据流生命周期执行一个合并操作,该操作仅针对小段的长尾,而不是整个分片。由于段被组织成指数级大小的层级,合并小段的长尾只是强制合并到一个段的成本的一小部分。小段通常包含最近的数据,因此尾部合并将集中合并资源在最有价值的数据上,这些数据最有可能被继续查询。
- 如果配置了降采样,它将执行所有配置的降采样轮次。
-
对剩余的后备索引应用保留策略。这意味着删除那些
generation_time超过有效保留期的后备索引(阅读更多关于有效保留计算的信息)。generation_time仅适用于翻转后的后备索引,并且它要么是后备索引翻转后的时间,要么是在index.lifecycle.origination_date设置中可选配置的时间。
我们使用generation_time而不是创建时间,因为这确保了后备索引中的所有数据都已通过保留期。因此,保留期不是数据被删除的确切时间,而是数据将被存储的最短时间。
步骤 2-4 仅适用于尚未由 ILM 管理的备份索引,这意味着这些索引要么没有定义 ILM 策略,要么如果定义了,它们已将 index.lifecycle.prefer_ilm 设置为 false。
配置数据流生命周期
edit由于生命周期是在数据流级别配置的,因此在新数据流和现有数据流上配置生命周期的过程有所不同。
在以下部分中,我们将浏览以下教程:
- 要创建一个具有生命周期的新的数据流,您需要将数据流生命周期作为索引模板的一部分添加,该模板匹配您的数据流的名称(参见教程:创建具有生命周期的数据流)。当一个带有您的数据流名称的写操作到达Elasticsearch时,数据流将使用相应的数据流生命周期创建。
- 要更新现有数据流的生命周期,您需要使用数据流生命周期API来编辑数据流本身的生命周期(参见教程:更新现有数据流)。
- 使用教程:将ILM管理的数据流迁移到数据流生命周期将现有ILM管理的数据流迁移到数据流生命周期。
更新现有数据流的生命周期与更新设置或映射不同,因为它是在数据流级别应用的,而不是在单个后备索引上应用的。
教程:使用生命周期创建数据流
edit要创建一个具有内置生命周期的数据流,请按照以下步骤操作:
创建索引模板
edit数据流需要一个匹配的索引模板。您可以通过在索引模板中设置lifecycle字段来配置数据流的生命周期,就像您为映射和索引设置所做的那样。您可以定义一个如下所示的索引模板来设置生命周期:
-
包含
data_stream对象以启用数据流。 - 在模板部分定义生命周期,或者包含定义生命周期的可组合模板。
-
使用高于
200的优先级,以避免与内置模板发生冲突。 请参阅避免索引模式冲突。
您可以使用创建索引模板 API。
PUT _index_template/my-index-template
{
"index_patterns": ["my-data-stream*"],
"data_stream": { },
"priority": 500,
"template": {
"lifecycle": {
"data_retention": "7d"
}
},
"_meta": {
"description": "Template with data stream lifecycle"
}
}
创建数据流
edit您可以通过两种方式创建数据流:
-
通过使用创建数据流 API手动创建数据流。数据流的名称必须仍然匹配您的模板中的一个索引模式。
PUT _data_stream/my-data-stream
-
通过针对数据流名称的索引请求来添加文档。此名称必须与您的索引模板中的一个索引模式匹配。
PUT my-data-stream/_bulk { "create":{ } } { "@timestamp": "2099-05-06T16:21:15.000Z", "message": "192.0.2.42 - - [06/May/2099:16:21:15 +0000] \"GET /images/bg.jpg HTTP/1.0\" 200 24736" } { "create":{ } } { "@timestamp": "2099-05-06T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
检索生命周期信息
edit您可以使用获取数据流周期 API来查看您的数据流的周期,以及使用解释数据流周期 API来查看每个后备索引的确切状态。
GET _data_stream/my-data-stream/_lifecycle
结果将如下所示:
{
"data_streams": [
{
"name": "my-data-stream",
"lifecycle": {
"enabled": true,
"data_retention": "7d",
"effective_retention": "7d",
"retention_determined_by": "data_stream_configuration"
}
}
],
"global_retention": {}
}
|
您的数据流的名称。 |
|
|
显示此数据流是否启用了数据流生命周期。 |
|
|
此数据流中索引的数据的保留期,由用户配置。 |
|
|
数据流生命周期将应用的保留期。这意味着此数据流中的数据将至少保留7天。之后,Elasticsearch可以根据自己的判断删除它。 |
如果您想查看有关如何在各个后备索引上应用数据流生命周期的更多信息,请使用 解释数据流生命周期 API:
GET .ds-my-data-stream-*/_lifecycle/explain
结果将如下所示:
教程:更新现有数据流
edit要更新现有数据流的声明周期,您需要执行以下操作:
设置数据流的生命周期
edit要添加或更改数据流的保留期限,您可以使用PUT lifecycle API。
-
您可以设置无限保留期,这意味着您的数据将永远不会被删除。例如:
-
或者您可以设置您选择的保留期。例如:
生命周期的变化应用于数据流的所有后备索引。您可以通过解释API查看更改的效果:
GET .ds-my-data-stream-*/_lifecycle/explain
响应将如下所示:
{
"indices": {
".ds-my-data-stream-2023.04.19-000002": {
"index": ".ds-my-data-stream-2023.04.19-000002",
"managed_by_lifecycle": true,
"index_creation_date_millis": 1681919221417,
"time_since_index_creation": "6.85s",
"lifecycle": {
"enabled": true,
"data_retention": "30d"
}
},
".ds-my-data-stream-2023.04.17-000001": {
"index": ".ds-my-data-stream-2023.04.17-000001",
"managed_by_lifecycle": true,
"index_creation_date_millis": 1681745209501,
"time_since_index_creation": "48d",
"rollover_date_millis": 1681919221419,
"time_since_rollover": "6.84s",
"generation_time": "6.84s",
"lifecycle": {
"enabled": true,
"data_retention": "30d"
}
}
}
}
|
支持索引的名称。 |
|
|
此索引由数据流生命周期管理。 |
|
|
自创建此索引以来已经过去的时间。 |
|
|
该索引的数据保留期至少为30天,因为它最近被更新了。 |
|
|
支持索引的名称。 |
|
|
此索引由内置数据流生命周期管理。 |
|
|
自创建此索引以来已经过去的时间。 |
|
|
自此索引被滚动更新以来所经过的时间。 |
|
|
用于确定何时可以安全删除此索引及其所有数据的时间。 |
|
|
该索引的数据保留期同样至少为30天,因为最近进行了更新。 |
删除数据流的生存周期
edit要移除数据流的声明周期,您可以使用删除生命周期 API。作为结果,生命周期所应用的维护操作将不再应用于数据流及其所有后备索引。例如:
DELETE _data_stream/my-data-stream/_lifecycle
然后,您可以再次使用解释 API来查看索引不再被管理。
GET .ds-my-data-stream-*/_lifecycle/explain
教程:数据流保留
edit在本教程中,我们将详细介绍数据流生命周期保留;我们将定义它,讨论如何配置它以及如何应用它。请记住,以下选项仅适用于由数据流生命周期管理的数据流。
您可以通过获取数据流生命周期API来验证数据流是否由数据流生命周期管理:
GET _data_stream/my-data-stream/_lifecycle
结果应如下所示:
什么是数据流保留?
edit我们将保留定义为数据流的数据在Elasticsearch中保留的最短时间。在此时间过后,Elasticsearch可以删除这些数据以释放空间和/或管理成本。
保留期并不定义数据将被删除的时间段,而是定义它们将被保留的最短时间。
我们定义了4种不同的留存类型:
-
数据流保留,或
data_retention,这是在数据流级别配置的保留。它可以通过索引模板为未来的数据流设置,或通过PUT数据流生命周期API为现有数据流设置。当数据流保留未设置时,这意味着数据需要永久保存。 -
全局默认保留,我们称之为
default_retention,这是一个通过集群设置data_streams.lifecycle.retention.default配置的保留,并将应用于所有未配置data_retention的数据流生命周期管理的数据流。实际上,它确保不会有数据流永久保存其数据。这可以通过更新集群设置API进行设置。 -
全局最大保留,我们称之为
max_retention,这是一个通过集群设置data_streams.lifecycle.retention.max配置的保留,并将应用于所有数据流生命周期管理的数据流。实际上,它确保不会有数据流的保留时间超过此时间段。这可以通过更新集群设置API进行设置。 -
有效保留,或
effective_retention,这是在给定时刻应用于数据流的保留。有效保留无法设置,它是通过考虑上述所有配置的保留并按照此处描述的方式计算得出的。
全局默认和最大保留期不适用于 Elastic 内部的 数据流。内部数据流通过将 system 标志设置为 true 或其名称以点 (.) 为前缀来识别。
如何配置保留策略?
edit-
通过在数据流级别设置
data_retention。此保留可以通过两种方式进行配置:— 对于新的数据流,可以在索引模板中定义,该模板将在数据流创建时应用。 例如,您可以使用创建索引模板 API:
PUT _index_template/template { "index_patterns": ["my-data-stream*"], "data_stream": { }, "priority": 500, "template": { "lifecycle": { "data_retention": "7d" } }, "_meta": { "description": "带有数据流生命周期的模板" } }— 对于现有的数据流,可以通过PUT lifecycle API进行设置。
-
通过在集群级别设置
data_streams.lifecycle.retention.default和/或data_streams.lifecycle.retention.max来设置全局保留。可以通过更新集群设置API进行设置。例如:PUT /_cluster/settings { "persistent" : { "data_streams.lifecycle.retention.default" : "7d", "data_streams.lifecycle.retention.max" : "90d" } }
有效保留率是如何计算的?
edit有效性按以下方式计算:
-
当定义了
default_retention且数据流没有data_retention时,effective_retention是default_retention。 -
当定义了
data_retention且如果定义了max_retention,它小于max_retention时,effective_retention是data_retention。 -
当定义了
max_retention,且数据流没有data_retention或其data_retention大于max_retention时,effective_retention是max_retention。
上述内容在下面的示例中进行了演示:
default_retention |
max_retention |
data_retention |
effective_retention |
Retention determined by |
|---|---|---|---|---|
未设置 |
未设置 |
未设置 |
无限 |
不适用 |
不相关 |
12个月 |
30天 |
30天 |
|
不相关 |
未设置 |
30天 |
30天 |
|
30天 |
12个月 |
未设置 |
30天 |
|
30天 |
30天 |
未设置 |
30天 |
|
不相关 |
30天 |
12个月 |
30天 |
|
未设置 |
30天 |
未设置 |
30天 |
|
考虑到我们的例子,如果我们检索my-data-stream的生命周期:
GET _data_stream/my-data-stream/_lifecycle
我们看到它将与用户配置的内容保持一致:
{
"global_retention" : {
"max_retention" : "90d",
"default_retention" : "7d"
},
"data_streams": [
{
"name": "my-data-stream",
"lifecycle": {
"enabled": true,
"data_retention": "30d",
"effective_retention": "30d",
"retention_determined_by": "data_stream_configuration"
}
}
]
}
|
集群中配置的最大保留时间。 |
|
|
集群中配置的默认保留期。 |
|
|
此数据流的请求保留期。 |
|
|
数据流生命周期对此数据流应用的保留策略。 |
|
|
确定有效保留期的配置。在这种情况下,它是 |
有效保留是如何应用的?
edit保留策略应用于数据流生命周期运行的最后一步,即对数据流的剩余后备索引进行处理。数据流生命周期将检索那些generation_time超过有效保留期的后备索引并删除它们。generation_time仅适用于已滚动更新的后备索引,它要么是后备索引滚动更新后的时间,要么是在index.lifecycle.origination_date设置中可选配置的时间。
我们使用generation_time而不是创建时间,因为这确保了后备索引中的所有数据都已通过保留期。因此,保留期不是数据被删除的确切时间,而是数据将被存储的最短时间。
教程:将ILM管理的数据流迁移到数据流生命周期
edit在本教程中,我们将探讨如何将现有的数据流从索引生命周期管理 (ILM)迁移到数据流生命周期。现有的由ILM管理的索引将继续由ILM管理,直到它们老化并被ILM删除;然而,新的索引将由数据流生命周期管理。这样,数据流将逐渐从由ILM管理迁移到由数据流生命周期管理。正如我们将看到的,ILM和数据流生命周期可以共同管理一个数据流;然而,一个索引一次只能由一个系统管理。
太长不看
edit要将数据流从ILM迁移到数据流生命周期,我们需要执行两个步骤:
-
更新支持数据流的索引模板,将prefer_ilm设置为
false,并配置数据流生命周期。 - 使用生命周期API为现有数据流配置数据流生命周期。
更多详情请参见迁移到数据流生命周期部分。
设置ILM管理的数据流
edit让我们首先创建一个由ILM管理两个后备索引的数据流。 我们首先创建一个ILM策略:
PUT _ilm/policy/pre-dsl-ilm-policy
{
"policy": {
"phases": {
"hot": {
"actions": {
"rollover": {
"max_primary_shard_size": "50gb"
}
}
},
"delete": {
"min_age": "7d",
"actions": {
"delete": {}
}
}
}
}
}
并创建一个索引模板,该模板将支持数据流并配置ILM:
PUT _index_template/dsl-data-stream-template
{
"index_patterns": ["dsl-data-stream*"],
"data_stream": { },
"priority": 500,
"template": {
"settings": {
"index.lifecycle.name": "pre-dsl-ilm-policy"
}
}
}
我们现在将一个文档索引到 dsl-data-stream 以创建数据流,并且我们还将手动滚动数据流以创建另一个生成的索引:
POST dsl-data-stream/_doc?
{
"@timestamp": "2023-10-18T16:21:15.000Z",
"message": "192.0.2.42 - - [06/May/2099:16:21:15 +0000] \"GET /images/bg.jpg HTTP/1.0\" 200 24736"
}
POST dsl-data-stream/_rollover
我们将使用GET _data_stream API 来检查数据流的状态:
GET _data_stream/dsl-data-stream
检查响应,我们会看到两个后备索引都由ILM管理,并且下一代索引也将由ILM管理:
{
"data_streams": [
{
"name": "dsl-data-stream",
"timestamp_field": {
"name": "@timestamp"
},
"indices": [
{
"index_name": ".ds-dsl-data-stream-2023.10.19-000001",
"index_uuid": "xCEhwsp8Tey0-FLNFYVwSg",
"prefer_ilm": true,
"ilm_policy": "pre-dsl-ilm-policy",
"managed_by": "Index Lifecycle Management"
},
{
"index_name": ".ds-dsl-data-stream-2023.10.19-000002",
"index_uuid": "PA_JquKGSiKcAKBA8DJ5gw",
"prefer_ilm": true,
"ilm_policy": "pre-dsl-ilm-policy",
"managed_by": "Index Lifecycle Management"
}
],
"generation": 2,
"status": "GREEN",
"template": "dsl-data-stream-template",
"next_generation_managed_by": "Index Lifecycle Management",
"prefer_ilm": true,
"ilm_policy": "pre-dsl-ilm-policy",
"hidden": false,
"system": false,
"allow_custom_routing": false,
"replicated": false,
"rollover_on_write": false
}
]
}
|
支持索引的名称。 |
|
|
对于每个后备索引,我们显示prefer_ilm配置的值,该值将指示在为索引配置了两个系统的情况下,ILM是否优先于数据流生命周期。 |
|
|
为此索引配置的ILM策略。 |
|
|
管理此索引的系统(可能的值是“索引生命周期管理”、“数据流生命周期”或“未管理”) |
|
|
将管理下一代索引的系统(一旦数据流滚动,这是该数据流的新写入索引)。可能的值为"索引生命周期管理"、"数据流生命周期"或"未管理"。 |
|
|
在支持数据流的索引模板中配置的prefer_ilm值。此值将配置给所有新的支持索引。如果未在索引模板中配置,支持索引将接收 |
|
|
在支持此数据流的索引模板中配置的ILM策略(只要它在索引模板中存在,就会在所有新的支持索引上配置)。 |
将数据流迁移到数据流生命周期
edit要将 dsl-data-stream 迁移到数据流生命周期,我们需要执行两个步骤:
-
更新支持数据流的索引模板,将prefer_ilm设置为
false,并配置数据流生命周期。 -
使用生命周期API为现有的
dsl-data-stream配置数据流生命周期。
添加到索引模板中的数据流生命周期配置,作为一个数据流配置,只会应用于新数据流。我们的数据流已经存在,因此即使我们在索引模板中添加了数据流生命周期配置,它也不会应用于dsl-data-stream。
PUT _index_template/dsl-data-stream-template
{
"index_patterns": ["dsl-data-stream*"],
"data_stream": { },
"priority": 500,
"template": {
"settings": {
"index.lifecycle.name": "pre-dsl-ilm-policy",
"index.lifecycle.prefer_ilm": false
},
"lifecycle": {
"data_retention": "7d"
}
}
}
我们已经确保新数据流将由数据流生命周期管理。
让我们更新现有的 dsl-data-stream 并配置数据流生命周期:
PUT _data_stream/dsl-data-stream/_lifecycle
{
"data_retention": "7d"
}
我们可以检查数据流,确认下一代确实将由数据流生命周期管理:
GET _data_stream/dsl-data-stream
{
"data_streams": [
{
"name": "dsl-data-stream",
"timestamp_field": {
"name": "@timestamp"
},
"indices": [
{
"index_name": ".ds-dsl-data-stream-2023.10.19-000001",
"index_uuid": "xCEhwsp8Tey0-FLNFYVwSg",
"prefer_ilm": true,
"ilm_policy": "pre-dsl-ilm-policy",
"managed_by": "Index Lifecycle Management"
},
{
"index_name": ".ds-dsl-data-stream-2023.10.19-000002",
"index_uuid": "PA_JquKGSiKcAKBA8DJ5gw",
"prefer_ilm": true,
"ilm_policy": "pre-dsl-ilm-policy",
"managed_by": "Index Lifecycle Management"
}
],
"generation": 2,
"status": "GREEN",
"template": "dsl-data-stream-template",
"lifecycle": {
"enabled": true,
"data_retention": "7d",
"effective_retention": "7d",
"retention_determined_by": "data_stream_configuration"
},
"ilm_policy": "pre-dsl-ilm-policy",
"next_generation_managed_by": "Data stream lifecycle",
"prefer_ilm": false,
"hidden": false,
"system": false,
"allow_custom_routing": false,
"replicated": false,
"rollover_on_write": false
}
]
}
|
现有的后备索引将继续由ILM管理 |
|
|
现有的后备索引将继续由ILM管理 |
|
|
下一代索引将由数据流生命周期管理 |
|
|
我们在索引模板中配置的 |
我们现在将滚动数据流,以查看由数据流生命周期管理的新生成索引:
POST dsl-data-stream/_rollover
GET _data_stream/dsl-data-stream
{
"data_streams": [
{
"name": "dsl-data-stream",
"timestamp_field": {
"name": "@timestamp"
},
"indices": [
{
"index_name": ".ds-dsl-data-stream-2023.10.19-000001",
"index_uuid": "xCEhwsp8Tey0-FLNFYVwSg",
"prefer_ilm": true,
"ilm_policy": "pre-dsl-ilm-policy",
"managed_by": "Index Lifecycle Management"
},
{
"index_name": ".ds-dsl-data-stream-2023.10.19-000002",
"index_uuid": "PA_JquKGSiKcAKBA8DJ5gw",
"prefer_ilm": true,
"ilm_policy": "pre-dsl-ilm-policy",
"managed_by": "Index Lifecycle Management"
},
{
"index_name": ".ds-dsl-data-stream-2023.10.19-000003",
"index_uuid": "PA_JquKGSiKcAKBA8abcd1",
"prefer_ilm": false,
"ilm_policy": "pre-dsl-ilm-policy",
"managed_by": "Data stream lifecycle"
}
],
"generation": 3,
"status": "GREEN",
"template": "dsl-data-stream-template",
"lifecycle": {
"enabled": true,
"data_retention": "7d",
"effective_retention": "7d",
"retention_determined_by": "data_stream_configuration"
},
"ilm_policy": "pre-dsl-ilm-policy",
"next_generation_managed_by": "Data stream lifecycle",
"prefer_ilm": false,
"hidden": false,
"system": false,
"allow_custom_routing": false,
"replicated": false,
"rollover_on_write": false
}
]
}
|
在滚动之前存在的后备索引将继续由ILM管理 |
|
|
在滚动之前存在的后备索引将继续由ILM管理 |
|
|
新的写入索引接收到了 |
|
|
新的写入索引由 |
将数据流迁移回 ILM
edit我们可以轻松地将此数据流更改为由ILM管理,因为我们没有在更新索引模板时移除ILM策略。
我们可以通过两种方式实现这一点:
- 删除生命周期 从数据流中
-
通过将
enabled标志配置为false来禁用数据流生命周期。
让我们实现选项2并禁用数据流生命周期:
GET _data_stream/dsl-data-stream
{
"data_streams": [
{
"name": "dsl-data-stream",
"timestamp_field": {
"name": "@timestamp"
},
"indices": [
{
"index_name": ".ds-dsl-data-stream-2023.10.19-000001",
"index_uuid": "xCEhwsp8Tey0-FLNFYVwSg",
"prefer_ilm": true,
"ilm_policy": "pre-dsl-ilm-policy",
"managed_by": "Index Lifecycle Management"
},
{
"index_name": ".ds-dsl-data-stream-2023.10.19-000002",
"index_uuid": "PA_JquKGSiKcAKBA8DJ5gw",
"prefer_ilm": true,
"ilm_policy": "pre-dsl-ilm-policy",
"managed_by": "Index Lifecycle Management"
},
{
"index_name": ".ds-dsl-data-stream-2023.10.19-000003",
"index_uuid": "PA_JquKGSiKcAKBA8abcd1",
"prefer_ilm": false,
"ilm_policy": "pre-dsl-ilm-policy",
"managed_by": "Index Lifecycle Management"
}
],
"generation": 3,
"status": "GREEN",
"template": "dsl-data-stream-template",
"lifecycle": {
"enabled": false,
"data_retention": "7d"
},
"ilm_policy": "pre-dsl-ilm-policy",
"next_generation_managed_by": "Index Lifecycle Management",
"prefer_ilm": false,
"hidden": false,
"system": false,
"allow_custom_routing": false,
"replicated": false,
"rollover_on_write": false
}
]
}
如果我们当时在更新索引模板时移除了ILM策略,数据流的写索引现在将会是Unmanaged,因为索引没有配置ILM策略作为回退。