上一章节我们详细剖析了 Log360 可扩展架构的核心组件，阐述各组件的定义、功能及其对系统可扩展性的直接作用。
本节将结合前文讨论的所有架构组件，逐步说明日志从源设备传输到Log360控制台、直至可供分析的完整流程。
示例场景：企业部署及假设条件
中心位置/总部（HQ）
•部署3个Log360日志处理器节点（Log Processor Node）。
•处理器1（Processor 1）为主要处理器（Primary Processor）。
•每个处理器节点均启用了处理引擎（Processing Engine）、日志队列引擎（Log Queue Engine）、搜索引擎（Search Engine）和关联引擎（Correlation Engine）。默认情况下，告警（Alerts）、日志转发（Log Forwarding）和归档（Archiving）功能均由处理引擎负责。
•所有3个节点均配置了共享存储（通过NFS挂载），用于通信和文件处理。
•每个处理器均已配置为可与公共数据库（common database）通信。
•总部处理的日志事件总量（EPS）：8000条/秒。
远程站点A
•100台设备，日志生成量为1000条/秒（EPS）。
•已配置轻量级日志代理（lightweight log agent），用于解析日志并上传至总部的处理器集群。
远程站点B
•150台设备，日志生成量为1500条/秒（EPS）。
•采用与站点A类似的代理配置。
数据流管道概述
远程站点的日志收集
远程站点的代理会先解析日志格式，对日志进行压缩，再通过HTTPS协议将其上传至总部集群中可用的处理器节点。
处理器节点的接收与角色分配
接收日志的处理器节点会先对传入的日志进行 enrichment（增强处理，如补充元数据、标准化格式等），再将其写入队列集群（queue cluster）。之后，日志会被搜索、关联、告警、日志转发等各个独立模块获取并处理。
队列处理（Queuing）
主题（Topics）会临时缓存日志，为后续处理做准备。此过程基于“发布-订阅”（Publish-Subscription）模型实现。
索引与搜索引擎（Indexing and Search Engine）
•已处理的日志会在Elasticsearch中建立索引（所有节点共享该Elasticsearch实例）。
•搜索请求会在各处理器节点间进行负载均衡，但数据均从公共索引（common index）中获取。
存储处理（Storage Handling）
•热数据（Hot data）：存储在Elasticsearch中，以支持快速搜索（默认保留30天）。
•冷数据（Cold data）：以文件格式归档（已压缩且加密），用于审计场景。
•PostgreSQL数据库负责存储元数据（metadata）、告警配置（alert configs）和事件摘要（incident summaries）。
控制台与分析人员访问（Dashboard and Analyst Access）
用户可通过Web控制台执行实时搜索、查看告警、调查事件，以及配置关联规则（correlation rules）。基于角色的访问控制（Role-based access）可确保不同部门和远程分支机构之间的数据可见性相互隔离。
总结
所有处理流程均集中在总部，远程站点仅需保持轻量级部署即可。队列系统（queuing system）确保日志摄入具备高吞吐量，处理器节点则实现了工作负载与存储的高效分配。Elasticsearch支持实时搜索与关联分析，而PostgreSQL和共享文件系统则保障了元数据管理、归档操作和报表生成的连续性。
该部署方案可处理约10000条/秒（EPS）的日志事件，且具备高可用性；支持通过远程代理进行日志转发与索引建立，能够实现高效的日志管理。在下一节中我们将进一步分析架构实现的常见场景和实用案例。
