阶段二：多集群独立部署（烟囱式架构）
当业务线从 1 条扩展到 3～5 条时，集中式 ELK 开始出现性能争抢、索引模板冲突、权限混用等问题。此时最直接的解法是：每条业务线独立部署一套完整的 ELK 集群。这种模式在业界被称为“烟囱式架构”——每根烟囱独立运转，彼此之间没有数据共享，也没有统一的管理视图。
架构特征
| 维度 | 特征描述 |
|---|---|
| 部署粒度 | 每条业务线拥有独立的 Filebeat/Logstash → Elasticsearch → Kibana 链路 |
| 资源隔离 | 物理机或虚拟机完全隔离，不共享计算/存储资源 |
| 配置管理 | 索引生命周期、分片数、副本数、Mapping 各自独立配置 |
| 访问入口 | 每条业务线一个 Kibana URL，用户需记住多个地址 |
| 运维归属 | 各业务线自行维护，或由 SRE 团队按业务线分配专人 |
拓扑结构示意
下图展示了一个典型的 3 条业务线独立部署场景。每条业务线从采集到存储到展示完全独立，形成 3 套互不通信的 ELK 烟囱。
运维成本线性增长模型
烟囱式架构最直接的代价是运维成本与业务线数量呈线性关系。以下是一个基于 3 条业务线的成本测算示例：
| 成本项 | 单集群成本 | 3 集群总成本 | 增长趋势 |
|---|---|---|---|
| 服务器资源（节点数） | 6 节点（3 master + 3 data） | 18 节点 | O(n) |
| 运维人力（FTE） | 2 人 | 6 人 | O(n) |
| 监控告警配置 | 1 套（约 20 条规则） | 3 套（60 条规则） | O(n) |
| 备份/恢复策略 | 1 套脚本 | 3 套独立脚本 | O(n) |
| 版本升级 | 1 次滚动升级 | 3 次独立升级 | O(n) |
| Kibana 访问入口 | 1 个 URL | 3 个 URL | O(n) |
关键指标：当业务线从 1 条扩展到 5 条时，服务器节点数从 6 增长到 30，运维人力从 2 人增长到 10 人。每增加一条业务线，SRE 团队需要重复执行全部部署、配置、监控、备份流程。
典型痛点清单
- 无统一视图：每条业务线的日志只能在其专属 Kibana 中查看，跨业务线排障时需要切换多个页面，无法在一个屏幕上对比分析。
- 资源碎片化：每条业务线独立申请服务器，导致整体资源利用率偏低。例如业务线 A 的 ES 集群磁盘使用率 70%，而业务线 B 仅 30%，但无法互相借用。
- 配置碎片化：索引模板、ILM 策略、Mapping 结构各自维护，缺乏统一规范。同一字段在不同业务线可能使用不同的数据类型，给后续数据整合带来困难。
- 版本碎片化：各业务线可能在不同时间点部署，导致 Elasticsearch 版本不统一（如 7.10、7.17、8.5 混用），增加安全补丁和版本升级的复杂度。
- 权限管理分散：每条业务线独立管理用户和角色，没有统一的 LDAP/SSO 对接，用户需要记忆多套账号密码。
何时应该考虑进入下一阶段？
当出现以下任一信号时，说明烟囱式架构已经到达瓶颈，需要向统一平台演进：
- 业务线数量超过 5 条，运维人力成本占比超过团队总人力的 40%
- 跨业务线排障场景每周出现 3 次以上，每次需要登录 3 个以上 Kibana 实例
- 服务器总节点数超过 30，但整体资源利用率低于 50%
- 因版本不一致导致的安全漏洞修复周期超过 2 周
经验建议：烟囱式架构并非完全不可取。对于强合规要求（如金融、医疗）的业务线，独立部署仍然是满足数据隔离审计的必要手段。但在非强合规场景下，建议在业务线达到 3～5 条时提前规划统一平台，避免后期大规模迁移的阵痛。