分布式日志系统实战：从ELK到Kafka的搭建与排坑指南

1. 一次故障排查，让我决定把日志系统翻个底朝天

先说个真实经历。当时我们一个核心交易服务上了三个实例，前端页面突然报系统繁忙，我登录服务器看日志，先得在十来个日志文件里翻找——业务日志、错误日志、接口访问日志混着来，而且分布在不同的机器上。我首先定位到一台机器的错误日志，结果发现异常只出现在其中一台，另外两台完全正常，但页面报错是全局的。后来折腾了一个多小时才搞明白：某个接口在凌晨的定时任务里把数据库连接池打满了，异常会在三台机器间随机触发，可我只有一台一台地进服务器、一条一条地grep，效率低到让人崩溃。

那次之后我就下决心，必须要有一套分布式日志系统。

其实"分布式日志系统"这个概念很宽泛。对于小团队来说，最简单的形态可能就是日志集中收集到一个地方，统一检索。但如果你真正在微服务架构下跑过，就会发现这事远远不止"收集"这么简单——它涉及日志的采集、传输、缓冲、解析、存储、检索、告警，链路非常长，每个环节都有坑。这篇文章我把从零搭建到稳定运行的全过程写出来，包括技术选型时的几次纠结、实际部署中的具体配置、以及后续踩过的各种坑，希望能帮准备上手的人省点时间。

文章主要面向后端开发、运维和架构师，尤其是那些服务已经拆成多个模块、日志已经开始"满天飞"的团队。如果你现在还能通过tail -f定位问题，可能暂时不需要；但只要你经历一次"日志散落在十几台机器上，宕机了只能一台一台上去查"的夜晚，你会回来把它看完的。

2. 选型阶段：ELK、EFK、Loki，到底选哪套

选型是整个项目里最容易被低估的一步。很多人一上来就想着 "上ELK"，但ELK只是Elastic技术栈（Elasticsearch、Logstash、Kibana）的缩写，实际生产环境很少只用这套就够。我把自己对比过的方案列一下，方便你根据自己团队的情况做判断。

2.1 三套主流方案的优劣势对比

方案	核心组件	优势	劣势	适合场景
ELK	Filebeat + Logstash + Elasticsearch + Kibana	生态成熟、检索能力强、Kibana可视化丰富	Logstash消耗资源较高、全链路较重量级	中大型团队，日志量大，检索需求复杂
EFK	Fluentd/Fluent Bit + Elasticsearch + Kibana	Fluentd轻量、插件丰富、内存占用低	配置语法学习成本高、部分插件维护一般	容器环境、K8s集群日志收集
Loki + Promtail + Grafana	Promtail + Loki + Grafana	基于标签索引、存储成本极低、和Prometheus联动好	全文检索能力弱、日志量大时查询慢	以监控告警为主、对日志检索深度要求不高的场景

我当时纠结的是ELK和Loki。

我们团队业务里有很多需要按关键字定位问题、按时间范围聚合统计、甚至结合业务字段（比如订单号、用户ID）去查日志的场景。Loki的索引机制是基于标签的，它不索引日志内容本身，查询是"先按标签过滤，再暴力扫描"，对于"根据订单号搜索完整请求链路"这种需求，性能会跟不上。虽然Loki在成本上极其诱人（存储占用大概是Elasticsearch的十分之一），但我还是选择了ELK生态。

2.2 为什么我最终选择了ELK + Kafka的架构

选ELK还有个重要原因是团队梯队问题。Elasticsearch、Kibana、Logstash的用户基数大，社区资料多，新人上手成本低；Fluentd虽然好，但遇到问题能搜到的中文资料、踩坑记录明显少一些。考虑到后面不止我一个人要维护这套系统，选更主流的技术栈，长期看是更稳的决策。

但我也没完全照搬"三件套"，而是加了Kafka作为消息缓冲层。原因很简单：日志是写密集型场景，业务高峰期每秒钟产生的日志量可以轻松超过上千条。如果让Filebeat直接往Elasticsearch里灌，Elasticsearch的写入压力会非常大，还可能出现写入拒绝的报错，日志就丢了。加一个Kafka之后，采集端和存储端之间就有了一个缓冲期，即使Elasticsearch短暂抖动，日志也能先在Kafka里排队，不会马上丢。

