日志采集与 ELK：从本地日志到集中检索分析

日志采集与 ELK从本地日志到集中检索分析系统越简单日志越像一个附属品哪里出问题就登录机器看一眼。系统一旦拆成多个服务日志就会变成排查问题的入口。订单服务打了一行日志支付服务打了一行日志库存服务又打了一行日志如果这些日志散在不同机器上排查问题就会变成到处找文件。日志采集要解决的事很直接把分散在各台机器、各个容器、各个服务里的日志稳定地收集到统一平台让开发和运维可以按时间、关键字、服务名、traceId 快速检索和分析。一、为什么需要集中日志单机应用里日志一般写在本地文件/data/logs/order-service/info.log /data/logs/order-service/error.log常用命令tail-finfo.loggreporderId10086info.log但生产环境通常不是一台机器。这时会出现几个很真实的问题问题影响日志分散不知道请求打到哪台机器查询低效需要反复登录服务器权限混乱给开发开机器权限有风险日志易丢容器重启、机器下线可能导致日志不可查难以关联跨服务调用很难串起来集中日志平台的价值不只是把日志搬到一个地方。更重要的是把日志变成可检索、可聚合、可追踪的系统数据。二、ELK 分别负责什么ELK 通常指 Elasticsearch、Logstash、Kibana 三个组件。很多生产环境还会加 Filebeat所以也常被叫作Beats ELK或Elastic Stack。组件角色作用Elasticsearch存储和检索建索引、按条件搜索日志Logstash处理和转发接收日志、解析字段、过滤转换Kibana查询和展示搜索日志、配置图表、查看趋势如果只讲经典 ELK一条日志从应用到页面大致是这样走的但在真实项目里不太建议让每个 Java 应用都直接推 Logstash。更常见的方式是让Filebeat靠近日志文件或容器标准输出负责轻量采集和转发。简化方案Filebeat 直连 ES如果日志格式比较简单也可以让 Filebeat 直接写入 Elasticsearch标准方案Filebeat Logstash如果日志需要复杂解析、清洗、字段转换、路由分发就把 Logstash 放在中间实际项目里更常见的是Filebeat Logstash Elasticsearch Kibana。Filebeat 靠近业务机器负责轻量采集Logstash 放在日志链路中间负责重一点的处理逻辑。这样应用只管把日志写好采集链路单独演进耦合更低。三、Filebeat 和 Logstash 怎么选很多人第一次搭日志平台会把 Filebeat 和 Logstash 的职责混在一起。Filebeat轻量日志搬运工。部署在业务服务器或容器节点上监控指定日志文件把新增日志发送出去。不适合承担太复杂的处理逻辑。Logstash日志加工管道。接收多种输入经过 filter 做解析、转换、补充字段再输出到 Elasticsearch、Kafka 等地方。可以用一个简单判断场景建议只采集普通文本日志Filebeat 直连 Elasticsearch需要解析 JSON 字段Filebeat 或 Logstash 都可以需要多条件过滤和转换加 Logstash需要缓冲削峰中间可接 Kafka日志来源很多且格式复杂Logstash 更合适高并发系统里还会在采集链路中间加KafkaKafka 的作用不是必须的但它能把日志产生速度和日志处理速度解耦。短时间日志暴涨时先写入 Kafka后面的 Logstash 慢慢消费日志链路会更稳。代价是链路更长运维成本更高所以中小系统不必一开始就上 Kafka。四、应用日志应该怎么打日志平台好不好用一半取决于采集链路另一半取决于应用写日志的质量。最怕的是这种日志下单失败它对排查几乎没有帮助。失败的是哪个订单哪个用户哪个接口失败原因是什么都看不出来。更好的日志应该带上关键上下文create order failed, orderId10086, userId9527, skuId3001, reasonstock_not_enough如果是 Java 项目常见组合是Logback JSON 编码器把日志输出成结构化 JSON{timestamp:2026-06-08T10:15:30.12308:00,level:ERROR,service:order-service,traceId:a1b2c3d4,spanId:s1001,userId:9527,orderId:10086,message:create order failed,exception:StockNotEnoughException}结构化日志的好处字段用途timestamp按时间定位问题level区分 INFO、WARN、ERRORservice知道日志来自哪个服务traceId串起一次请求的完整链路userId定位用户维度的问题orderId定位业务对象exception快速聚合异常类型日志不是写得越多越好而是要让后来排查问题的人知道**“发生了什么、发生在哪、影响谁、为什么失败”**。五、traceId 是日志检索的生命线微服务排查问题时最重要的字段之一就是traceId。一次请求可能经过网关、订单、库存、优惠券、支付多个服务。如果没有统一标识每个服务的日志都像孤立的小片段。有了 traceId排查时只要在 Kibana 里搜索traceId:a1b2c3d4就能看到这次请求经过的所有服务日志。如果系统还接了链路追踪traceId 还可以和调用链详情关联起来——日志负责告诉你哪里报错链路追踪负责告诉你哪里慢、调用顺序是什么。六、本地日志命令仍然要会有了集中日志平台不代表本地命令就没用了。当日志采集延迟、平台不可用、临时排查机器问题时Linux 日志命令仍然非常重要。命令用法查看最新日志tail -f app.log查看最后 200 行tail -n 200 app.log查看文件开头head -n 50 app.log按关键字搜索grep orderId10086 app.log忽略大小写搜索grep -i exception app.log查看某段行号范围sed -n 1000,1100p app.log分页查看more app.log搜索结果输出到新文件grep ERROR app.log error.log追加输出grep timeout app.log timeout.log这些命令看起来基础但生产排查时非常管用。尤其是tail -f、grep、sed几乎是日志排查三件套。七、日志采集链路的关键配置日志采集不是把组件装起来就结束了还要关注几个关键点。1. 日志路径采集器必须知道日志在哪里。filebeat.inputs:-type:filestreamid:order-service-logpaths:-/data/logs/order-service/*.log容器环境里日志路径可能来自宿主机挂载目录也可能来自容器标准输出。不同部署方式要提前定好日志规范。2. 多行日志Java 异常堆栈通常是多行java.lang.RuntimeException: create order failed at com.example.OrderService.create(OrderService.java:35) at com.example.OrderController.create(OrderController.java:18)如果不处理多行合并异常堆栈会被拆成多条日志检索体验很差。3. 索引规划Elasticsearch 里日志一般按服务 环境 日期拆索引log-order-service-prod-2026.06.08设计好处按环境区分避免测试和生产混在一起按服务区分查询范围更小按日期区分方便冷热数据管理设置保留周期控制存储成本日志量大时索引生命周期管理很重要。不是所有日志都需要永久保存通常会按业务重要性保留 7 天、30 天、90 天或更久。4. 字段脱敏日志里不要打印密码、身份证号、银行卡号、Token、密钥。类型处理方式手机号保留前三后四身份证号只保留少量可定位片段密码禁止打印Token禁止打印或只打印摘要请求体敏感接口不要完整打印日志一旦进入集中平台访问面会变大。前面不脱敏后面再补权限控制成本会高很多。八、一套比较稳的落地方案中小规模系统高并发大规模系统更高并发、日志量更大的系统可以把 Kafka 放进来各环节职责环节重点应用打结构化日志带 traceIdFilebeat轻量采集保证日志送出去Kafka削峰和缓冲Logstash解析、清洗、补字段Elasticsearch索引、存储、检索Kibana搜索、展示、告警辅助九、常见坑日志采集平台最常见的坑不在于组件不会装而在于规范没定好。坑后果建议日志格式不统一字段无法检索统一 JSON 格式没有 traceId跨服务无法串联网关入口生成并透传ERROR 滥用告警噪声很大明确日志级别规范打印敏感信息安全风险日志输出前脱敏日志量无限增长存储成本失控设置保留周期多行异常未合并堆栈被拆散配置多行规则只采集不治理平台越用越乱定期清理索引和字段十、面试或方案设计怎么讲如果被问到日志采集怎么做不要只回答用 ELK。可以按这段话讲我们会先规范应用日志格式日志里必须包含时间、级别、服务名、traceId、业务主键和异常信息。应用通过 Logback 输出到本地文件Filebeat 负责采集日志。如果日志需要解析和清洗就发送到 Logstash再写入 Elasticsearch最后通过 Kibana 查询。日志量比较大时中间会接 Kafka 做缓冲避免日志高峰直接打爆后端。安全上会做敏感字段脱敏存储上会按服务、环境、日期建索引并设置保留周期。这比只说组件名要强很多因为它说清楚了数据怎么流、每个组件干什么、生产上有哪些风险点。总结日志系统不是为了看起来很完整而是为了让问题发生时能更快定位。一套好用的日志平台应该做到三件事一次请求能靠 traceId 串起来。一个异常能靠服务名、时间、业务主键快速定位。日志链路本身要稳定、安全、可控。做到这三点日志就不只是文件而是生产系统的黑匣子。