在处理AWS/CloudWatch日志时，什么是好的索引策略？

我是Elasticsearch world的新手，我正在进行一个项目，使用Amazon Elasticsearch服务（Elasticsearch和Kibana）为来自不同AWS帐户的所有CloudWatch日志提供日志分析系统。设置堆栈和路由CloudWatch日志是简单的部分。但我注意到，当您以时间序列的方式拥有不可变的数据时（在本例中为日志），一个好的索引策略就显得尤为重要。 我的第一种方法是为每个日志组创建一个每日单一索引，并根据我的需求使用索引策略移动/终止旧索引。但我想我要处理Elasticsearch集群中的许多小索引。 然后，我考虑将每个AWS帐户中的所有CloudWatch日志组编入每日单个索引。问题是，它超出了映射限制（1000个字段），这主要是由CloudTrail和VPS流日志引起的，我认为增加此限制不是一个好主意。 因此，我决定将我的日志分为一些数量有限的索引类型（例如cloudtrail日志、VPC流日志和其他日志）。所以基本上，我会为每个AWS账户建立三个每日指数，这是相对较大的指数，我不必增加映射限制。

---

我分享这篇文章是想看看是否有人已经实现了类似的东西，他们的想法是什么。我仍处于项目的初始阶段，我急切地寻求建议和建议。

一个好的索引策略是非常主观的，取决于很多因素，如每个索引的大小以及查询的频率

因为，这里我们讨论的是cloudwatch日志，所以您应该继续关注避免大量较小的索引。除了合并不同类型的日志外，您还可以将较旧的指数合并为每周或每月指数。例如，在一周结束时将一周数据重新索引为一周索引。此外，请确保定义了保留期，并清除了所有旧索引

您还可以考虑查看Amazon Elasticsearch中提供的热温存储体系结构，该体系结构非常适合于日志等只读数据