日志平台-Index的管理

• 当前使用的是shell的定时任务
  • Mapping配置
  • 索引生命周期
  • index配置
• ILM的管理
• index管理
  • 方法 1: 使用在索引名称上带上时间的方法管理索引（这个是目前采用的方式）
  • 方法 2: 使用 Rollover 管理索引
  • 方法 3: 使用 ILM（Index Lifecycle Management ） 管理索引（这个使用跟graylog一样，就是被抛弃的原因之一，索引的名字目前在系统中是具有意义的）
• shard的管理
  • 按照保留期限进行索引
  • 每个索引和分片都会产生一定的资源开销
  • 分片大小对性能影响
  • 如何管理分片大小

当前使用的是shell的定时任务

Mapping配置

 norms 不需要计算字段的评分，将该参数设为false

 ignore_malformed 忽略这个字段错误并保留该文档中的其他字段，设为ture

 _source 文档原始内容，可以考虑删除

 dynamic_templates 动态模板将默认的字符串类型映射为keyword

 如果不需要按数字大小排序或过来，不使用int类型，使用keyword

索引生命周期

 定时提前新建下一天用的空索引

 冷热数据分离，48小时以前的索引数据搬移到冷节点

 索引变冷后（无写入后），进行强制合并（ForceMerge）

 定时关闭和删除索引

index配置

◼ 合理切分索引和制定分片大小，避免节点故障后索引恢复速度慢的问题

◼ 日志收集场景下写请求远远大于读请求，尽量均匀分配分片在每个节点上，分摊写压力

◼ 节点磁盘独立，避免节点间产生IO竞争

ILM的管理

https://www.elastic.co/guide/en/elasticsearch/reference/current/ilm-index-lifecycle.html

https://www.elastic.co/cn/blog/implementing-hot-warm-cold-in-elasticsearch-with-index-lifecycle-management

生命周期策略中的滚动更新是需要对索引设置别名的，而且每个索引设置的别名不能一样。但日志平台设置的是每天更新索引，索引是按天区分的，给每个索引设置别名的方式很明显不适合我，没办法自动设置索引，最多使用脚本定时去执行，这样增加了复杂度，必要性不强，真做到这一步，我还不如写脚本定时删除，不用生命周期策略了。

红色框体内的配置就已经够用了，关闭rollover，开启delete，设置天数

index管理

https://mp.weixin.qq.com/s/eejvp9yCJxP_Crj8P9jqew
在生产环境使用 ES 要面对的第一个问题通常是索引容量的规划，不合理的分片数，副本数和分片大小会对索引的性能产生直接的影响；
Elasticsearch 中的每个索引都由一个或多个分片组成的，每个分片都是一个 Lucene 索引实例，您可以将其视作一个独立的搜索引擎，它能够对 Elasticsearch 集群中的数据子集进行索引并处理相关查询；
查询和写入的性能与索引的大小是正相关的，所以要保证高性能，一定要限制索引的大小，具体来说是限制分片数量和单个分片的大小；

方法 1: 使用在索引名称上带上时间的方法管理索引（这个是目前采用的方式）

1 创建索引：索引名上带日期
2 写入数据：写入数据的时候也要带上日期
3 查询数据：由于数据分布在多个索引里，查询的时候要在符合条件的所有索引查询，可以使用

.1 使用逗号分割指定多个索引
.2 使用通配符查询
.3 使用别名查询

缺点：
不是所有数据都适合使用时间分割，对于写入之后还有修改的数据不适合；
直接使用时间分割也可能存在某段时间数据量集中，导致索引分片超过设计容量的问题，从而影响性能；
为了解决上述问题还需要配合 rollover 策略使用，索引的维护比较复杂。

方法 2: 使用 Rollover 管理索引

Rollover 的原理是使用一个别名指向真正的索引，当指向的索引满足一定条件（文档数或时间或索引大小）更新实际指向的索引。

1 创建索引并且设置别名：索引名称的格式为 {.*}-d 这种格式的，数字默认是 6 位
2 通过别名写数据：
3 执行 rollover 操作：rollover 的 3 个条件是并列关系，任意一个条件满足就会发生 rollover

缺点：

必须明确执行了 rollover 指令才会更新 rollover 的别名对应的索引；
通常可以在写入数据之后 再执行一下 rollover 命令，或者采用配置系统 cron 脚本的方式；
增加了使用的 rollover 的成本，对于开发者来说不够自动化。

