ELK

flowchart TD A["E — Elasticsearch 分布式搜索与分析引擎。 负责索引、查询、聚合、分片与副本等。"] B["L — Logstash 日志数据处理管道。 接收数据、解析格式、转换字段、过滤和输出。"] C["K — Kibana Elastic 生态中的可视化和分析界面。 搜索日志、制作图表、查看仪表盘、配置相关分析功能。"] A ~~~ B ~~~ C

日志系统架构图

通用的数据流模型：

flowchart TD A["日志产生端 Nginx · Go · Java · Linux · Kubernetes"] B["采集 Agent 读取文件、系统日志、容器输出"] C["Logstash / Collector (可选) 解析 · 转换 · 丰富 · 过滤"] D["Elasticsearch 索引 · 存储 · 查询 · 聚合"] E["Kibana 查询 · 图表 · Dashboard · 分析"] A --> B --> C --> D --> E

Elastic 经典参考架构：

flowchart LR B1[Filebeat] --> L[Logstash] B2[Metricbeat] --> L B3[Packetbeat] --> L L --> ES[Elasticsearch] ES --> K[Kibana]

Beats（采集） + Logstash（聚合/转换） + Elasticsearch（存储/检索） + Kibana（可视化）

这通常被称作为 ELK + Beats 架构（早期也叫 ELK Stack，现在官方统称 Elastic Stack）

具体实施思考

Beats 的细分？

我们可以看到官方给出了 6种 Beats

FileBeat
Metricbeat
Packetbeat
Winlogbeat
Auditbeat
Heartbeat

查找得知，经常使用的比如File、Metric、Packet

为什么需要 Logstash？

可能会想，既然用了 Beats，为什么不直接写到 ES中？

我认为是需要防止 ES被击垮，通过 Logstash作为多目标的输出、消息队列的缓冲

在其中进行复杂的正则解析、字段清洗

高可用、性能

既然作为多目标的输出，那就需要考虑高可用和性能

Logstash 的节点，ES 的规模，数据分片的策略

以及是否需要在 Logstash前面加上 Kafka 或 Redis作为缓冲，防止 Logstash 崩溃

ELK与分布式系统的关系

ELK 是分布式系统的“运行观测面”

之前学过类似这样的链路：

1
用户态
2
  ↓
3
系统调用
4
  ↓
5
Linux Kernel
6
  ↓
7
驱动 / 网络协议栈
8
  ↓
9
硬件 / 虚拟化层

而在生产系统中，另一条横向链路会贯穿它们：

1
系统运行
2
  ↓
3
产生事件 / 指标 / 日志
4
  ↓
5
采集与传输
6
  ↓
7
存储 / 索引
8
  ↓
9
查询 / 分析 / 告警
10
  ↓
11
运维人员定位问题

J i y ' s 数 字 花 園

ELK