问题描述
我们在Azure上有一个运行在带有Redis-cluster和其他一些节点的NodeJ上的应用程序。所有这些都生成日志，这些日志将作为诊断信息移到公共的“ Azure文件存储”中，然后每周通过cron存档到tgzs中。我们想要引入弹性堆栈，以便更好地将现有日志用于主动措施。因此，我想到了Beats（filebeat-system，redis）-> logstash（可选）或Elastic search（ingest）-> Kibana [不太了解logstash的强大功能，因此将其作为可选项（尽管如此，还是建议） ）]。现在的问题如下：
- 最佳的可扩展+具有成本效益的体系结构是什么？
选项1：Azure的Elasticsearch（自我管理）设置-包含Elastic的数据和主节点的完整设置需要几个步骤来设置，可以与日志源集成并根据需要进行管理。 选项2：我们根据当前日志占用的存储空间和ELK预期的用例设计和设置自己的设置 我更喜欢这种方式，因为我想拥有一个通用的与云无关的设置，该设置也可以在其他地方使用。
-
如果选项＃2，如何为ES计算正确的尺寸。例如，是否要设置3个主节点，2个数据节点，然后如何进行索引，然后如何将索引划分为分片（假设将来无法更改/更新每个索引的主分片数量）。需要注意哪些因素和最佳做法？ 如何分解-需要的存储和计算。您可能会遇到例如Redis服务器日志的情况。
-
如上所述，所有源日志都已经在“ azure文件”存储中-但是弹性搜索要求将数据保留在数据节点中以进行分析等。我有点想避免在2处复制日志地方？是否有可能对弹性搜索进行运行时分析，即Beat模块始终（运行时）从现有的“ azure存储”中获取/运送数据，然后数据节点在Kibana上进行分析和显示（这可能需要更少的时间）而不是复制完整的日志）。 我在阅读有关“万岁索引”和“滚动索引”的信息，对您有帮助吗？
提前感谢您的指导和建议
解决方法
您应该探索弹性堆栈托管解决方案 https://www.elastic.co/cloud/