我们在azure上有一个应用程序，运行在带有redis cluster的nodejs和其他一些节点上。他们都在生成日志，这些日志被移动到一个公共的“azure文件存储”作为诊断，然后每周通过cron归档到tgzs中。我们希望引入弹性堆栈，以便更好地利用现有日志进行主动措施。所以我想到了beats（filebeat-system，redis）--->logstash（可选）或elasticsearch（inset）--->kibana[不熟悉logstash的广泛功能，所以把它作为可选的（尽管建议是受欢迎的）]。现在的问题如下：
什么是最佳的可扩展+经济高效的体系结构？
选项1:azure的elasticsearch（自我管理）设置-包含elastic的数据和主节点的完整设置只需几个步骤即可完成，这些步骤可以与日志源集成并根据需要进行管理。选项2：我们根据当前日志占用的存储空间和elk预期的用例来设计和调整我们自己的设置，我更喜欢这样，因为我希望有一个通用的云不可知设置，也可以在其他地方使用。
如果选项2，如何计算es的正确尺寸。例如，我们是否要设置3个主节点、2个数据节点，然后如何进行索引，然后如何将索引划分为多个分片（假设我们以后不能更改/更新每个索引的主分片数）。需要注意哪些因素和最佳做法？如何分解-所需的存储和计算。您可以以redis服务器日志为例。
如前所述，所有源日志都已在“azure文件”存储中-但ElasticSearch要求将数据保留在数据节点中以供分析等。我有点想避免在两个位置复制日志？有没有可能在ElasticSearch中进行运行时分析，即beat模块始终从现有的“azure存储”获取/传送数据（运行时），然后数据节点在kibana上分析和显示相同的数据（这可能比复制完整的日志一次需要更少的存储）。我在读关于“长寿命指数”和“滚动指数”的书，能帮上忙吗？
提前感谢您的指导和建议