我们最初的问题
去年我们遇到了一个问题，一台服务器上的恶意软件向我们的中央 Graylog 服务器发送了大量垃圾邮件，从而给其他应用程序带来了问题。
主要问题是来自其他应用程序的较旧的有用消息比正常情况更早被清除，而索引中则充满了来自恶意应用程序的无用消息。
我建议的解决办法是给每个应用程序一个自己的索引，这样任何应用程序都不会占用其他应用程序的日志存储空间。这不需要对应用程序本身进行任何更改，只需要在 Graylog 内部进行更改。然而，什么也没做，因为正在计划一种新的基于 kubernetes 的 Graylog 解决方案。
我们提供的解决方案
快进到现在，我们正处于替换 Graylog 系统的调试过程中。
最初我们被告知每个应用程序都有自己独立的graylog 服务器（负载均衡器、gelf 端点、graylog 节点、弹性搜索集群）和 graylog 前端网站。
问题是，不同的应用程序之间存在复杂的关系，并且必须转到不同的 graylog 网络服务器来获取来自不同应用程序的日志（graylog-application1.site 获取来自应用程序 1 的日志，graylog-application2.site 获取来自应用程序 2 的日志，而不仅仅是转到 graylog.site）将使跨应用程序搜索变得非常困难。
修改后的解决方案
指出这一点之后，提出了一个解决方案，根据需要一起搜索的可能性对应用程序进行分组，因此现在我们希望每个组都有单独的 Graylog 服务器（应用程序 1 和 3 使用 application-group-a.site，应用程序 2、4 和 5 使用 application-group-b.site 等）。
我不知道这是否是必要的或者充分的。
这意味着许多可能的跨应用程序搜索将很容易进行，但一些最难解决的支持问题是那些跨越不太明显的应用程序边界的问题，这些搜索将不再那么容易（事实上，如果你不知道涉及哪个应用程序，可能是不可能的）。
人们认为，仅在单个中央 graylog 服务器上设置单独的索引并不能在应用程序组之间提供足够的隔离。他们希望确保来自一个应用程序的消息的进入永远不会干扰来自其他应用程序的消息的进入，因此他们希望在组之间实现完全隔离。
我的问题在于，如果群组内的应用程序出现问题并向群组 graylog 服务器发送垃圾邮件，那么这种方法就无济于事了。如果我们能找到一种解决方案来防止群组内出现拒绝服务问题，那么我们也能找到一种针对单一集中式 Graylog 服务的解决方案。
我认为，使用更多负载平衡的 graylog 节点、更多弹性搜索节点、更多 GELF 端点等水平扩展单个中央服务将比拥有数十台 graylog 服务器更好。
问题
当所有 graylog 服务器都托管在同一个 Kubernetes 集群上时，单独的 graylog 服务器是否真的能提供人们想要的隔离级别（拒绝服务缓解）？
我们能否使用单个中央 Graylog 服务器提供与单独组 Graylog 服务器类似或更好的隔离级别？
其他组织是否以这种方式使用 Graylog，拥有许多前端网站，还是需要单一中央网站来访问所有日志？
本质上，我要么想说服自己，我只是在担心一些小事，这种解决方案很常见；要么想找到论据，让人们相信我们正在考虑的事情违背了最佳实践，我们真的不应该这样做。
我真的很想找到一个对每个人都有效的解决方案，但目前在我看来，我们目前提出的解决方案更像是把孩子和洗澡水一起倒掉。
答案1
您对 Graylog 设置架构的担忧和疑问非常合理。找到一种能够平衡隔离和资源管理需求以及易用性和可管理性的解决方案非常重要。让我们像 Kris Kross 一样来分析一下！
1. 当所有 Graylog 服务器都托管在同一个 Kubernetes 集群上时，单独的 Graylog 服务器是否真的能提供人们想要的隔离级别（拒绝服务缓解）？
在同一 Kubernetes 集群上运行的独立 Graylog 服务器可以提供一定程度的隔离，但重要的是要了解它们仍在集群级别共享资源，包括网络带宽、存储以及可能的 CPU 和内存。如果组中的一个应用程序出现异常并开始发送垃圾邮件，则可能会因资源争用而影响同一集群上其他 Graylog 服务器的性能。虽然 Kubernetes 提供了资源管理功能，但它并不是防止资源相关问题的灵丹妙药。
2. 我们能否使用单个中央 Graylog 服务器提供与单独组 Graylog 服务器类似或更好的隔离级别？
单个中央 Graylog 服务器可以使用单独的索引在应用程序之间提供隔离，但正如您所提到的，它可能无法防止恶意应用程序使服务器过载并导致其他应用程序出现问题。为了缓解这种情况，您可以考虑对生成日志消息的输入或源实施更严格的速率限制和节流策略。此外，您可以水平扩展中央 Graylog 服务器以处理增加的负载，这比管理多个单独的服务器更具成本效益。
3. 其他组织是否以这种方式使用 Graylog，拥有许多前端网站，还是需要单个中央网站来访问所有日志？
选择为不同的 Graylog 实例设置多个前端网站还是设置一个中央网站取决于组织的具体需求和偏好。这两种方法都是有效的，各有优缺点。
多个前端网站：当不同的团队或应用程序需要单独的 Graylog 实例以实现更好的隔离、控制和组织时，这种方法很合适。它可以简化访问控制并为不同的团队提供自主权。但是，它可能需要用户在不同的界面之间切换以进行跨应用程序搜索。
单一中央网站：用于访问所有日志的单一中央网站提供了整个日志基础设施的统一视图，使跨应用程序搜索更加容易。这种方法简化了用户访问，但可能需要更强大的访问控制和权限管理，以确保不同团队或应用程序之间的数据分离。
最终，这些方法之间的选择取决于您的组织对隔离、易用性、资源管理的优先级以及您的应用程序和团队的特定要求。
为了找到适合每个人的平衡解决方案，请考虑以下几点：
- 在每个 Graylog 实例中实施严格的速率限制和节流策略，以防止恶意应用程序压垮系统。
- 监控并警告所有 Graylog 实例的资源使用情况和性能，以主动检测和解决问题。
- 记录并向所有团队传达日志管理和使用的最佳实践。
- 继续探索具有适当资源扩展和访问控制机制的集中式 Graylog 解决方案的可能性。
总而言之，最好的方法可能涉及组合。您可能会发现自己对逻辑应用程序组使用单独的 Graylog 实例，同时实施强大的资源管理和监控实践，以确保日志管理基础设施的整体稳定性。让来自不同团队的利益相关者参与决策过程也很重要，以确保所选解决方案符合他们的需求和期望，这只是一个避免 wiggity wiggity wiggity 打击问题的建议，你知道吗？;)
答案2
Graylog（以及类似产品）提供的巨大优势不是单独的日志存储，而是不同日志源和记录事件之间的相关性。通过使用多个独立的 Graylog 服务器，每个服务器收集不同的源，多源关联变得更加困难。
我建议使用单个 Graylog 服务器（如果单个节点不够用，则使用集群多节点设置）和多个特定索引，并采用不同的（和适当的）轮换策略。您可以通过适当的方式将流量路由到这些索引流规则（并选择“从默认流中删除匹配”）。