ELK日志方案#

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

优化： Filebeat 替代 Logstash 采集(更轻) / Kafka 做缓冲(削峰) / 索引生命周期管理（老做法按天建索引；现在推荐 data stream + ILM，按大小/时间自动 rollover）

现状（Elastic Stack 9.x）：

• Filebeat 的 log input 7.16 起废弃、9.0 起默认禁用，改用 filestream input
• Elastic 官方新接入更推荐 Elastic Agent（Fleet 统一管理），且已内置 EDOT（Elastic 发行版 OpenTelemetry Collector，用 filelog receiver 采日志）；Beats 仍可用
• 日志采集整体在向 OpenTelemetry 靠拢：OTel Collector 采集后可发往 ES、Loki 等任意后端

ELK 是微服务场景下集中式日志方案的标配，由三个组件组成。Elasticsearch 负责日志的存储和全文检索，Logstash 负责日志的收集、解析和格式转换，Kibana 提供可视化查询界面。实际生产中我们做了几个优化：采集层用 Filebeat 替代 Logstash，因为 Filebeat 是 Go 写的，资源占用非常小，适合部署在每台应用服务器上做日志文件采集；Logstash 只放在中间层做解析和转换。日志量大的时候在 Filebeat 和 Logstash 之间加一层 Kafka 做缓冲削峰，防止突发日志洪峰把 ES 打垮。索引按时间滚动（以前按天建索引，现在更推荐 data stream + ILM 按大小/时间自动 rollover），方便做冷热数据分离和过期删除。日志采集也不是什么都采：DEBUG 默认不采，INFO 量大时做采样或缩短保留期，WARN/ERROR 全量保留。另外新接入可以考虑 Elastic Agent 或 OpenTelemetry Collector 替代单独部署的 Filebeat。整个链路就是：应用日志文件 -> Filebeat 采集 -> Kafka 缓冲 -> Logstash 解析 -> ES 存储 -> Kibana 查询。

追问方向：

• “日志量很大怎么处理？”→ 采集端按级别过滤/采样（DEBUG 不采、INFO 采样或短保留）、加 Kafka 做缓冲层削峰、data stream + ILM 策略自动 rollover 并删除过期数据、冷热分离（热节点 SSD 冷节点 HDD）
• “ELK 和 Loki 区别？”→ ELK 全文索引功能强大但资源消耗大（ES 需要大量内存和磁盘）；Loki 只索引标签不索引日志内容，存储成本低很多，适合 K8s 原生场景配合 Grafana 使用
• “怎么做日志告警？”→ Kibana 告警规则（Alerting，官方主推）或 Watcher 基于 ES 查询结果触发告警（如 5 分钟内 ERROR 超 100 条）；开源方案用 ElastAlert 2（原 Yelp ElastAlert 已停止维护）；也可在 Logstash 用 filter 匹配关键字再经 http/email output 直接告警；告警渠道对接钉钉/飞书/PagerDuty

易错点：

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