再加上Kafka的分区机制天然支持多消费者并行消费，后面无论是接Logstash做清洗，还是接实时告警计算，都可以从Kafka里拉数据，一套日志流可以同时喂给多条下游管道，非常灵活。

2.3 各组件在链路中的定位

先说清楚每个组件干啥，后面讲配置时你才能理解每个参数存在的意义：

• Filebeat：轻量级采集器，部署在业务机器上，负责读日志文件、把日志发给Kafka。它比Logstash轻得多，Go写的，内存占用通常在几十MB级别，适合作为监控采集Agent大批量部署。
• Kafka：消息缓冲与分发枢纽。承接Filebeat上报的日志流，下游多个消费者各取所需。它的存在让日志系统在高并发下不丢数据、不阻塞。
• Logstash：日志解析与清洗中心。从Kafka消费日志，把非结构化的文本解析成结构化JSON，按需要做字段拆分、类型转换、过滤丢弃，然后写入Elasticsearch。
• Elasticsearch：分布式存储与检索引擎。所有日志最终落在这里，支撑全文检索、聚合分析。
• Kibana：可视化面板。支持搜索日志、做Dashboard大盘、设置告警规则，是日常排查问题的入口。

一句话总结这个架构的流动路径：业务日志 → Filebeat → Kafka → Logstash → Elasticsearch → Kibana。后面所有的工作，都是围绕这条链路的每一环去优化。

3. 核心链路拆解：日志从产生到你看得见的完整旅程

在动手部署之前，把链路里每个环节的原理和细节搞透，比急着跑起来重要得多。下面按日志流动的顺序，把每一段的原理和关键配置讲清楚。

3.1 采集端：Filebeat如何做到"轻量又不漏"

日志采集最怕两件事：一是Agent本身太耗资源，影响业务机器；二是日志产生太快，Agent来不及读，或者文件已经被轮转删掉了，日志就丢了。

Filebeat在这两方面的设计都挺靠谱的。

它内部有几个关键状态：registry文件记录了每个文件当前读取的偏移量（offset）。就算Filebeat进程重启、机器重启，它也会从registry记录的offset继续读，不会从头重发，也不会漏掉中间那一段。这个特性在你日常重启Agent或者发布业务版本时特别重要。

另一个容易被忽略的配置是multiline。很多业务日志是堆栈异常，一个异常跨好几行，如果按行采集，一个堆栈就会被拆成无数条"碎片"日志，根本无法阅读。必须用多行合并规则把属于同一条日志的多行内容拼接成一条完整记录：

