Logstash/Elasticsearch/Kibana 资源规划答案

【问题标题】：Logstash/Elasticsearch/Kibana resource planningLogstash/Elasticsearch/Kibana 资源规划
【发布时间】：2015-05-19 17:00:14
【问题描述】：

如何根据负载规划资源（我怀疑是elasticsearch实例）：

我的意思是 ≈500K 事件/分钟，每个包含 8-10 个字段。

我应该转动哪些配置旋钮？我是这个堆栈的新手。

【问题讨论】：

您要将数据保留多长时间？您预计会有什么样的查询负载？最后，这将取决于很多因素，以至于您在这里所能得到的只是（可能是受过教育的）猜测；您只需亲自尝试一下即可。
感谢您的评论。负载是永远的，保留可能是 2 个月。存储在这里不是问题，查询能力是。查询是针对仪表板的，1-2 个人应该同时使用它，比如说我每个仪表板有 20-30 个可视化。我只想知道，是一大堆服务器，还是

【解决方案1】：

每分钟 500,000 个事件等于每秒 8,333 个事件，这对于小型集群（3-5 台机器）来说应该很容易处理。

问题在于将每天 7.2 亿份文档保持打开 60 天（43B 份文档）。如果这 10 个字段中的每一个都是 32 字节，那么这就是 13.8TB 的磁盘空间（单个副本接近 28TB）。

作为比较，我最多有 5 个节点（64GB 的 RAM，31GB 堆），1.2B 的文档消耗 1.2TB 的磁盘空间（副本加倍）。这个集群无法处理每台机器只有 32GB RAM 的负载，但它现在对 64GB 很满意。这是我们 10 天的数据。

粗略地说，您预计消耗的磁盘空间是我的集群的 40 倍。

我没有确切的数字，但我们使用 doc_values 的试点项目为我们节省了 90% 的堆空间。

如果所有这些数学都成立，并且 doc_values 很好，那么就索引的实际字节而言，您可以使用类似的集群。我会征求有关拥有如此多单个文档的开销的更多信息。

我们已经对 elasticsearch 进行了一些调整，但可能还有更多工作要做。

我建议您从少量 64GB 机器开始。您可以根据需要添加更多。加入几个（较小的）客户端节点作为索引和搜索请求的前端。

【讨论】：

谢谢。我有强大的 64Gb RAM 机器，将重新考虑我的保留政策。假设我有这一切，10 台机器处理 30Tb 的数据，弹性集群是否能够及时查询，每个实例大约需要 1.5Tb 来扫描。