方法 3: 使用 ILM（Index Lifecycle Management ） 管理索引（这个使用跟graylog一样，就是被抛弃的原因之一，索引的名字目前在系统中是具有意义的）

ES 定义的一个索引从生到死的过程, Hot -> Warm -> Cold -> Delete 4 个阶段只有 Hot 阶段是必须的，其他 3 个阶段根据业务的需求可选。

1 建立 Lifecycle 策略
2 建立索引模版：
3 创建索引
4 查看索引配置
5 写入数据
6 配置 Lifecycle 自动 Rollover 的时间间隔

.1 由于 ES 是一个准实时系统，很多操作都不能实时生效；
.2 Lifecycle 的 rollover 之所以不用每次手动执行 rollover 操作是因为 ES 会隔一段时间判断一次索引是否满足 rollover 的条件；
.3 ES 检测 ILM 策略的时间默认为 10min。

shard的管理

https://www.elastic.co/cn/blog/how-many-shards-should-i-have-in-my-elasticsearch-cluster
避免分片过大，因为这样会对集群从故障中恢复造成不利影响。尽管并没有关于分片大小的固定限值，但是人们通常将 50GB 作为分片上限，而且这一限值在各种用例中都已得到验证。

按照保留期限进行索引

尽量使用时序型索引来管理具有数据保留期要求的数据。根据保留期限对数据分组，将它们存储到索引中。通过时序型索引，用户还能随着时间推移轻松调整主分片和副本分片的数量，这是因为用户可针对要生成的下个索引进行这方面的更改。这样便能简化对不断变化的数据量和数据要求的适应过程。

每个索引和分片都会产生一定的资源开销

分片过小会导致段过小，进而致使开销增加。您要尽量将分片的平均大小控制在至少几 GB 到几十 GB 之间。对时序型数据用例而言，分片大小通常介于 20GB 至 40GB 之间。
由于单个分片的开销取决于段数量和段大小，所以通过 forcemerge 操作强制将较小的段合并为较大的段能够减少开销并改善查询性能。理想状况下，应当在索引内再无数据写入时完成此操作。请注意：这是一个极其耗费资源的操作，所以应该在非高峰时段进行。
每个节点上可以存储的分片数量与可用的堆内存大小成正比关系，但是 Elasticsearch 并未强制规定固定限值。这里有一个很好的经验法则：确保对于节点上已配置的每个 GB，将分片数量保持在 20 以下。如果某个节点拥有 30GB 的堆内存，那其最多可有 600 个分片，但是在此限值范围内，您设置的分片数量越少，效果就越好。一般而言，这可以帮助集群保持良好的运行状态。

分片大小对性能影响

从查询性能的角度来看，确定最大分片大小的最佳方法是使用具有实际意义的数据和查询进行基准测试。进行基准测试时，务必确保所使用的查询和索引负载能够代表节点在生产环境中需要处理的内容，因为只针对单一查询进行优化可能会得出错误结果。

尽管查询很多个小分片会加快单个分片的处理速度，但是由于有很多任务需要进入队列并按顺序加以处理，所以与查询较少的大分片相比，这种方法并不一定会加快查询速度。如果有多个并发查询，拥有很多小分片还会降低查询吞吐量。（这句话意思是一味的增加分片并不是一定能够解决问题）

如何管理分片大小

如果使用时序型索引来存储固定期限内的数据，用户应根据保留期和预计数据量对每个索引覆盖的期限进行调整，从而确保达到目标分片大小。对于拥有较长保留期的数据，尤其如果每日数据量并不能保证用完每日索引，通常可按周索引或按月索引，以便提高分片大小。长期来看，这有助于减少存储在集群中的索引和分片数量。
如果您拥有不可更改的时序型数据，并且数据量在一段期间内会巨幅变化，可以考虑使用 rollover index API（汇总索引 API）通过动态调整每个索引所覆盖的时间段来实现最佳的目标分片大小。这为用户提供了很大的灵活性，并且在数据量难以预测时，还有助于避免分片过大或过小。（就是一个index下的shard已经满足不了你的当前方案，进行索引的自动rollover）
如果您希望每个索引既要对应至特定时间段，同时还想将索引过程分散到大量节点上，可以考虑使用 Shrink（压缩）API 来在索引内再无数据写入时