filebeat.inputs: - type: filestream enabled: true paths: - /data/logs/order-service/*.log fields: app_name: order-service env: prod fields_under_root: true parsers: - multiline: type: pattern pattern: '^[0-9]{4}-[0-9]{2}-[0-9]{2}' negate: true match: after

注意这个配置的含义：pattern指定一行日志开始的特征，我这里用的是"以日期开头"。negate: true表示不匹配该模式的行，match: after表示把它们合并到前一条的后面。这样Java堆栈里的每一行（以空格或tab开头）都会被拼接到上一条日志中，整个堆栈成为一条完整记录。

实测下来，多行规则的正则要严格匹配你日志行首的格式。如果日志行首是时间戳像2025-06-14 10:00:00，那正则就得写对格式。很多团队在这省事，结果Kibana里一堆被"大卸八块"的堆栈日志，查问题反而更费劲。

3.2 缓冲层：为什么非要用Kafka，直接写ES不行吗

我见过不少团队最初是Filebeat直接输出到Elasticsearch的，日志量小的时候确实没毛病，但到了高峰期就出问题。

核心原因是Elasticsearch的写入能力受限于分片数、硬件配置、索引刷新频率等因素，索引刷新默认refresh_interval是1秒。如果你持续以高并发往Elasticsearch灌数据，集群的CPU和IO会很快被拉高，查询性能跟着下降。而且一旦Elasticsearch出现GC卡顿或节点故障，Filebeat重试队列一旦积压，就会反过来拖累业务机器。

Kafka作为夹在中间的缓冲层，解决的是生产速度和消费速度不匹配的问题。你只管往Kafka写，Kafka的写入性能极高，吞吐量可以达到每秒几十万条。下游Logstash要想多慢就多慢，慢慢消费、慢慢清洗，完全不会影响采集端。与此同时，Kafka消息可以保留一段时间（默认7天），如果下游管道出了故障，修复回来后数据还在，可以追数据。

我当时Kafka的topic配置是：分区数12，副本数2，消息保留时间48小时。分区数要跟下游消费者数量挂钩，设计原则是消费者数不超过分区数，否则多余消费者会空转。副本数2是成本和可靠性的平衡，日志数据不像业务数据那么高敏感，没必要全副本拷贝。

3.3 解析与清洗：Logstash把文本变成结构化数据的魔法

Filebeat发到Kafka的消息还是原始的文本行，Elasticsearch虽然也能全文检索，但你想"查出所有订单号为ORD123456的ERROR日志"就比较费劲。Logstash的作用就是把非结构化文本转换成结构化JSON。

看一个典型的logstash pipeline配置：

input { kafka { bootstrap_servers => "kafka-server:9092" topics => ["app-logs"] group_id => "logstash-app-logs" codec => "json" consumer_threads => 4 } } filter { if [fields][app_name] == "order-service" { grok { match => { "message" => "^%{TIMESTAMP_ISO8601:log_time}\s+%{LOGLEVEL:level}\s+\[%{DATA:thread}\]\s+%{DATA:logger}\s+-\s+%{DATA:class_name}#%{DATA:method_name}\s*-\s*%{GREEDYDATA:detail_message}" } } date { match => ["log_time", "yyyy-MM-dd HH:mm:ss.SSS"] target => "@timestamp" } mutate { remove_field => ["message", "original"] } } } output { elasticsearch { hosts => ["http://elasticsearch-server:9200"] index => "app-logs-%{+YYYY.MM.dd}" } }

grok是整个Logstash里最核心、也是最让人又爱又恨的插件。它本质是一个正则表达式库，把常用的时间、IP、数字、日志级别等格式封装成了命名模式。你只需要按照自己日志的格式拼装一条grok表达式，就能把日志拆成字段。

我当时为了解析Java应用日志里的类名和方法名，调整了好几次正则表达式。实际干活建议直接在线调试工具（比如Grok Constructor）里先跑通，再贴到配置里，能省很多时间。

还有一个细节：date插件。日志里记录的"业务时间"和Logstash处理时的"当前时间"往往不同（可能是几秒甚至几分钟的延迟），而Elasticsearch默认用的是@timestamp字段（写入时间）。如果你用写入时间去Kibana里过滤日志，看到的可能跟业务时间对不上，排查问题时很误导。所以用date插件把日志里的原始时间覆盖到@timestamp，让日志的检索时间轴跟业务时间轴保持一致。

3.4 存储与检索：Elasticsearch索引生命周期和分片的心得

索引是Elasticsearch里存储数据的逻辑容器，我按天建索引（app-logs-2025.06.14），好处是显而易见的：日志删除只需要删掉过期索引，不用逐条delete；检索时可以缩小范围到某几天；每个索引独立做优化互不影响。

但分片数量的设计往往是新手最容易出错的地方。我开始时每个索引分片数设置成了5，副本1，结果索引特别碎。分片过多带来的问题包括：集群维护分片的元数据开销大、小分片查询效率反而下降、单分片数据量很小造成存储浪费。后来我把分片数调整为3，实测下来查询和写入性能都稳定了。

关于索引生命周期（ILM），这个是必须配置的。如果没有ILM，日志索引会无限增长，磁盘总有一天被打爆。ILM策略分几个阶段：hot阶段（写入频繁，SSD存储）、warm阶段（只读，降低副本数）、delete阶段（超过保留时间删除）。我配置的保留策略是根据业务需要来的，核心服务日志保留30天，普通业务日志保留15天。每天凌晨ILM会检查并自动执行滚动和清理，全程无需人工干预。

3.5 可视化：Kibana的Discover和Dashboard

到了Kibana这层，其实是把底层能力变成"人能看懂"的东西。

Discover页面是日常排查问题的主场。支持全文搜索、字段过滤、时间范围选择、索引模式切换。我习惯先在Discover里把要看的日志检索逻辑确认好，再另存为保存搜索（Saved Search），后面做Dashboard或告警直接引用。

Dashboard大盘则适合团队共用的展示场景。我做了几个比较实用的面板：全局日志量趋势（按小时统计）、各服务错误日志占比（饼图）、Top10异常日志接口（柱状图）、以及响应时间过慢的请求日志列表（表格）。

这里想提醒一点：Kibana里的时区默认是UTC（浏览器访问时会按当前浏览器时区转换），但Kibana显示时间时经常会遇到"差8小时"的问题。原因在于Kibana的时区设置和Elasticsearch存储的时间是UTC的，你需要在Kibana的Advanced Settings里把dateFormat:tz设置为Asia/Shanghai，否则你看到的时间永远比业务时间慢8个小时。这个坑极其常见。

4. 落地实操：从零搭建一套可用的分布式日志系统

选型和链路原理都清楚了，这一节是纯实操环节，照着做能搭出一套完整可用的系统。

4.1 环境准备和组件版本选择

我基于实际经验，建议组件版本用以下组合（都是稳定版，兼容性经过验证）：

组件	版本	说明
Elasticsearch	7.10.2	7.10之后的版本 license 变化比较大，老版本积累的踩坑资料多
Logstash	7.10.2	和 ES 同一个大版本，避免兼容问题
Kibana	7.10.2	同上
Filebeat	7.10.2	版本跟服务端保持一致最省心
Kafka	2.13-3.1.0	稳定版本，配合Zookeeper使用

如果你用的是JDK，注意Kafka和Elasticsearch都依赖Java，建议JDK版本11及以上。另外Elasticsearch默认不允许以root用户运行，必须创建独立的系统用户：

groupadd elsearch useradd elsearch -g elsearch -p es123456 chown -R elsearch:elsearch /usr/local/elasticsearch

4.2 Filebeat配置详解：日志轮转和多行合并

在业务机器上安装Filebeat后，配置文件的关键项看3.1节已经给了。这里补充一个特别容易出的问题：日志文件的轮转（rotation）。

Java应用普遍用Logback或Log4j2按天或按大小切分日志文件，比如order-service.log到当天晚上12点变成order-service.log.2025-06-14。Filebeat在监控一个文件名时，如果文件被rename或delete，它可能短暂地丢失几秒的日志（在文件轮转的间隙）。

解决方式是Filebeat的配置里要同时监控*.log和*.log.*，并开启ignore_older参数来忽略过于老的日志文件：

filebeat.inputs: - type: filestream enabled: true paths: - /data/logs/order-service/*.log - /data/logs/order-service/*.log.* ignore_older: "48h"

ignore_older的意思是：文件最后修改时间超过48小时就不再采集。这个参数防止每次Filebeat启动时把所有历史日志都扫一遍，白白浪费带宽和存储。

4.3 Logstash pipeline编写：格式解析、时间覆盖和字段裁剪

Logstash的pipeline配置已经在3.3节展示过了，这里补充一个生产环境常见的需求：多应用日志用一个pipeline消费，但解析规则不同。

假设你有order-service和user-service两个应用，日志格式不同，可以这样处理：

filter { if [fields][app_name] == "order-service" { grok { match => { "message" => "order服务的grok表达式..." } } } else if [fields][app_name] == "user-service" { grok { match => { "message" => "user服务的grok表达式..." } } } }

这个做法的关键是Filebeat采集时一定要给每条日志打上应用标签（fields.app_name），否则下游根本不知道这条日志来自哪个服务。

多应用共用pipeline能减少Logstash实例数量、节省服务器资源，但代价是单个pipeline逻辑变复杂。我的建议是：先按日志格式分组，一个pipeline最多处理2-3种格式的日志。如果业务系统特别多、格式差异特别大，宁可拆成多个pipeline、起多个Logstash进程，也别把几百行判断逻辑堆在一个配置里，后面维护起来真想骂人。

4.4 Spring Boot应用如何接入：Logback输出JSON格式和TraceId

日志能不能被Logstash顺利解析，关键在于应用侧输出的日志格式。如果你用的是Spring Boot，我强烈建议用logstash-logback-encoder这个库，直接把日志输出成JSON格式，而不是输出成纯文本再让Logstash用grok去解析。

为什么这么做？grok解析依赖正则，正则性能消耗大、且格式稍微变一点就解析失败。如果应用侧直接输出JSON，Logstash只需要指定codec => json，连grok都不用写，性能和稳定性都高了一个量级。

在pom.xml添加依赖：

<dependency> <groupId>net.logstash.logback</groupId> <artifactId>logstash-logback-encoder</artifactId> <version>7.2</version> </dependency>

logback-spring.xml核心配置：

<appender name="JSON_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>/data/logs/order-service/app.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>/data/logs/order-service/app.%d{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>30</maxHistory> </rollingPolicy> <encoder class="net.logstash.logback.encoder.LogstashEncoder"> <customFields>{"app_name":"order-service"}</customFields> <includeMdc>true</includeMdc> </encoder> </appender>

这样输出的日志是类似这样的结构化的JSON：

{ "@timestamp": "2025-06-14T10:00:00.123+08:00", "level": "ERROR", "logger": "com.example.OrderController", "thread": "http-nio-8080-exec-3", "message": "订单创建失败", "app_name": "order-service", "trace_id": "8f2e9c6a1b3d4e5f" }

Logstash那边几乎不需要filter，codec => json直接解析，性能非常高。

TraceId怎么打通全链路，这里展开说一下。在一个请求经过多个微服务的时候，如果没有一个统一的请求ID，你根本没法把"用户下单"在网关、订单服务、支付服务里的所有日志串联起来。做法是：

1. 在网关或入口Filter生成一个UUID作为traceId，放入MDC。
2. 通过HTTP头（比如X-Trace-Id）向下游传递。
3. 下游服务在Filter里从请求头取出traceId，再放入自己的MDC。

Logback的MDC（Mapped Diagnostic Context）本质是一个ThreadLocal Map，贯穿整个请求线程。LogstashEncoder配置了includeMdc=true之后，日志会自动把MDC里的所有key-value输出到JSON字段里。这样在Kibana里直接按trace_id搜索，一次请求涉及的所有服务日志就全部串起来了。

4.5 Elasticsearch索引生命周期策略配置

我直接在Kibana的DevTools里创建ILM策略和索引模板：

PUT _ilm/policy/app-logs-policy { "policy": { "phases": { "hot": { "min_age": "0ms", "actions": { "rollover": { "max_size": "50GB", "max_age": "1d" }, "set_priority": { "priority": 100 } } }, "delete": { "min_age": "30d", "actions": { "delete": {} } } } } }

rollover的意思是：当前索引超过50GB或写满1天，就自动rollover到新的索引。delete阶段设定30天后自动删除。这个策略直接解决了索引无限增长的问题。

索引模板的意义在于：当第一个app-logs-2025.06.14索引被创建时，Elasticsearch会自动套用模板里的settings和aliases，包括分片数、副本数、ILM策略等：

PUT _index_template/app-logs-template { "index_patterns": ["app-logs-*"], "template": { "settings": { "number_of_shards": 3, "number_of_replicas": 1, "index.lifecycle.name": "app-logs-policy" } } }

从此以后，Logstash往app-logs-%{+YYYY.MM.dd}写索引时，不需要手动建索引，模板自动生效。

4.6 验证链路是否打通

搭完所有组件后，验证链路是最后一步。先确认业务日志持续落盘，然后依次检查：

1. Filebeat是否正常监控文件：filebeat -e -d "*"调日志级别，看有没有读取输入。
2. Kafka是否收到了日志：用kafka-console-consumer.sh --bootstrap-server kafka-server:9092 --topic app-logs --from-beginning --max-messages 20来观察消费消息。
3. Elasticsearch里有没有索引数据：curl http://elasticsearch-server:9200/_cat/indices/app-logs-*看索引是否存在且有文档数。
4. Kibana索引模式是否创建：在Kibana的Stack Management里创建app-logs-*索引模式，然后在Discover里选时间范围，能看到日志刷新就说明全链路OK。

整个落地过程，大概就是这三件事：配置采集端、部署消息管道、定义存储策略。每一步都有现成配置可抄，但如果不懂原理，一旦出问题就容易抓瞎。所以下面的章节，我把自己运维时踩过的坑和排查思路详细列了出来。

5. 上线半年后，我把踩过的坑一个一个填平

系统搭好只是开始，真正考验人的是后续的稳定性和调优。下面这些坑，基本覆盖了分布式日志系统上线后最容易遇到的几类问题。

5.1 时区问题：Kibana显示的时间和日志时间对不上

这是反馈最多的一个"坑"。业务日志里明明写着2025-06-14 10:00:00，Kibana Discover里看到的时间却是02:00:00，差了8个小时。

根本原因在链路里有三层时间：日志原文里的时间（业务服务器本地时间）、Logstash处理时写入的@timestamp（UTC时间）、Kibana展示时按浏览器时区转成的时间。如果Logstash的date插件没有正确解析日志里的时间并覆盖@timestamp，Elasticsearch就会用UTC的当前写入时间作为@timestamp，Kibana按浏览器时区转换后自然就差了8小时。

解决办法就是3.3节里写的date插件。给你个验证技巧：在Kibana的Discover里展开一条日志，看原始字段里的log_time（业务时间）和@timestamp是否一致。如果相差8小时，基本就是date插件没生效或者grok解析的时间字段不对。

另外，如果你在index template里自定义了time_field（比如log_time），还要在索引模式的"Time field"里改成对应字段，否则Kibana仍然默认用@timestamp做时间过滤。

5.2 日志太多了，ES查询卡顿和集群负载过高

日志系统的特点是"写多读少"，但读的瞬间往往是在故障发生时——此时大家的查询需求会集中涌来，如果集群性能本来就不行，就会雪上加霜。

我踩到的第一个问题是"索引分片过多"。因为按天索引，每天有十几个索引，每个索引默认5个分片，再加上副本就是10个分片，集群里积了上百个分片。Elasticsearch每个分片都是一颗独立的Lucene索引，分片太多意味着每个查询请求都要在各个分片上并行执行，再汇总结果，集群的协调节点开销特别大。

根治方案就是调整分片数，以及用ILM的rollover策略让单个索引的数据量控制在一个合理范围。一般来说，每个分片的数据量在10GB到50GB之间比较合适。日志量小的服务，甚至可以把分片数设为1。

第二个问题是search的深度翻页。Kibana的Discover里翻页翻得比较深时，Elasticsearch的from + size模式会变得异常缓慢，因为每个分片都要取from+size条数据到协调节点再做全局排序。如果你在Kibana里翻到几千页之后，会感觉页面越来越卡，就是这个原因。

解决办法是不要在Kibana里做深度翻页。Kibana默认只加载前500条记录，如果要导出一大段日志去分析，建议缩小时间范围，或者使用Kibana的"Download CSV"功能。如果确实需要深度翻页API调用，用search_after或者scroll实现。

5.3 Filebeat采集吞吐不足，日志积压在文件里

有一次监控大屏上Kafka的lag指标持续走高，说明Filebeat送到Kafka的速度慢了。排查发现是Filebeat的bulk_max_size和worker配置没有根据机器性能调整。

默认配置里worker: 1，bulk_max_size: 1600。如果业务机器日志量大，可以在filebeat.yml里调整：

output.kafka: hosts: ["kafka-server:9092"] topic: "app-logs" worker: 4 bulk_max_size: 4096 compression: gzip codec.json: pretty: false

worker: 4代表有4个并发worker往Kafka写，compression: gzip可以减少网络带宽占用（Kafka消息压缩后体积减少60%以上）。

调整后，Kafka的lag指标迅速下降。注意，这个配置不是越高越好，worker太多会占用更多业务机器的CPU和内存。需要观察机器负载再定。

5.4 磁盘打爆：日志清理策略不生效的排查

这套系统运行到第三个月时，收到告警说ES节点磁盘使用率超过85%。查了一圈发现，ILM的delete阶段没有执行。

原因很有迷惑性：我配置的ILM策略是min_age: 30d，但这里的"age"是从索引创建时间开始算的，不是从写入数据的时间开始算。由于rollover策略是按max_size: 50GB来切分的，某一天业务量特别大时索引可能不到24小时就rollover了，但有些索引创建后数据量小，可能要两三天才会被rollover。结果每个索引的实际"年龄"差异很大，30天统一删除的话，最早的索引实际存活了35天以上。

解决方案有两种：第一，把ILM的min_age改小一点（比如25d），留出时差余量；第二，更推荐的做法是在ILM的hot阶段用max_age: 1d强制每天rollover一次，保证索引年龄和业务日期严格对应，这样逻辑最清晰，后面对账也方便。

另外别忘了给Elasticsearch数据目录的磁盘做监控，日志系统一旦磁盘满，影响的是整个ES集群的工作，而不只是日志写入。

6. 一套分布式日志系统搭建完成后，我的一些额外建议

日志系统跑通之后，你会发现它能做的事情远远不止"排查问题"。我额外琢磨了几个方向，也顺手做了一些延伸优化。

告警与日志联动。Kibana里的Alerting功能可以正对某个检索条件设置阈值告警，比如"每分钟ERROR日志超过50条"，或者"某个特定异常关键字出现10次"。我配置了针对OutOfMemoryError和ConnectionPoolTimeoutException的告警，提前发现过两次线上内存泄漏的苗头，比业务侧自己告警还早。这个能力建议一定用起来，成本很低、收益很高。

日志链路追踪和性能分析。有了统一的日志格式和TraceId之后，可以把一次请求在各服务间的耗时串起来。在Kibana里用trace_id搜索，然后按时间排序看日志时间戳，就能算出每个微服务处理该请求花了多少毫秒。这比专门上APM工具要轻量得多，虽然不够精确，但日常定位慢请求已经完全够用。我靠这个方法排查过一次"网关转发正常但订单服务响应极慢"的问题，最终定位到是数据库连接池满导致的等待，日志链路里时间戳一目了然。

日志分类分级存储。不是所有日志都值得存30天。我把访问日志、调试日志的保留期缩短到7天，错误日志和业务关键日志保留30天以上。实现方式是在Logstash里按日志级别写不同的ES索引：

if [level] == "ERROR" or [level] == "WARN" { elasticsearch { index => "app-logs-error-%{+YYYY.MM.dd}" } } else { elasticsearch { index => "app-logs-%{+YYYY.MM.dd}" } }

这样错误日志单独存一份，存储成本下降，且排查问题时直接进error索引，更快。

最后分享一个小技巧。Filebeat的registry文件里面记录了每个日志文件的读取偏移量，如果你误删了日志，或者想重新采集某一段日志，可以停掉Filebeat，删除/var/lib/filebeat/registry下对应文件，再重启Filebeat重新全量读取。但谨慎操作，这也意味着所有历史日志都会重新传输一遍，Kafka和ES瞬间压力特别大。我在测试环境试过一次，生产环境还是老老实实让数据自然流动比较好。

分布式日志系统的搭建不是一锤子买卖，它是随着业务增长不断调优的过程。但只要你一开始把架构的骨架搭对了（采集、缓冲、解析、存储、检索、告警各司其职），后面无论日志量怎么增长，这套框架都能通过扩展节点和调整参数去消化。希望这篇从选型到落地的完整记录，能帮你少走一些我已经走过的弯路。