弹性搜索中索引的自动翻转
Automated rollover for index in elasticsearch
我需要一个索引,它通过 Logstash 不断地将数据加载到 Elasticsearch (7.15) 中,问题是随着时间的推移索引将变满,并且由于性能原因和庞大的大小,最好将索引拆分为较小的。
据我了解,滚动更新和索引生命周期管理是我需要了解的概念才能满足要求。
我对此有一些疑问
当他们谈论索引别名和数据流时。我还没有找到任何关于区别到底是什么的信息。它们似乎都涵盖了跨越多个较小索引的情况。那么谁能详细说明区别是什么
据我所知,我需要创建一个策略和一个索引模板,创建一个数据流,然后上传数据。我试图制定一个简单的策略,只要有超过 3 个文档就应该滚动,但即使这样做它也会创建一个索引但在超过文档数量后永远不会滚动。如果我使用 max_age 它似乎有效
我做的事情如下:
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_docs": 2
},
"set_priority": {
"priority": 100
}
}
},
"cold": {
"min_age": "30s",
"actions": {
"set_priority": {
"priority": 0
}
}
}
}
}
}
PUT _component_template/my-mappings
{
"template": {
"mappings": {
"properties": {
"@timestamp": {
"type": "date",
"format": "date_optional_time||epoch_millis"
},
"message": {
"type": "wildcard"
}
}
}
},
"_meta": {
"description": "Mappings for @timestamp and message fields",
"my-custom-meta-field": "More arbitrary metadata"
}
}
# Creates a component template for index settings
PUT _component_template/my-settings
{
"template": {
"settings": {
"index.lifecycle.name": "my-lifecycle-policy"
}
},
"_meta": {
"description": "Settings for ILM",
"my-custom-meta-field": "More arbitrary metadata"
}
}
PUT _index_template/my-index-template
{
"index_patterns": ["my-data-stream*"],
"data_stream": {
"hidden": false
},
"composed_of": [ "my-mappings", "my-settings" ],
"priority": 500,
"_meta": {
"description": "Template for my time series data",
"my-custom-meta-field": "More arbitrary metadata"
}
}
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-07T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-05-08T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-05-09T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-05-10T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
PUT my-data-stream/_bulk
{ "create":{ } }
{ "@timestamp": "2099-06-11T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-06-12T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-06-13T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-06-14T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-06-15T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-06-16T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
- 我想要一个命名方案,这样它们每个季度都会轮换命名方案似乎是按序列号命名的,是否可以指定每个季度
提前致谢
- 别名是对一个或多个索引的引用,是 Elasticsearch 中的一个基本概念。数据流使用别名,可以看作是别名、数据分层等概念的集合,通过自动化使事情更容易使用
- ILM 并非真正设计用于处理如此小的阈值,因此它不起作用也就不足为奇了。即默认情况下,ILM 只会每 10 分钟检查一次操作
- 基于时间的滚动更新基于从策略创建基础索引的时间。因此相对于日历的“季度”翻转是不可能的
我需要一个索引,它通过 Logstash 不断地将数据加载到 Elasticsearch (7.15) 中,问题是随着时间的推移索引将变满,并且由于性能原因和庞大的大小,最好将索引拆分为较小的。
据我了解,滚动更新和索引生命周期管理是我需要了解的概念才能满足要求。
我对此有一些疑问
当他们谈论索引别名和数据流时。我还没有找到任何关于区别到底是什么的信息。它们似乎都涵盖了跨越多个较小索引的情况。那么谁能详细说明区别是什么
据我所知,我需要创建一个策略和一个索引模板,创建一个数据流,然后上传数据。我试图制定一个简单的策略,只要有超过 3 个文档就应该滚动,但即使这样做它也会创建一个索引但在超过文档数量后永远不会滚动。如果我使用 max_age 它似乎有效
我做的事情如下:
{
"policy": {
"phases": {
"hot": {
"min_age": "0ms",
"actions": {
"rollover": {
"max_docs": 2
},
"set_priority": {
"priority": 100
}
}
},
"cold": {
"min_age": "30s",
"actions": {
"set_priority": {
"priority": 0
}
}
}
}
}
}
PUT _component_template/my-mappings
{
"template": {
"mappings": {
"properties": {
"@timestamp": {
"type": "date",
"format": "date_optional_time||epoch_millis"
},
"message": {
"type": "wildcard"
}
}
}
},
"_meta": {
"description": "Mappings for @timestamp and message fields",
"my-custom-meta-field": "More arbitrary metadata"
}
}
# Creates a component template for index settings
PUT _component_template/my-settings
{
"template": {
"settings": {
"index.lifecycle.name": "my-lifecycle-policy"
}
},
"_meta": {
"description": "Settings for ILM",
"my-custom-meta-field": "More arbitrary metadata"
}
}
PUT _index_template/my-index-template
{
"index_patterns": ["my-data-stream*"],
"data_stream": {
"hidden": false
},
"composed_of": [ "my-mappings", "my-settings" ],
"priority": 500,
"_meta": {
"description": "Template for my time series data",
"my-custom-meta-field": "More arbitrary metadata"
}
}
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-07T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-05-08T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-05-09T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-05-10T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
PUT my-data-stream/_bulk
{ "create":{ } }
{ "@timestamp": "2099-06-11T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-06-12T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-06-13T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-06-14T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-06-15T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
{ "create":{ } }
{ "@timestamp": "2099-06-16T16:25:42.000Z", "message": "192.0.2.255 - - [06/May/2099:16:25:42 +0000] \"GET /favicon.ico HTTP/1.0\" 200 3638" }
- 我想要一个命名方案,这样它们每个季度都会轮换命名方案似乎是按序列号命名的,是否可以指定每个季度
提前致谢
- 别名是对一个或多个索引的引用,是 Elasticsearch 中的一个基本概念。数据流使用别名,可以看作是别名、数据分层等概念的集合,通过自动化使事情更容易使用
- ILM 并非真正设计用于处理如此小的阈值,因此它不起作用也就不足为奇了。即默认情况下,ILM 只会每 10 分钟检查一次操作
- 基于时间的滚动更新基于从策略创建基础索引的时间。因此相对于日历的“季度”翻转是不可能的