ELK Stack 整体架构与数据流
想象一下，你运营着一个日活 100 万的电商平台。突然，用户开始抱怨系统慢，你如何在海量日志中找到问题所在？
ELK Stack 就是来解决这个问题的——它让你能从海量数据中快速发现问题的真相。
1. ELK Stack 是什么？
ELK Stack 是三个开源工具的组合：
┌─────────────────────────────────────────────────────────────┐
│ ELK Stack │
│ │
│ ┌─────────┐ ┌─────────┐ ┌─────────┐ │
│ │Elastic- │ │Logstash │ │ Kibana │ │
│ │search │ ← │ │ ← │ │ │
│ │ 存储+搜索 │ │ 数据处理 │ │ 可视化 │ │
│ └─────────┘ └─────────┘ └─────────┘ │
│ ↑ │
│ │ │
│ ┌─────┴─────┐ │
│ │ Beats │ ← 轻量级采集器 │
│ │ (Filebeat) │ │
│ └───────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘组件说明：
| 组件 | 全称 | 作用 |
|---|---|---|
| Elasticsearch | ES | 存储、搜索、分析 |
| Logstash | LS | 数据收集、处理、转换 |
| Kibana | KB | 数据可视化 |
| Beats | - | 轻量级数据采集 |
2. 数据流架构
┌─────────────────────────────────────────────────────────────────┐
│ 数据流架构 │
│ │
│ 日志源 │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
│ │ 应用日志 │ │ 系统日志 │ │ 网络日志 │ │
│ └─────┬────┘ └─────┬────┘ └─────┬────┘ │
│ │ │ │ │
│ └───────┬───────┴───────┬─────┘ │
│ │ │ │
│ ┌──────▼──────┐ ┌─────▼─────┐ │
│ │ Filebeat │ │ Metricbeat │ │
│ │ 轻量级采集 │ │ 指标采集 │ │
│ └──────┬──────┘ └─────┬─────┘ │
│ │ │ │
│ └───────┬───────┘ │
│ │ │
│ ┌────▼────┐ │
│ │ Kafka │ ← 消息队列（可选） │
│ └────┬────┘ │
│ │ │
│ ┌────▼────┐ │
│ │ Logstash │ ← 数据处理 │
│ └────┬────┘ │
│ │ │
│ ┌────▼────┐ │
│ │ Elastic │ │
│ │ search │ ← 数据存储 │
│ └────┬────┘ │
│ │ │
│ ┌────▼────┐ │
│ │ Kibana │ ← 数据可视化 │
│ └─────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘3. 轻量级架构（Beats 直连）
适合小规模场景，数据直接从 Beats 到 ES：
┌──────────────────────────────────────────┐
│ 轻量级架构（Beats 直连） │
│ │
│ Filebeat ──┐ │
│ │ │
│ Metricbeat ─┼──→ Elasticsearch ──→ Kibana│
│ │ │
│ Heartbeat ─┘ │
│ │
└──────────────────────────────────────────┘适用场景：
- 小规模部署（< 5 台服务器）
- 日志量较小（< 10GB/天）
- 不需要复杂的数据处理
4. 标准架构（Beats + Logstash + ES + Kibana）
适合中等规模，需要数据处理：
┌─────────────────────────────────────────────────────────────────┐
│ 标准架构（Beats + Logstash + ES + Kibana） │
│ │
│ ┌─────────────┐ │
│ │ Beats │ ← 轻量级采集 │
│ │(Filebeat等) │ │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Logstash │ ← 数据处理、转换、过滤 │
│ │ (集群) │ │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │Elasticsearch│ ← 数据存储、搜索 │
│ │ (集群) │ │
│ └──────┬──────┘ │
│ │ │
│ ▼ │
│ ┌─────────────┐ │
│ │ Kibana │ ← 可视化 │
│ │ │ │
│ └─────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘适用场景：
- 中等规模部署
- 需要数据解析、过滤、富化
- 需要多数据源汇聚
5. 高可用架构（引入 Kafka）
适合大规模、高并发场景：
┌─────────────────────────────────────────────────────────────────┐
│ 高可用架构（引入 Kafka） │
│ │
│ 数据源 │
│ ┌───────┐ ┌───────┐ ┌───────┐ │
│ │Server1 │ │Server2 │ │Server3 │ │
│ └───┬───┘ └───┬───┘ └───┬───┘ │
│ │ │ │ │
│ ┌───▼───┐ ┌───▼───┐ ┌───▼───┐ │
│ │Filebeat│ │Filebeat│ │Filebeat│ │
│ └───┬───┘ └───┬───┘ └───┬───┘ │
│ └──────────┼──────────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ Kafka │ ← 缓冲、削峰 │
│ │ (集群) │ │
│ └─────┬─────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ Logstash │ ← 消费、处理 │
│ │ (消费者组) │ │
│ └─────┬─────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │Elasticsearch│ │
│ │ (集群) │ │
│ └─────┬─────┘ │
│ │ │
│ ┌─────▼─────┐ │
│ │ Kibana │ │
│ └────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────┘Kafka 的作用：
- 缓冲：削峰填谷，吸收突发流量
- 解耦：生产者和消费者分离
- 可靠：消息持久化，保证数据不丢失
- 扩展：可以增加多个 Logstash 消费者并行处理
6. 完整数据流详解
6.1 日志采集阶段
数据采集流程：
1. 日志文件被写入磁盘
2. Filebeat 监控文件变化
3. 读取新日志行
4. 添加元数据（主机名、路径等）
5. 发送到目标6.2 数据处理阶段
Logstash 处理流程：
1. 接收 Beats 发送的数据
2. Filter 处理
├─→ Grok：解析日志格式
├─→ JSON：解析 JSON
├─→ Date：转换时间
├─→ GeoIP：添加地理位置
└─→ Mutate：字段转换
3. 输出到 ES6.3 数据存储阶段
ES 存储流程：
1. 写入请求到协调节点
2. 根据 routing 计算目标分片
3. 写入主分片
4. 同步到副本
5. 返回确认6.4 数据可视化阶段
Kibana 可视化流程：
1. 用户访问 Kibana
2. 编写查询（KQL）
3. 发送到 ES
4. ES 执行搜索/聚合
5. Kibana 渲染图表7. 组件对比
7.1 日志采集器对比
| 特性 | Filebeat | Logstash | Fluentd |
|---|---|---|---|
| 资源占用 | 低 | 高 | 中 |
| 数据处理 | 无 | 丰富 | 丰富 |
| 插件生态 | 有限 | 丰富 | 丰富 |
| 部署复杂度 | 低 | 中 | 中 |
| 支持协议 | ES, Logstash, Kafka | 多种 | 多种 |
7.2 数据处理对比
| 特性 | Logstash | Ingest Node | Beats Filter |
|---|---|---|---|
| 处理能力 | 强 | 中 | 弱 |
| 资源消耗 | 高 | 中 | 低 |
| 部署位置 | 独立集群 | ES 节点 | 采集端 |
| 延迟 | 中 | 低 | 极低 |
8. 容量规划
8.1 集群规划参考
| 数据量/天 | ES 节点 | Logstash | Kafka | 场景 |
|---|---|---|---|---|
| < 10GB | 3 | 1 | - | 测试/小规模 |
| 10-100GB | 5-10 | 2-3 | 可选 | 中等规模 |
| 100-500GB | 10-20 | 4-8 | 推荐 | 大规模 |
| > 500GB | 20+ | 8+ | 必须 | 超大规模 |
8.2 硬件配置参考
| 角色 | CPU | 内存 | 磁盘 | 说明 |
|---|---|---|---|---|
| ES Data Node | 8核+ | 32GB+ | SSD 500GB+ | 数据存储 |
| ES Master Node | 4核 | 16GB | - | 集群管理 |
| Logstash | 8核+ | 16GB+ | - | 数据处理 |
| Kibana | 4核 | 8GB | - | 可视化 |
| Kafka Broker | 8核+ | 16GB+ | SSD 1TB+ | 消息队列 |
9. 监控与运维
9.1 监控指标
关键监控指标：
Elasticsearch：
├─ 集群健康状态（green/yellow/red）
├─ 节点状态
├─ 分片分布
├─ 写入吞吐量
├─ 查询延迟
└─ JVM 内存使用
Logstash：
├─ Pipeline 吞吐量
├─ 事件处理延迟
├─ 队列堆积
└─ JVM 内存使用
Beats：
├─ 发送成功率
├─ 采集延迟
└─ 文件处理状态9.2 告警配置
常见告警：
├─ ES 集群不健康
├─ 节点离线
├─ 磁盘空间不足
├─ 写入拒绝
├─ Logstash 队列堆积
└─ Beats 采集失败10. 架构演进建议
架构演进路径：
阶段一：小规模（< 10GB/天）
└─→ Beats 直连 ES + Kibana
阶段二：中等规模（10-100GB/天）
└─→ 添加 Logstash 处理
└─→ 添加 Kafka 缓冲
阶段三：大规模（100GB+/天）
└─→ 多 Logstash 消费者
└─→ 冷热分离架构
└─→ ILM 生命周期管理总结
ELK Stack 的核心价值：
- 数据采集：Beats 负责轻量级采集
- 数据处理：Logstash 负责数据转换
- 数据存储：ES 负责存储和搜索
- 数据可视化：Kibana 负责展示
架构选择原则：
- 小规模：Beats 直连 ES
- 中等规模：添加 Logstash
- 大规模：引入 Kafka 作为缓冲
留给你的问题：
假设你的公司从单体应用迁移到微服务架构，日志量从 10GB/天增长到 200GB/天。
当前的 ELK 架构会出现什么问题？你会如何演进架构？
需要考虑：
- 数据采集如何扩展？
- 数据处理能力如何提升？
- 如何保证高可用？