2. ELK 架构基础回顾：组件职责与数据流转
在深入成本优化之前，必须统一团队对 ELK 核心架构的认知。本章从组件职责、数据写入与检索流程两个维度，建立后续 Golden Signals 指标分析与存储策略优化的共同语言。
2.1 四大核心组件职责
| 组件 | 全称 | 核心职责 | 部署形态 |
|---|---|---|---|
| Beats | Elastic Beats | 轻量级数据采集器，负责从服务器、容器、应用捕获日志/指标/网络数据 | Agent 端，无状态 |
| Logstash | Logstash | 数据管道引擎，负责解析、过滤、转换、丰富日志数据 | 独立服务，可集群 |
| Elasticsearch | Elasticsearch | 分布式搜索与分析引擎，负责数据存储、索引、检索、聚合 | 集群，有状态 |
| Kibana | Kibana | 可视化与管控平台，负责数据探索、仪表盘、告警、索引管理 | Web 服务，无状态 |
成本视角提示： Elasticsearch 是存储成本的核心载体，Beats 和 Logstash 主要影响网络与计算成本。理解各组件在数据生命周期中的位置，是定位成本瓶颈的第一步。
2.2 数据写入流程（端到端）
一条日志从产生到可检索，经历以下关键阶段：
- 采集（Beats）：Filebeat 读取日志文件行，添加元数据（host、timestamp），发送到 Logstash 或直接写入 Elasticsearch。
- 解析与过滤（Logstash）：通过
grok、mutate、date等插件解析非结构化日志，丢弃无用字段，标准化时间戳。 - 缓冲与传输：Logstash 内部使用内存或持久队列（
queue.type: persisted）缓冲数据，防止背压导致数据丢失。 - 索引与分片（Elasticsearch）：数据到达 ES 节点后，根据索引模板映射字段类型，写入主分片并同步副本分片。
- 刷新与提交：默认每秒刷新（refresh_interval=1s）使新数据可检索，同时触发 translog 提交保证持久性。
写入路径简化示意：
App Log → Filebeat → Logstash（解析/过滤）→ Elasticsearch（索引/分片）→ 可检索
2.3 数据检索流程
用户通过 Kibana 或 API 发起查询时，检索路径如下：
- 查询入口：Kibana 将用户输入的 DSL 查询发送到 Elasticsearch 协调节点。
- 协调节点分发：协调节点解析查询，向所有相关分片（主分片或副本分片）广播请求。
- 分片级查询：每个分片执行 Lucene 索引搜索，返回匹配文档 ID 及评分。
- 结果合并：协调节点合并各分片返回的 Top N 结果，再次从分片拉取完整文档数据。
- 返回展示：最终结果返回 Kibana，渲染为表格、图表或日志流。
检索成本陷阱： 查询涉及的分片数越多，协调节点合并开销越大。大量跨分片查询会显著增加 CPU 和内存消耗，间接推高集群资源成本。后续章节将讨论如何通过索引生命周期管理（ILM）和分片策略控制检索范围。
2.4 组件间通信协议与端口
| 组件对 | 协议 | 默认端口 | 说明 |
|---|---|---|---|
| Beats → Logstash | Lumberjack / HTTP | 5044 / 5000 | Beats 默认使用 Lumberjack 协议保证可靠传输 |
| Beats → Elasticsearch | HTTP / HTTPS | 9200 | 直接写入模式，跳过 Logstash |
| Logstash → Elasticsearch | HTTP / HTTPS | 9200 | 批量写入，可配置压缩 |
| Kibana → Elasticsearch | HTTP / HTTPS | 9200 | 查询与管控接口 |
| Elasticsearch 节点间 | Transport | 9300 | 集群内部通信、分片复制、选举 |
成本优化关联： 压缩传输（如 Logstash 配置
http.compression: true）可减少网络带宽消耗；直接写入模式（Beats → ES）可降低 Logstash 计算成本，但会失去数据过滤能力，需在 ES Ingest Pipeline 中补偿。