阶段一：单体集群日志架构（单集群时代）
在日志平台建设的初期，业务规模与节点数量有限，团队通常采用最直接的“采集→存储→展示”三组件模型。这一阶段的核心诉求是快速搭建、开箱即用，架构拓扑呈现为典型的星型或直线型结构。
2.1 单集群架构拓扑图
下图展示了单体集群时代的标准日志管道：Filebeat 作为轻量采集器将日志数据发送至 Elasticsearch 单集群，Kibana 作为可视化层直接对接 ES 进行查询与仪表盘展示。
2.2 组件角色与职责
| 组件 | 角色定位 | 核心职责 | 部署形态 |
|---|---|---|---|
| Filebeat | 轻量日志采集器 | 监控日志文件/标准输出，读取、过滤、发送至 ES | 每台应用服务器部署一个 Agent |
| Elasticsearch | 分布式搜索与存储引擎 | 接收日志索引、存储、全文检索、聚合分析 | 单集群（通常 1~3 节点，主从合一） |
| Kibana | 可视化与交互层 | 日志查询、仪表盘、告警配置、索引管理 | 单实例 Web 服务 |
2.3 单点故障风险分析
单体架构最突出的问题在于单点故障（SPOF）。任何一个核心组件失效，都会导致日志链路中断或数据不可用。
- Filebeat 单点：若 Filebeat 进程崩溃或所在节点宕机，该服务器日志将完全丢失采集能力，且无自动恢复机制。
- Elasticsearch 单点：单节点 ES 一旦宕机，所有索引数据丢失，Kibana 无法查询；即使部署 2~3 节点，若未配置副本分片，主节点故障仍会导致数据不可用。
- Kibana 单点：Kibana 实例挂掉后，运维人员无法访问日志界面，排查问题只能直接操作 ES API，效率极低。
典型故障场景：某次 ES 主节点 JVM OOM 导致集群完全不可用，日志写入失败持续 40 分钟，Kibana 返回 502 错误。恢复后需手动重建索引，期间丢失约 15% 的日志数据。
2.4 存储与查询瓶颈
随着日志量增长，单体架构在存储和查询维度会迅速暴露性能瓶颈：
| 瓶颈维度 | 具体表现 | 根因 |
|---|---|---|
| 存储容量 | 磁盘空间快速耗尽，索引写入拒绝 | 单节点磁盘上限（通常 2~4 TB），无法水平扩展 |
| 写入吞吐 | 日志堆积，Filebeat 重试队列溢出 | 单节点 CPU/IO 瓶颈，bulk 写入并发受限 |
| 查询延迟 | 聚合查询耗时 > 30s，仪表盘加载超时 | 全量扫描所有分片，无冷热分层，无缓存优化 |
| 索引管理 | 索引数量膨胀，分片碎片化严重 | 缺乏 ILM（索引生命周期管理）策略，手动维护 |
2.5 单体架构的典型容量指标
以下为单集群时代常见的性能参考值，超出后架构瓶颈将显著加剧：
- 日日志量：50 ~ 200 GB/天
- 总存储：1 ~ 4 TB（受单节点磁盘限制）
- 查询 QPS：< 50 次/秒（聚合查询 < 10 次/秒）
- 写入延迟：平均 2~5 秒（高峰期可能 > 30 秒）
- 可用性 SLA：99.0% ~ 99.5%（无冗余设计）
演进信号：当日志量持续超过 200 GB/天，或查询延迟频繁超过 10 秒，即应启动架构升级规划。单体架构适用于 PoC 或小规模场景，生产环境建议尽早引入集群化与高可用设计。
2.6 阶段小结
单体集群日志架构是日志平台建设的起点，其核心价值在于快速验证日志链路与降低初始复杂度。但该架构在可用性、扩展性、性能三方面存在天然缺陷：
- 无组件级冗余，单点故障即导致服务中断；
- 存储与计算资源绑定，无法独立扩展；
- 查询性能随数据量线性下降，缺乏优化手段。
下一阶段将引入多节点集群 + 副本分片 + 负载均衡，解决单点故障与写入瓶颈问题，进入高可用日志架构时代。