我们有一个 4 数据节点 ElasticSearch 集群：每个节点有 4 个核心、16GB RAM 和 160GB 存储空间（集群有单独的专用主节点）。集群负责存储和呈现（使用 Kibana）我们在开发/测试/生产过程中维护的各种客户端和服务中的大量不同日志。
我们正在尝试开发索引数据的最佳方法。我们的目标是将数据隔离在尽可能低的级别，以便我们能够根据数据值轻松管理（即存档、删除等）具有不同保留期限的每个客户端环境。
我们已经知道我们想要按日期进行索引，但在索引数量变得难以处理之前，我们可以将索引细化到什么程度？例如，logstash-{client}-{environment}-{date} 是否合理？我们的索引会不会太多？
答案1
为 LogStash 扩展 ES 是一个难题，尤其是对于保留间隔差异很大的情况。对于 ES 扩展，有两个大问题需要解决：
- 全局目录中的字段
- 分片数量（索引 * 分区 * 副本数）
字段数量决定了所有东西对 Java HEAP 的要求。我听说过一些恐怖故事，有人允许 JSON 输入，导致类似这样的事件：
http.192-168-82-19.request = "GET /"
http.192-168-82-19.verb = "GET"
http.192-168-82-19.path = "/"
http.192-168-82-19.response_time = 12022
等等。您可以想象，这会导致目录中的字段数量惊人。他们花了很长时间才从这个坑里爬出来，所以请注意您的输入并尽量不要进入它。对于像您这样的多客户端架构，对允许进入索引的字段进行更改控制是一个好主意；您会为此感到高兴。
分片的数量会再次扩展 Java HEAP，以及节点故障转移时的恢复时间。30 个分片中的 8TB 与 300 个分片中的 8TB 的恢复方式不同。通常，分片越少越好，但这取决于您的 RAM。
我用来判断 ElasticSearch 集群大小是否合适的指标之一是维护集群的麻烦程度。如果我云端而我的修补方法是创建一个新的基础映像并部署一个新的虚拟机，我将非常关心用数据填充新实例需要多长时间。在这种情况下，出于维护原因，我更有可能添加数据节点以完全缩短恢复时间。如果我在实际服务器上，并且我的修补方法是重新启动机器并继续运行，那么全机恢复的情况就少得多，所以我不太关心数据节点上的多个 TB 数据。只有你能决定你的痛点在哪里。
较新版本的 ElasticSearch（特别是 5.x 系列）具有重新索引功能，对于像您这样的情况非常有用，尤其是与 Curator 搭配使用时。一旦您的索引老化到一定程度，仅出于合规性原因而保留它们，您可以将一周的每日索引重新索引为单个每周索引。这会将 70 个分片（2 个副本 * 5 个分区 * 7 天）变成 10 个分片，但代价是降低该周的搜索速度。
这种事情对您的服务器来说可能非常困难，所以可能不是正确的选择。但是，这是一种允许您运行具有自己的保留和查询期限的 ES 服务器“存档”集群的技术。