azure - 如何设计和构建 Elastic 堆栈（使用 Beats、Logstash、Elastic Search、Kibana）？（最佳实践）

问题描述

我们在带有 Redis-cluster 和其他一些节点的 NodeJ 上运行在 Azure 上的应用程序。它们都在生成日志，这些日志被移动到一个通用的“Azure 文件存储”作为诊断，然后每周通过一个 cron 归档到 tgzs 中。我们希望引入 Elastic stack，以便更好地使用现有日志进行主动措施。所以我在考虑 Beats (filebeat - system, redis) --> logstash (optional) 或 Elastic search (ingest) --> Kibana [不太熟悉 logstash 的广泛功能，所以把它作为可选的（尽管建议)]。现在问题如下：

什么是最优化的可扩展+具有成本效益的架构？

选项 1：Azure 的 Elasticsearch（自我管理）设置 - 包含弹性数据和主节点的完整设置只需几个步骤即可与日志源集成并根据需要进行管理。选项 2：我们根据当前日志占用的存储空间和 ELK 预期的用例来设计和确定我们自己的设置我更喜欢这个，因为我想要一个通用的云不可知设置，也可以在其他地方使用。

如果选项 #2，如何计算 ES 的正确尺寸。例如，我们是否使用 3 个主节点、2 个数据节点设置，然后如何进行索引以及如何将索引划分为分片（鉴于我们将来无法更改/更新每个索引的主分片数量）。需要注意哪些因素和最佳实践？如何分解 - 所需的存储和计算。例如，您可以使用 redis-server 日志。
如上所述，所有源日志都已经在“天蓝色文件”存储中 - 但弹性搜索要求将数据保留在数据节点中以进行分析等。我有点想避免在 2 个地方复制日志？是否可以在弹性搜索中进行运行时分析，即 Beat 模块始终从现有的“天蓝色存储”中获取/发送数据（运行时），然后在 Kibana 上分析和显示相同的数据节点（这可能需要更少时间存储而不是复制完整的日志）。我正在阅读有关“长寿指数”和“滚动指数”的信息，它有帮助吗？

提前感谢您的指导和建议

标签： azureelasticsearchkibanaelastic-stack

azure - 如何设计和构建 Elastic 堆栈（使用 Beats、Logstash、Elastic Search、Kibana）？（最佳实践）

问题描述

解决方案

推荐阅读