服务一多，日志就成了噩梦。十台机器，每台一个catalina.out，排查问题靠grep加 SSH，效率极低。ELK 正是为解决这个问题而生——把分散的日志集中采集、存储、检索和可视化。本文从 SpringBoot 出发，带你从零完成 ELK 整合，并给出进阶实践。
一、ELK 各组件职责
ELK 是三个开源组件的缩写：Elasticsearch负责存储和全文检索，Logstash负责日志的过滤和转换，Kibana负责可视化查询。实际生产中通常还会加入Filebeat，它是一个轻量级采集器，部署在应用服务器上，把日志推给 Logstash 或直接推给 Elasticsearch，比 Logstash 更省资源。
典型链路：SpringBoot 应用 → Filebeat → Logstash → Elasticsearch → Kibana。
二、SpringBoot 端：输出结构化日志
ELK 检索的前提是日志结构化。传统文本日志需要 Logstash 用正则解析，成本高且易出错。更好的做法是让 SpringBoot 直接输出 JSON。
引入依赖：
<dependency> <groupId>net.logstash.logback</groupId> <artifactId>logstash-logback-encoder</artifactId> <version>7.4</version> </dependency>
在logback-spring.xml中配置 JSON 输出：
<appender name="JSON" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="net.logstash.logback.encoder.LogstashEncoder"> <includeMdcKeyName>traceId</includeMdcKeyName> </encoder> </appender> <root level="INFO"> <appender-ref ref="JSON"/> </root>
这样每条日志都是标准 JSON，包含时间戳、级别、类名、线程、消息以及 MDC 中的traceId。结合 Sleuth 或 SkyWalking，还能把链路追踪 ID 一并输出，排查跨服务问题非常方便。
三、Filebeat 与 Logstash 配置
Filebeat 配置极简，只需指定日志路径和输出目标：
filebeat.inputs: type: filestream paths: /var/log/app/.log output.logstash: hosts: ["logstash:5044"]
Logstash 接收后做基础处理，比如增加环境标签、剔除多余字段：
input { beats { port => 5044 } } filter { mutate { add_field => { "env" => "prod" } } } output { elasticsearch { hosts => ["http://es:9200"] index => "springboot-%{+YYYY.MM.dd}" } }如果日志已经是 JSON，Logstash 可以直接用json过滤器解析，无需正则。
四、Kibana 可视化
启动 Kibana 后，在 Stack Management 中创建索引模式springboot-，选择@timestamp作为时间字段。之后就能在 Discover 中按级别、类名、traceId 过滤日志。更进一步，可以创建仪表盘：统计 ERROR 数量趋势、按服务分布、慢请求 TOP 列表。配合告警功能，ERROR 突增时自动通知。
五、进阶与避坑
性能：Logstash 较重，高并发下容易成为瓶颈。可用 Filebeat 直接写 Elasticsearch，或引入 Kafka 做缓冲削峰。索引管理：日志量大，务必配置 ILM（索引生命周期管理），按天滚动、定期删除，避免磁盘打满。字段映射：提前定义模板，避免 Elasticsearch 动态映射把数字字段解析成 text。安全：生产环境开启 X-Pack 认证，Kibana 不要裸奔在公网。
结语
ELK 整合并不复杂，难的是稳定运行和成本控制。入门只需跑通链路，精通则要关注采集性能、索引策略和告警闭环。把日志当成数据来治理，而不是事后才想起的文本文件，这才是 ELK 真正的价值。
