elasticsearch ELK登录微服务体系结构

我正在使用ELK为我所有的微服务实现集中式日志记录。我的疑问是，我是否必须为每个微服务创建单独的索引，还是为所有微服务日志创建一个索引。到目前为止，我的研究表明，所有微服务的单一通用索引对于集中日志记录实现跨微服务的搜索是有意义的。我还了解到，在elasticsearch中，索引太多会带来一些开销。所以我想听听有经验的人的意见

---

我已经在软件建议中提出了这个问题。在我们的场景中，我们有50多个微服务，我们根据用例执行日志记录，比如UserManagement可能是一个由多个微服务（用户、角色、策略等）组成的用例

因此我们有一个索引对应一个用例。

通过这种方式，我们利用了报告系统的效率，因为报告围绕着每个用例，比如在什么时候有多少用户登录和注销，前后用户角色的变化等等

同样，您也可以创建对应于另一个用例的弹性索引。

---

通过这种方式，我们隔离了弹性索引数据，任何一个索引的任何停机/重新索引都不会影响另一个索引。

其中很多都是特定于您的用例的。你在谈论多少微服务？您能为Elasticsearch投入多少硬件？每个微服务是否都有一种通用的日志格式？这些是在真正了解如何分割数据之前需要回答的一些基本问题。在Kibana中使用正确的索引名称和模式，您仍然可以在多个索引中搜索，所以我不会考虑将数据分离成每个微服务的索引，这是可搜索性的障碍。我可以将elasticsearch集群专用于少数高端机器。是的，在微服务中有一种通用的日志格式。我还认为，当您可以利用跨微服务的搜索时，日志实际上是“集中的”。你对此有何看法？只要你有一个通用的格式，并且数据没有任何分离它的硬要求，我个人会把它全部放在一个索引中（你可以使用Logstash默认提供的每日索引轮换）并监视性能。如果Elasticsearch集群可以处理输入，但搜索速度较慢，则可以增加每个索引的碎片数，或者根据微服务本身的逻辑上下文将数据分散到不同的索引中。感谢您的输入。但我不明白为什么你要索引对应的用例？因为您可以根据用例以多种形式可视化索引数据！