上一章节我们逐步说明日志从源设备传输到Log360控制台、直至可供分析的完整流程。
为了呈现该架构在动态环境中的运行表现，本节将探讨多个企业常见场景。这些示例将展示系统在应对组件故障、工作负载变化及业务需求演进时的设计逻辑与响应方式。
场景1：冗余部署中的处理器节点故障
案例：某企业部署了两台处理器，且两台处理器均配置了相同角色（处理引擎、日志队列引擎、搜索引擎）。其中一台处理器发生硬件故障并下线。
解决方案：剩余的活跃处理器会无缝接管全部工作负载。访问网关集群（Access Gateway Cluster）会自动停止向故障节点转发日志。由于队列主题（queue topics）和Elasticsearch数据已在集群中实现副本备份，因此不会出现日志丢失，搜索功能也能保持在线，确保服务连续性。
场景2：承担唯一专属角色的节点故障
案例：为处理高负载的规则运算，企业将关联引擎（Correlation Engine）角色分配给了一台专属的独立处理器，而该处理器发生故障。
解决方案：实时关联分析会暂时暂停，但其他节点仍会继续执行日志摄入、队列缓存和索引建立操作，因此不会造成数据丢失。当故障处理器恢复正常，或关联引擎角色被重新分配至另一台活跃处理器后，系统会从队列中处理积压的事件，确保不会遗漏任何安全威胁。
场景3：扩展特定功能以满足需求
案例：分析人员反馈，在峰值调查时段，日志搜索查询速度变慢，给安全团队造成了瓶颈。
解决方案：企业可通过横向扩展（horizontally scale）解决该问题——新增一台处理器节点，并为其分配专属的搜索引擎角色。此举可将资源密集型的搜索功能与日志摄入、日志处理节点隔离开来。现有Elasticsearch集群会自动将搜索工作负载分配至新节点，查询性能随即得到提升。
场景4：适配“仅日志转发”需求
案例：某企业决定将安全分析功能集中到另一款工具中，目前仅需Log360从各远程站点收集、解析并转发日志。
解决方案：通过主要处理器（Primary Processor）重新配置角色，可简化架构。具体操作包括：禁用关联分析（Correlation）、搜索（Search）、告警（Alerts）等角色，将处理器专属用于处理引擎（Processing Engine）、日志队列引擎（Log Queue Engine）和日志转发（Log Forwarding）角色。此外，可停用不必要的节点以降低成本，从而将Log360高效转型为高可扩展的日志转发管道。
场景5：主要处理器（Primary Processor）故障
案例：负责集群管理与配置任务的主要处理器意外下线。
解决方案：其他所有安全运营工作（如数据收集、处理、搜索、告警）会在其余处理器节点上继续运行，不受任何中断影响。尽管新增处理器等管理类任务会暂时暂停，但安全监控功能完全不受影响。
后续步骤
了解Log360的架构原理后，下一步需规划具体的部署方案。
