ELK日志方案#

架构： 应用日志 → Filebeat(采集) → Logstash(解析/转换) → Elasticsearch(存储/索引) → Kibana(查询/可视化)

优化： Filebeat 替代 Logstash 采集(更轻) / Kafka 做缓冲(削峰) / ES 索引按天分割

ELK 是微服务场景下集中式日志方案的标配，由三个组件组成。Elasticsearch 负责日志的存储和全文检索，Logstash 负责日志的收集、解析和格式转换，Kibana 提供可视化查询界面。实际生产中我们做了几个优化：采集层用 Filebeat 替代 Logstash，因为 Filebeat 是 Go 写的，资源占用非常小，适合部署在每台应用服务器上做日志文件采集；Logstash 只放在中间层做解析和转换。日志量大的时候在 Filebeat 和 Logstash 之间加一层 Kafka 做缓冲削峰，防止突发日志洪峰把 ES 打垮。ES 的索引按天分割，方便做冷热数据分离和过期删除。日志采集也不是什么都采，按级别过滤，生产环境通常只采 WARN 和 ERROR 级别，DEBUG 和 INFO 按需开启。整个链路就是：应用日志文件 -> Filebeat 采集 -> Kafka 缓冲 -> Logstash 解析 -> ES 存储 -> Kibana 查询。

追问方向：

• “日志量很大怎么处理？”→ 前端按级别过滤（只采集 WARN 以上）、加 Kafka 做缓冲层削峰、ES 按天建索引+ILM 策略自动滚动删除冷数据、冷热分离（热节点 SSD 冷节点 HDD）
• “ELK 和 Loki 区别？”→ ELK 全文索引功能强大但资源消耗大（ES 需要大量内存和磁盘）；Loki 只索引标签不索引日志内容，存储成本低很多，适合 K8s 原生场景配合 Grafana 使用
• “怎么做日志告警？”→ ElastAlert 或 ES Watcher 基于 ES 查询结果触发告警（如 5 分钟内 ERROR 超 100 条）；也可在 Logstash/Filebeat 层做关键字匹配直接告警；告警渠道对接钉钉/飞书/PagerDuty

易错点：

• ❌ 所有日志都要采集——按级别采集
• ❌ ELK 很重不推荐——是大规模微服务标配