EFLK 日志收集系统
EFLK = ElasticSearch + Filebeat + Logstash + Kibana
它是经典 ELK（ElasticSearch + Logstash + Kibana）的改进版，
E 表示 ElasticSearch，F 表示 Filebeat，L 表示 Logstash，K 表示 Kibana。
通常 EFLK 与 ELFK（ElasticSearch + Filebeat + Kafka + Logstash + Kibana）都是日志系统常用缩写。
核心思想：
- Filebeat：轻量级高效日志采集器（替代 Logstash 在边缘节点的作用）
- Logstash：负责数据清洗、解析、标准化
- ElasticSearch：存储和搜索日志数据
- Kibana：可视化、查询、告警
相比最原始 ELK：
- 性能更高（Filebeat 比 Logstash 轻几十倍）
- 资源消耗更低（Filebeat 占用内存 CPU 极小）
- 架构更清晰（采集 - 传输 -> 清洗 -> 存储）
+------------------+
| Filebeat | <- 采集日志
| (轻量级 Agent) |
+------------------+
|
v
+------------------+
| Logstash | <- 解析、清洗、转换结构化
| filter + codec |
+------------------+
|
v
+---------------------------+
| ElasticSearch | <- 存储 + 检索 + 聚合
+---------------------------+
|
v
+---------------------------+
| Kibana | <- 分析 + 可视化 + 告警
+---------------------------+
如果你的业务量更大，可以扩展为：
Filebeat -> Kafka -> Logstash -> ElasticSearch -> Kibana
- 只负责日志收集，速度快、资源少
- 支持多种模块：nginx, mysql, system, redis, docker
- 能自动检测日志滚动
- 可以输出到 Logstash、Kafka、Redis、ES
适合部署到每台业务服务器。
- 解析、格式化日志（grok、json、mutate）
- 转换结构化内容
- 数据过滤规则集中管理
- 比 Filebeat 功能更强、但更重
推荐：前端用 Filebeat，集中使用 Logstash 清洗
- 分布式存储日志
- 可横向扩容
- 高性能全文搜索
- 聚合分析（统计/趋势/分布）
日志通常按：
- index lifecycle（hot-warm-cold）
- daily index（如 logs-2025.02.20）
管理生命周期。
- ES 的可视化门户
- Dashboard
- 监控（APM / Metrics）
- 告警（Watcher / Kibana Alerting）
⭐ 推荐架构（中大型集群）
Filebeat (业务机器)
|
v
Kafka （可选，提高缓冲能力）
|
v
Logstash（2-3 节点）
|
v
ElasticSearch 集群（Hot/Warm）
|
v
Kibana
若日志量不大（<100GB/day），可以直接：
Filebeat -> Logstash -> ElasticSearch
filebeat.yml
filebeat.inputs:
- type: log
paths:
- /var/log/nginx/*.log
output.logstash:
hosts: ["logstash01:5044", "logstash02:5044"]
logstash.conf
input {
beats {
port => 5044
}
}
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
date {
match => [ "timestamp", "dd/MMM/YYYY:HH:mm:ss Z" ]
}
}
output {
elasticsearch {
hosts => ["http://es01:9200"]
index => "nginx-%{+YYYY.MM.dd}"
}
}
PUT _ilm/policy/logs-ilm
{
"policy": {
"phases": {
"hot": {
"actions": { "rollover": { "max_size": "40GB" }}
},
"warm": {
"min_age": "7d",
"actions": {
"allocate": { "number_of_replicas": 0 },
"forcemerge": { "max_num_segments": 1 }
}
},
"delete": {
"min_age": "30d",
"actions": { "delete": {} }
}
}
}
}
Filebeat 自动模块。
模块解析 + 自带 Dashboard。
Filebeat 自动采集容器 JSON。
Elastic APM 可直接接入。
配合 Elastic SIEM。
防止 Logstash 单点。
pipeline.workers = CPU核心数
每分片控制在 20–50GB 最佳。
自动滚动、压缩、删除。
如：
- 500 错误率超过 1%
- 登录失败暴增
- 服务响应时间过高
在 Filebeat -> Kafka -> Logstash -> ElasticSearch -> Kibana（EFLK/EFKL） 这条日志链路中，Kafka 的职责非常关键，但又非常专一：负责“日志缓冲、削峰、解耦、持久化、高可用”。
Filebeat 发送日志时，可能遇到：
- 短时间日志量暴增（流量洪峰）
- Logstash 重启或处理能力不足
- ElasticSearch 集群出现写入拥塞
Kafka 可以作为“超大容量的蓄水池”吸收所有日志，即使下游暂时不可用，日志也不会丢。
👉 没有 Kafka，日志高峰时 Logstash/ES 会被压垮。
在没有 Kafka 的 ELK 中：
- Filebeat -> Logstash：强依赖
- Logstash -> ES：强依赖
一旦其中一个组件挂了，链路就断了。
引入 Kafka 后：
Filebeat -> Kafka （不关心 Logstash 是否存活）
Logstash -> Kafka （不关心 Filebeat 是否存活）
组件间完全异步，互不影响。
Kafka 是分布式日志存储系统：
- 日志写入后复制到多个副本
- 即使节点挂了，数据依旧存在
- 即使 ES 或 Logstash 挂了一天，日志也不会丢
文件日志 -> Kafka -> 下游，真正实现“零日志丢失”。
Kafka 允许 Logstash 以自己的节奏消费：
- 流量高峰：积压在 Kafka
- 流量恢复：Logstash 逐步消费
这是一种流量“柔性处理机制”，保证下游稳定。
Kafka 支持：
- 多分区（partition）高吞吐
- 多 Logstash 共享消费组消费（负载均衡）
适合大型系统日志量级：百万条/秒。
如果后续需要重新建索引、迁移 ES、修复解析问题，可以：
重新消费 Kafka Topic，从头解析日志
在没有 Kafka 的 ELK 中，这几乎不可能。
Kafka 给日志系统带来了“可回放性”。
一个分区内日志的顺序是严格保证的。
适合：
- 单服务单实例日志
- 业务事件流
- 依赖顺序的审计日志
有了 Kafka 后：
- Logstash 消费 -> ES
- Flink 消费 -> 实时分析
- ClickHouse 消费 -> 历史归档
- 消费者服务 -> 告警系统
Kafka 变成日志数据总线。
Kafka 是日志系统的“分布式缓冲层 + 持久队列 + 解耦中心”，负责吸收流量、保证稳定性、避免日志丢失、让下游可以按需消费、实现水平扩展与多路分发。