1. 起因：日志还靠“逐台机器 grep”的时候，问题有多大？几年前我所在的业务组，日常排查线上问题的标准动作是这样的：先看告警群，然后连上一台服务器，tail -f看后端日志，再顺着调用关系去下一台机器继续找。那时候日志量一天大概 200G，单机 Elasticsearch 勉强活着，Kibana 上搜中文经常转圈，翻到一条有效的错误信息全凭运气。真正让我下决心重做一套企业级日志系统架构的，是某次凌晨大促流量：应用临时扩容了二十台，每台都在写日志，但到底哪台报错、哪台接口变慢，所有人心里没底，最后只能挨个登录机器去 grep KEY 字段。那晚之后，我们开始认真规划一套以 Elasticsearch、Filebeat、Kafka、Logstash、Kibana 为核心的日志系统。现在回头看，这套架构解决的问题远不止“能搜日志”这么简单，它同时承担了削峰填谷、数据缓冲、格式统一、多团队检索隔离、长期留存成本控制这些职责。如果你所在的团队同样是从三五十台服务器的小规模往几百台、上千台容器方向走，这篇内容应该能帮你少踩不少坑。很多人会觉得日志链路不复杂，把应用日志写到 Elasticsearch，再配个 Kibana 就能查。这个判断在小规模下没错；可流量一旦上来，直接写 ES 的模式会最先崩。日志场景的特点是大部分时间平稳，但故障和促销期间流量可能突然翻几倍，应用产生的日志量和业务请求量基本成正比。如果采集端直接把日志灌进 ES，ES 的写入线程池会在几秒钟内被打满，bulk 请求开始拒绝，查询也跟着变慢。问题扩大之后，正常日志和异常日志混在一起，你压根没法定位是业务问题还是日志系统引发的链路崩溃。当时我们列了一个很粗的接入需求：所有应用统一走一套日志采集通道，支持多行异常栈整合、字段拆解、敏感信息脱敏、按业务线和环境隔离开；日志至少保留三十天，能支撑告警、排障和简单统计；采集端丢日志的比例要尽量低。于是架构从“Filebeat 直接发 ES 或 Logstash”调整为“Filebeat 采集，Kafka 缓冲，Logstash 消费加工，ESS 存储，Kibana 查询”。这也是本文想分享的核心内容：每个组件到底在解决什么问题，以及上线后遇到过哪些真实排障过程。2. 先把架构想清楚：为什么中间要插一个 Kafka，而不是让日志直达 ES？如果只是搭一个演示环境，Filebeat 直接把日志推到 Elasticsearch 完全够用，少一层 Kafka 还少一点运维成本。但在企业级场景里，日志链路不可能只看正常状态，还得看 ES 集群抖动、Logstash 宕机、应用突发大量日志这种最坏情况。中间加 Kafka，本质上是给日志数据加了一个大容量缓冲池。我习惯用一个类比向新同事解释：日志源是山上的水，Elasticsearch 是楼下的大水桶。水量小时直接拿管子接过去没问题；但下暴雨时水突然变大，水桶灌满就会溢出来。Kafka 相当于水库，上游的水先蓄起来，下游按自己的速度处理。水桶不会因为暴雨被冲垮，上游也不会因为水桶满了而停掉生产。很多人纠结 Kafka 引入后延迟变高，实际上日志场景根本不在乎这几十毫秒，真正在乎的是 ES 写入压力和故障期间的数据完整性。再把几个组件的工作边界拆开看：组件职责放入链路的原因最容易踩的坑Filebeat读取日志文件、传输到 Kafka资源占用小，带读取位置记录，重启不丢不重多行日志没合并，堆栈被拆成碎行Kafka高吞吐消息缓冲削峰填谷，下游故障期间仍可短暂缓存分区数拍脑袋定，后期调整成本高Logstash消费 Kafka 数据，做过滤、解析、转换支持 grok、date、mutate，和 ES 解耦过滤器太重，CPU 直接打满Elasticsearch索引、存储、检索核心存储和搜索能力分片过多或映射字段类型失控Kibana可视化、检索、权限面向研发和业务人员的统一入口数据视图和权限配置混乱，查询变慢当初我们也认真考虑过一个更简单的方案：Logstash 直接从应用服务器读日志文件，不走 Kafka。实际测下来有几个问题。第一，Logstash 是 JVM 进程，内存和 CPU 占用比 Filebeat 高很多，在应用服务器上每多跑一个 JVM 都会吃掉本来属于业务的内存。第二，Logstash 没有像 Filebeat 那样轻量的 registry 机制来管理文件读取位置，进程重启后存在重复消费或者丢位置的风险。第三，一旦 Logstash 集群整体缓慢，采集端的日志会直接在文件里积压，应用磁盘占用率会飙升。所以采集端最终统一选定 Filebeat，只负责“快而稳”地把日志挪到 Kafka。选型时我们还否定了“Logstash 直接消费日志后写入 ES”的做法。这不是说 Logstash 不行，而是为了保留一个独立的缓冲层。Kafka 在这里不需要很大的存储配置，保留两三天就够了，目的是给下游留出故障窗口。比如 Elasticsearch 做版本升级、扩容或者集群因为磁盘水位变红时，Kafka 还能继续接收新日志；等 ES 恢复后再由 Logstash 追着消费。Kafka 的 topic 天然可以按业务线做隔离，某个业务日志量大也不影响其他业务线。整体链路变成了：应用写本地文件，Filebeat 采集，Kafka 蓄水，Logstash 加工，ES 存储，Kibana 展示。这也是企业里最常见的 ELK 扩展形态。3. 逐层落地：Filebeat、Kafka、Logstash、Elasticsearch 的关键配置与参数取舍3.1 Filebeat：把采集场景做“轻”，把多行日志做“整”Filebeat 的配置重点不是性能调参，而是多行日志和字段扩展。应用日志里最常见的麻烦是异常堆栈跨多行，如果一行一行发，在 Kibana 里搜到的就是一个支离破碎的Exception，上下文完全串不起来。好在 Filebeat 的 filestream input 已经自带 multiline 合并能力，我们用的是按时间戳首行匹配：filebeat.inputs: - type: filestream enabled: true id: app-json-log paths: - /var/log/apps/app1/*.log parsers: - ndjson: target: "" - multiline: type: pattern pattern: '^\[[0-9]{4}-[0-9]{2}-[0-9]{2}' negate: true match: after fields: app_id: order-center env: prod fields_under_root: true output.kafka: hosts: ["kafka001:9092", "kafka002:9092", "kafka003:9092"] topic: 'app-logs-%{[app_id]}' partition: round_robin: reachable_only: false required_acks: 1 compression: lz4 max_message_bytes: 1048576fields_under_root会把app_id和env提升为顶层字段，后续 Logstash 和 ES 都能直接按这两个字段做索引和过滤。注意 filestream 的id必须唯一，否则同一文件会被重复采集。多行解析里我用的是“以[YYYY-MM-DD开头作为新日志标志，其余行都追加到上一条”，对常规 springboot 格式的日志很管用。多行日志合并有个很隐蔽的问题：超长堆栈会超过 Kafka 的单条消息大小上限。如果堆栈特别厚，建议在应用侧把堆栈行数截断，比如 logback 的MaxLength，或者在 Filebeat 里做include_lines控制，避免单条消息超过 1MB。我们线上就遇到过某个应用打印了 3MB 的完整堆栈，直接把 Kafka producer 打崩。另外required_acks: 1是在吞吐和可靠性之间的折中，日志允许极少量的极端丢失，但不需要每个消息都等所有副本确认。部署完 Filebeat 后，一定要用filebeat test output验证 Kafka 连通性，并用filebeat test config检查语法。我们当时有一台机器配置文件里的 YAML 缩进错误，Filebeat 起不来，但日志采集任务在监控上没告警，数据缺了两小时才发现。所以采集端必须纳入自监控，后续我会再细说。3.2 Kafka：Topic 规划、分区数与保留时间不要靠拍脑袋Kafka 在整个链路里是被依赖但不参与业务逻辑的组件，布好之后很容易被忽略。但很多日志量大的团队最后会被 Kafka 反噬，根源往往就是 Topic 与分区数规划不合理。我们按业务线区分 Topic，命名规则是app-logs-{appId}。分区的数量按“日志峰值吞吐量”推，而不是按日志总量。假设一个核心应用高峰期每秒产生 30MB 日志，单个消费者线程稳定消费能力按 5MB/s 到 10MB/s 估算，那么至少 6 个分区；再考虑下游 Logstash 处理可能暂时卡住，还要留一定余量，所以我们把核心业务 Topic 定在 12 个分区。分区数也不是越多越好，分区多了会导致 ES 侧索引大量小段文件，对读写都有额外开销。创建命令大致是：kafka-topics.sh --create \ --topic app-logs-order-center \ --partitions 12 \ --replication-factor 3 \ --config cleanup.policy=delete \ --config retention.ms=259200000 \ --config max.message.bytes=1048588 \ --bootstrap-server kafka001:9092副本数如果集群节点少于 4 个，可以先设 2；副本数多会拖慢写入，对日志这种高吞吐低敏感场景没必要每个副本都强同步。保留时间我们设了三天，足够覆盖 Logstash 和 ES 同时故障的极端场景。cleanup.policy=delete是日志场景最合适的默认策略，别因为听过 Kafka 支持 compaction 就随便加上，compaction 适合存储 KV 状态，不适合纯日志流。Kafka 的消费组策略也要提前定好。所有 Logstash 实例最好使用同一个group_id，比如logstash-prod，这样多个 Logstash 节点能并行消费同一个 Topic；如果每个 Logstash 使用不同 group_id，就会出现同一份日志被重复写入 Elasticsearch，索引瞬间膨胀，而且还会出现不可控的重复计数。我们在联调环境踩过这个坑，监控上看半天没发现问题，最后排查到是不同节点上的 group_id 写错了。3.3 Logstash：过滤链路越短越好，解析规则尽量靠近数据源头Logstash 是全链路里最容易成为性能瓶颈的一环，因为 grok 正则解析非常耗 CPU。如果业务应用能直接输出 JSON 结构化日志，就不必让 Logstash 用 grok 猜字段，这样做能省下大量处理时间。我们的处理原则是：应用优先打印结构化日志；只有历史系统或第三方日志实在改不动时，才在 Logstash 里做 grok。一个简化后的 Logstash 管线配置大概长这样：input { kafka { bootstrap_servers => "kafka001:9092,kafka002:9092,kafka003:9092" topics_pattern => "app-logs-.*" group_id => "logstash-prod" consumer_threads => 8 codec => "json" auto_offset_reset => "latest" } } filter { if [app_id] == "order-center" { grok { match => { "message" => "%{LOGLEVEL:level} %{TIMESTAMP_ISO8601:log_time} %{JAVACLASS:logger} - %{GREEDYDATA:content}" } overwrite => ["message"] } } date { match => ["@timestamp", "UNIX_MS", "ISO8601"] target => "@timestamp" } mutate { remove_field => ["agent", "input", "ecs", "log"] rename => { "message" => "content" } } } output { elasticsearch { hosts => ["https://es001:9200", "https://es002:9200"] index => "app-logs-%{[app_id]}-%{+yyyy.MM.dd}" user => "${ES_LOG_USER}" password => "${ES_LOG_PWD}" ssl_certificate_authorities => ["/etc/logstash/certs/ca.crt"] } }有几个参数需要特别解释。consumer_threads原定 8 是根据 Kafka 分区数设置的，超过分区数多余的线程会空转；如果你改了 Topic 分区数，Logstash 实例数和消费者线程要重新对齐。date过滤器很关键，它决定最终 ES 里@timestamp是使用日志产生时间还是 Logstash 接收时间。对排障而言，日志产生时间才是真实时间，否则排查网络延迟或队列积压时看到的全是假的。Logstash 的调优参数大部分写在logstash.yml里。pipeline.workers建议等于 CPU 核数，pipeline.batch.size从默认 125 提到 500 在大日志量下有效果，但也要小心 JVM 堆内存压力，一般给 Logstash 4G 到 8G 堆内存比较平衡。还有一个容易被忽略的细节：如果业务高峰期出现 Logstash 积压，优先检查下游 ES 的 bulk 响应时间，而不是先加pipeline.workers。下游 ES 慢了，Logstash 消费速度再快也没用，消息全部卡在 Kafka 上。3.4 Elasticsearch：索引模板、字段映射和生命周期必须提前管起来日志写入 ES 之后最怕两件事：一是 mapping 被动态映射弄出一堆keyword和text类型错乱，二是索引分片多到把集群拖垮。企业级日志系统里，索引模板和生命周期策略不是上线后补的，而是接入第一天就要定好。我先说索引模板。ES 默认会动态映射字段，日志里如果混入一个非结构化字段，它可能被映射成keyword，导致后续无法全文搜索；又或者一个本应是date的字段被映射成text，Kibana 时间筛选直接失效。我们的做法是提前把通用字段控制住：PUT _index_template/app-logs-default { "index_patterns": ["app-logs-*"], "priority": 100, "template": { "settings": { "number_of_shards": 3, "number_of_replicas": 1 }, "mappings": { "properties": { "@timestamp": { "type": "date" }, "app_id": { "type": "keyword" }, "level": { "type": "keyword" }, "content": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "host_name": { "type": "keyword" } } } } }content同时定义text和keyword子字段，是为了既支持match模糊搜索，又能对整条消息做精确聚合。level、app_id、host_name这些字段用 keyword，因为它们的核心用途是过滤和分组，不需要分词搜索。生命周期方面，我们用了一个最简单但有效的策略：按天索引，保留 30 天。每天一个新索引app-logs-{appId}-{yyyy.MM.dd}，ILM 策略只负责删除过期索引。这里的重点是不要为了追求所谓的“性能”给每个应用都单独调分片数。分片太多是个大坑，我们曾统计过集群里有 400 多个 1GB 级别的小索引，每分片开销不小，最后整体写入变慢，缓存的 fielddata 也频繁抖动。后来把所有小日志应用的分片数统一压到 1 或 3，集群稳定性明显上来了。ES 还有几个值得关注的开关。如果日志中有大量不需要全文搜索的调试字段，可以把index设为false，节省存储空间。refresh_interval默认 1 秒，日志场景如果不是特别追求实时，调到 30 秒能显著降低合并段和写入压力。很多团队把 ES 当成在线数据库调优，但日志系统对实时性要求很低，适当放慢 refresh 完全无感。3.5 Kibana：检索、可视化和权限要从第一天就分层Kibana 是整个链路里离用户最近的一层。我们接入的业务方不只是后端研发，还有一部分数据分析同学和运维值班人员。如果只给一个默认 Dashboard，或者干脆让大家自己建索引再乱拖图表，过不了多久就会变成“Kibana 没人敢打开”。我们按团队划分 Kibana Space，比如订单域、支付域、基础设施域，各看各的日志。每个 Space 里预置了对应的数据视图、常用检索条件和 Dashboard。权限上用 Kibana 自身的角色机制，只读角色不能访问 Discover 之外的 Dev Tools，避免有人误改索引模式或者执行大规模聚合把集群拖慢。比起权限，更经常被忽略的是“检索视觉”。日志里最核心的查看界面是 Discover，我会在数据视图里把常用字段固定为表格首列，比如@timestamp、app_id、level、content的前 100 个字符。这样打开即用，否则每次排障都要手动加字段，效率差很多。Kibana 查询语法里最有用的是level: ERROR、content: "NullPointerException"这类组合，配合range语法按绝对时间锁定窗口。告警方面我们用 Kibana 自带的 Alerting 接了一个 webhook 到群里，规则就是“某业务线 ERROR 数量 5 分钟内超过阈值”，不需要额外引入组件。4. 真正上线会碰到的坑：一次积压、一次写入降速和一个 grok 解析谜题4.1 第一次 Kafka 消费积压：LAG 越来越高，问题出在消费线程数上线大概一个月后某天，监控图上kafka-consumer-lag曲线开始持续爬坡，从几万条涨到上百万条。排障第一步很常规，先看最直接的指标：kafka-consumer-groups.sh --bootstrap-server kafka001:9092 \ --describe \ --group logstash-prod输出里LAG列高得让人头皮发麻，但 Logstash 进程的 CPU 看着并不高。继续看 Logstash pipeline stats，发现它的duration_in_millis很大，说明消息其实已经拉下来了，只是处理速度跟不上。再往 Kafka 方向看，consumer 线程数量只有 2，而 Topic 分区数是 12，也就是说有大量分区根本没有活跃消费者线程在拉取，Kafka 只能等那两个线程慢慢消费。原因查清之后就好办了：Logstash 配置里consumer_threads只写了 2，明显小于分区数。把consumer_threads改成 8，同时给 Logstash JVM 堆内存加了 2G，消费速度立刻跟上来，LAG 在一个小时内归零。这里有个教训：Kafka 的 LAG 不是单纯靠增加分区数就能解决，消费者线程数、Logstash 实例数都要跟着分区数匹配，否则 Topic 设计得再大也只是浪费。4.2 ES 集群突然写入变慢：分片过多和 refresh 参数都在拖后腿第二次问题更隐蔽，日志量总体并没有暴涨，但 ES 写入指标从正常的几百 ms 一路涨到几十秒，Kibana 上的查询也频频超时。先看集群状态，是 yellow 但不是 red，CPU 和磁盘都没到极限。再用_cat/indices?v看索引列表，发现app-logs-*索引数量多得吓人，几百个磁盘只有几百 MB 的小索引，每个索引还有 3 到 5 个分片，这样光分片总数就上千了。分片本身不是问题，问题是分片太多之后，各个节点之间的协调开销、字段缓存和段合并压力都上来了。针对日志这种小索引，最佳实践是分片数宁少勿多。我们通过索引模板把后续应用的默认分片数改成 1，对已经存在的小索引做收缩和删除。同时把refresh_interval从默认 1 秒调到 30 秒，写入压力明显降下来。这个优化做完之后，我的一个体会是：ES 日志场景的瓶颈经常不是内存和 CPU，而是因为数据组织方式不合理把自己拖垮。4.3 grok 解析失败：排查了半天，最后发现是日志格式根本不统一有一次我们看 Kibana，发现content字段全是原始日志串，level字段是空的，而tags里出现了_grokparsefailure。这说明 Logstash 的 grok 正则没有匹配上。我最初以为是正则写得不够健壮，把日志样本拿过来一遍遍调。后来才发现，这个应用的日志格式在不同版本之间变了，新版加了traceId字段，旧版没有，而 grok 正则还是按旧格式写的。新格式一进来就失败，大部分日志没有被正确解析，排障时没人能看清来龙去脉。这个问题最有效的解法是让 grok 正则基于稳定前缀，或者干脆放弃在 Logstash 里解析，直接让应用输出 JSON。对于实在改不动的遗留系统，我会保留一条兜底管线：如果_grokparsefailure出现，不丢弃日志，而是把原始内容原样写入另一个索引app-logs-parse-failure-*，方便后续定期治理，而不是让日志静默丢失。很多团队一遇到 grok 解析失败就选择 drop，这是最坏的选择——日志的价值在于事后追溯，哪怕字段没解析出来，原始内容也值得留着。5. 日志治理层面的经验：结构化、采样、脱敏与成本控制如果链路搭好了但日志内容本身是乱的，那整个系统最多算“能搜”，算不上“能用”。我们后来花了不少精力做日志治理，核心方向是四个：结构化、采样、脱敏和成本控制。结构化是第一位的。应用只要打印 JSON 日志，Logstash 就不需要 grok，ES 映射也稳定，后续告警聚合、字段查询都顺理成章。我见过很多团队把 grok 正则写得像天书，但真正的问题不是解析难度，而是日志源头没有规范化。与其在后端解析补丁补丁地修，不如从应用日志框架的 pattern 和字段约定开始定规范。日志里至少要有时间、级别、应用标识、追踪 ID、业务动作和关键参数；没有 traceId 的日志，分布式链路里基本找不到关联点。采样比很多人想象的更重要。我们需要全量日志和全量可观测性不能兼得吗？其实大多数 DEBUG 日志只在排查问题时有价值，平时全量存下来就是在烧钱。我们对 DEBUG 日志做了比例采样，比如只保留 10%，ERROR 和 WARN 全量保留。这样一个简单的策略，存储成本直接降了差不多一半，而排障能力几乎没受影响。采样位置放在 Logstash 过滤器里，离数据源头越近越好，否则 Filebeat 已经发出去了，采样就没什么意义。脱敏这件事必须做，但别指望在 Logstash 里用一两个正则解决所有问题。如果日志里出现手机号、身份证号、银行卡号这类信息，建议在应用日志框架层面就不要打印，从源头去掉；老系统实在控制不了，再用 Logstash 的mutate和substitute做后用正则替换。需要注意，JSON 日志中某个字段的值被替换后，字段类型还是字符串，不影响 ES 映射，但正则如果写得不严谨很容易误伤正常文本。所以我们内部约定：日志中不允许出现明文敏感字段，这条写进代码评审 checklist。成本控制是绕不开的话题。日志存储是长期开销，保留 30 天听起来简单，但如果每天 200G，30 天就是 6T，再算上副本就是 12T，这还不算重构和段合并的额外空间。所以我们会按业务价值分类：核心业务日志保留 30 天，运营分析类日志保留 15 天，未来大概率用不到的低价值日志保留 7 天，并且关闭_source里的冗余字段。协调 ILM 策略时，用索引模板统一套上去，避免每来一个新业务线都手工建索引再手动删。成本控制不是临到月底才看账单，而是从接入的第一天就按数据价值定策略。6. 一些长期维护的工作习惯，希望你能比我更早意识到链路搭完只是开始，后续真正决定系统质量的往往是那些看着不起眼的日常工作习惯。第一，所有配置必须入库管理。Filebeat 的 yml、Logstash 的 pipeline、ES 的索引模板和 ILM 策略，全部放到配置仓库里走版本化，任何变更都留痕。我吃过亏：临时手动改过一台 Logstash 配置，改了之后现场恢复了，但一个月后格式化机器再部署，那台机器的配置和别家不一致，问题又回来一次。第二，每个环节都要有自监控和自愈手段。Filebeat 看采集速率和是否有 filebeat 进程退出；Kafka 看 Topic 的 LAG；Logstash 看 pipeline 的duration_in_millis和失败日志；ES 看写入延迟、查询延迟、分片数和磁盘水位。这些指标不一定都要接入公司级的监控平台，至少你自己得有办法在出问题时快速看到。第三，定期做故障演练。我们每季度会人为停掉一个 Logstash 节点、或者把 ES 集群里的一个节点摘除一段时间，观察 Kafka 的 LAG 变化、恢复后的消费追赶情况。不演练的话，真实事故发生时你根本不确定链路是否真的扛得住。第四，日志系统的交付不是“能搜到日志”就结束。我会在接入完成后专门做一次面向研发的简单培训，告诉大家 traceId 怎么填、时间范围怎么选、常见检索语法有哪些、什么情况下去看 Kibana 而不是登服务器。很多人不愿意花这个时间，其实这笔投入的回报非常直接：研发少问一次“为什么 Kibana 里查不到”，就少占用一次你的排障时间。这个架构用到现在，最让我满意的不是吞吐量多高，也不是各种组件调参有多精妙，而是团队在线上出问题时能迅速聚焦到真正的故障点，不再靠登录一台台机器碰运气。
1. 起因：日志还靠“逐台机器 grep”的时候，问题有多大？几年前我所在的业务组，日常排查线上问题的标准动作是这样的：先看告警群，然后连上一台服务器，tail -f看后端日志，再顺着调用关系去下一台机器继续找。那时候日志量一天大概 200G，单机 Elasticsearch 勉强活着，Kibana 上搜中文经常转圈，翻到一条有效的错误信息全凭运气。真正让我下决心重做一套企业级日志系统架构的，是某次凌晨大促流量：应用临时扩容了二十台，每台都在写日志，但到底哪台报错、哪台接口变慢，所有人心里没底，最后只能挨个登录机器去 grep KEY 字段。那晚之后，我们开始认真规划一套以 Elasticsearch、Filebeat、Kafka、Logstash、Kibana 为核心的日志系统。现在回头看，这套架构解决的问题远不止“能搜日志”这么简单，它同时承担了削峰填谷、数据缓冲、格式统一、多团队检索隔离、长期留存成本控制这些职责。如果你所在的团队同样是从三五十台服务器的小规模往几百台、上千台容器方向走，这篇内容应该能帮你少踩不少坑。很多人会觉得日志链路不复杂，把应用日志写到 Elasticsearch，再配个 Kibana 就能查。这个判断在小规模下没错；可流量一旦上来，直接写 ES 的模式会最先崩。日志场景的特点是大部分时间平稳，但故障和促销期间流量可能突然翻几倍，应用产生的日志量和业务请求量基本成正比。如果采集端直接把日志灌进 ES，ES 的写入线程池会在几秒钟内被打满，bulk 请求开始拒绝，查询也跟着变慢。问题扩大之后，正常日志和异常日志混在一起，你压根没法定位是业务问题还是日志系统引发的链路崩溃。当时我们列了一个很粗的接入需求：所有应用统一走一套日志采集通道，支持多行异常栈整合、字段拆解、敏感信息脱敏、按业务线和环境隔离开；日志至少保留三十天，能支撑告警、排障和简单统计；采集端丢日志的比例要尽量低。于是架构从“Filebeat 直接发 ES 或 Logstash”调整为“Filebeat 采集，Kafka 缓冲，Logstash 消费加工，ESS 存储，Kibana 查询”。这也是本文想分享的核心内容：每个组件到底在解决什么问题，以及上线后遇到过哪些真实排障过程。2. 先把架构想清楚：为什么中间要插一个 Kafka，而不是让日志直达 ES？如果只是搭一个演示环境，Filebeat 直接把日志推到 Elasticsearch 完全够用，少一层 Kafka 还少一点运维成本。但在企业级场景里，日志链路不可能只看正常状态，还得看 ES 集群抖动、Logstash 宕机、应用突发大量日志这种最坏情况。中间加 Kafka，本质上是给日志数据加了一个大容量缓冲池。我习惯用一个类比向新同事解释：日志源是山上的水，Elasticsearch 是楼下的大水桶。水量小时直接拿管子接过去没问题；但下暴雨时水突然变大，水桶灌满就会溢出来。Kafka 相当于水库，上游的水先蓄起来，下游按自己的速度处理。水桶不会因为暴雨被冲垮，上游也不会因为水桶满了而停掉生产。很多人纠结 Kafka 引入后延迟变高，实际上日志场景根本不在乎这几十毫秒，真正在乎的是 ES 写入压力和故障期间的数据完整性。再把几个组件的工作边界拆开看：组件职责放入链路的原因最容易踩的坑Filebeat读取日志文件、传输到 Kafka资源占用小，带读取位置记录，重启不丢不重多行日志没合并，堆栈被拆成碎行Kafka高吞吐消息缓冲削峰填谷，下游故障期间仍可短暂缓存分区数拍脑袋定，后期调整成本高Logstash消费 Kafka 数据，做过滤、解析、转换支持 grok、date、mutate，和 ES 解耦过滤器太重，CPU 直接打满Elasticsearch索引、存储、检索核心存储和搜索能力分片过多或映射字段类型失控Kibana可视化、检索、权限面向研发和业务人员的统一入口数据视图和权限配置混乱，查询变慢当初我们也认真考虑过一个更简单的方案：Logstash 直接从应用服务器读日志文件，不走 Kafka。实际测下来有几个问题。第一，Logstash 是 JVM 进程，内存和 CPU 占用比 Filebeat 高很多，在应用服务器上每多跑一个 JVM 都会吃掉本来属于业务的内存。第二，Logstash 没有像 Filebeat 那样轻量的 registry 机制来管理文件读取位置，进程重启后存在重复消费或者丢位置的风险。第三，一旦 Logstash 集群整体缓慢，采集端的日志会直接在文件里积压，应用磁盘占用率会飙升。所以采集端最终统一选定 Filebeat，只负责“快而稳”地把日志挪到 Kafka。选型时我们还否定了“Logstash 直接消费日志后写入 ES”的做法。这不是说 Logstash 不行，而是为了保留一个独立的缓冲层。Kafka 在这里不需要很大的存储配置，保留两三天就够了，目的是给下游留出故障窗口。比如 Elasticsearch 做版本升级、扩容或者集群因为磁盘水位变红时，Kafka 还能继续接收新日志；等 ES 恢复后再由 Logstash 追着消费。Kafka 的 topic 天然可以按业务线做隔离，某个业务日志量大也不影响其他业务线。整体链路变成了：应用写本地文件，Filebeat 采集，Kafka 蓄水，Logstash 加工，ES 存储，Kibana 展示。这也是企业里最常见的 ELK 扩展形态。3. 逐层落地：Filebeat、Kafka、Logstash、Elasticsearch 的关键配置与参数取舍3.1 Filebeat：把采集场景做“轻”，把多行日志做“整”Filebeat 的配置重点不是性能调参，而是多行日志和字段扩展。应用日志里最常见的麻烦是异常堆栈跨多行，如果一行一行发，在 Kibana 里搜到的就是一个支离破碎的Exception，上下文完全串不起来。好在 Filebeat 的 filestream input 已经自带 multiline 合并能力，我们用的是按时间戳首行匹配：filebeat.inputs: - type: filestream enabled: true id: app-json-log paths: - /var/log/apps/app1/*.log parsers: - ndjson: target: "" - multiline: type: pattern pattern: '^\[[0-9]{4}-[0-9]{2}-[0-9]{2}' negate: true match: after fields: app_id: order-center env: prod fields_under_root: true output.kafka: hosts: ["kafka001:9092", "kafka002:9092", "kafka003:9092"] topic: 'app-logs-%{[app_id]}' partition: round_robin: reachable_only: false required_acks: 1 compression: lz4 max_message_bytes: 1048576fields_under_root会把app_id和env提升为顶层字段，后续 Logstash 和 ES 都能直接按这两个字段做索引和过滤。注意 filestream 的id必须唯一，否则同一文件会被重复采集。多行解析里我用的是“以[YYYY-MM-DD开头作为新日志标志，其余行都追加到上一条”，对常规 springboot 格式的日志很管用。多行日志合并有个很隐蔽的问题：超长堆栈会超过 Kafka 的单条消息大小上限。如果堆栈特别厚，建议在应用侧把堆栈行数截断，比如 logback 的MaxLength，或者在 Filebeat 里做include_lines控制，避免单条消息超过 1MB。我们线上就遇到过某个应用打印了 3MB 的完整堆栈，直接把 Kafka producer 打崩。另外required_acks: 1是在吞吐和可靠性之间的折中，日志允许极少量的极端丢失，但不需要每个消息都等所有副本确认。部署完 Filebeat 后，一定要用filebeat test output验证 Kafka 连通性，并用filebeat test config检查语法。我们当时有一台机器配置文件里的 YAML 缩进错误，Filebeat 起不来，但日志采集任务在监控上没告警，数据缺了两小时才发现。所以采集端必须纳入自监控，后续我会再细说。3.2 Kafka：Topic 规划、分区数与保留时间不要靠拍脑袋Kafka 在整个链路里是被依赖但不参与业务逻辑的组件，布好之后很容易被忽略。但很多日志量大的团队最后会被 Kafka 反噬，根源往往就是 Topic 与分区数规划不合理。我们按业务线区分 Topic，命名规则是app-logs-{appId}。分区的数量按“日志峰值吞吐量”推，而不是按日志总量。假设一个核心应用高峰期每秒产生 30MB 日志，单个消费者线程稳定消费能力按 5MB/s 到 10MB/s 估算，那么至少 6 个分区；再考虑下游 Logstash 处理可能暂时卡住，还要留一定余量，所以我们把核心业务 Topic 定在 12 个分区。分区数也不是越多越好，分区多了会导致 ES 侧索引大量小段文件，对读写都有额外开销。创建命令大致是：kafka-topics.sh --create \ --topic app-logs-order-center \ --partitions 12 \ --replication-factor 3 \ --config cleanup.policy=delete \ --config retention.ms=259200000 \ --config max.message.bytes=1048588 \ --bootstrap-server kafka001:9092副本数如果集群节点少于 4 个，可以先设 2；副本数多会拖慢写入，对日志这种高吞吐低敏感场景没必要每个副本都强同步。保留时间我们设了三天，足够覆盖 Logstash 和 ES 同时故障的极端场景。cleanup.policy=delete是日志场景最合适的默认策略，别因为听过 Kafka 支持 compaction 就随便加上，compaction 适合存储 KV 状态，不适合纯日志流。Kafka 的消费组策略也要提前定好。所有 Logstash 实例最好使用同一个group_id，比如logstash-prod，这样多个 Logstash 节点能并行消费同一个 Topic；如果每个 Logstash 使用不同 group_id，就会出现同一份日志被重复写入 Elasticsearch，索引瞬间膨胀，而且还会出现不可控的重复计数。我们在联调环境踩过这个坑，监控上看半天没发现问题，最后排查到是不同节点上的 group_id 写错了。3.3 Logstash：过滤链路越短越好，解析规则尽量靠近数据源头Logstash 是全链路里最容易成为性能瓶颈的一环，因为 grok 正则解析非常耗 CPU。如果业务应用能直接输出 JSON 结构化日志，就不必让 Logstash 用 grok 猜字段，这样做能省下大量处理时间。我们的处理原则是：应用优先打印结构化日志；只有历史系统或第三方日志实在改不动时，才在 Logstash 里做 grok。一个简化后的 Logstash 管线配置大概长这样：input { kafka { bootstrap_servers => "kafka001:9092,kafka002:9092,kafka003:9092" topics_pattern => "app-logs-.*" group_id => "logstash-prod" consumer_threads => 8 codec => "json" auto_offset_reset => "latest" } } filter { if [app_id] == "order-center" { grok { match => { "message" => "%{LOGLEVEL:level} %{TIMESTAMP_ISO8601:log_time} %{JAVACLASS:logger} - %{GREEDYDATA:content}" } overwrite => ["message"] } } date { match => ["@timestamp", "UNIX_MS", "ISO8601"] target => "@timestamp" } mutate { remove_field => ["agent", "input", "ecs", "log"] rename => { "message" => "content" } } } output { elasticsearch { hosts => ["https://es001:9200", "https://es002:9200"] index => "app-logs-%{[app_id]}-%{+yyyy.MM.dd}" user => "${ES_LOG_USER}" password => "${ES_LOG_PWD}" ssl_certificate_authorities => ["/etc/logstash/certs/ca.crt"] } }有几个参数需要特别解释。consumer_threads原定 8 是根据 Kafka 分区数设置的，超过分区数多余的线程会空转；如果你改了 Topic 分区数，Logstash 实例数和消费者线程要重新对齐。date过滤器很关键，它决定最终 ES 里@timestamp是使用日志产生时间还是 Logstash 接收时间。对排障而言，日志产生时间才是真实时间，否则排查网络延迟或队列积压时看到的全是假的。Logstash 的调优参数大部分写在logstash.yml里。pipeline.workers建议等于 CPU 核数，pipeline.batch.size从默认 125 提到 500 在大日志量下有效果，但也要小心 JVM 堆内存压力，一般给 Logstash 4G 到 8G 堆内存比较平衡。还有一个容易被忽略的细节：如果业务高峰期出现 Logstash 积压，优先检查下游 ES 的 bulk 响应时间，而不是先加pipeline.workers。下游 ES 慢了，Logstash 消费速度再快也没用，消息全部卡在 Kafka 上。3.4 Elasticsearch：索引模板、字段映射和生命周期必须提前管起来日志写入 ES 之后最怕两件事：一是 mapping 被动态映射弄出一堆keyword和text类型错乱，二是索引分片多到把集群拖垮。企业级日志系统里，索引模板和生命周期策略不是上线后补的，而是接入第一天就要定好。我先说索引模板。ES 默认会动态映射字段，日志里如果混入一个非结构化字段，它可能被映射成keyword，导致后续无法全文搜索；又或者一个本应是date的字段被映射成text，Kibana 时间筛选直接失效。我们的做法是提前把通用字段控制住：PUT _index_template/app-logs-default { "index_patterns": ["app-logs-*"], "priority": 100, "template": { "settings": { "number_of_shards": 3, "number_of_replicas": 1 }, "mappings": { "properties": { "@timestamp": { "type": "date" }, "app_id": { "type": "keyword" }, "level": { "type": "keyword" }, "content": { "type": "text", "fields": { "keyword": { "type": "keyword", "ignore_above": 256 } } }, "host_name": { "type": "keyword" } } } } }content同时定义text和keyword子字段，是为了既支持match模糊搜索，又能对整条消息做精确聚合。level、app_id、host_name这些字段用 keyword，因为它们的核心用途是过滤和分组，不需要分词搜索。生命周期方面，我们用了一个最简单但有效的策略：按天索引，保留 30 天。每天一个新索引app-logs-{appId}-{yyyy.MM.dd}，ILM 策略只负责删除过期索引。这里的重点是不要为了追求所谓的“性能”给每个应用都单独调分片数。分片太多是个大坑，我们曾统计过集群里有 400 多个 1GB 级别的小索引，每分片开销不小，最后整体写入变慢，缓存的 fielddata 也频繁抖动。后来把所有小日志应用的分片数统一压到 1 或 3，集群稳定性明显上来了。ES 还有几个值得关注的开关。如果日志中有大量不需要全文搜索的调试字段，可以把index设为false，节省存储空间。refresh_interval默认 1 秒，日志场景如果不是特别追求实时，调到 30 秒能显著降低合并段和写入压力。很多团队把 ES 当成在线数据库调优，但日志系统对实时性要求很低，适当放慢 refresh 完全无感。3.5 Kibana：检索、可视化和权限要从第一天就分层Kibana 是整个链路里离用户最近的一层。我们接入的业务方不只是后端研发，还有一部分数据分析同学和运维值班人员。如果只给一个默认 Dashboard，或者干脆让大家自己建索引再乱拖图表，过不了多久就会变成“Kibana 没人敢打开”。我们按团队划分 Kibana Space，比如订单域、支付域、基础设施域，各看各的日志。每个 Space 里预置了对应的数据视图、常用检索条件和 Dashboard。权限上用 Kibana 自身的角色机制，只读角色不能访问 Discover 之外的 Dev Tools，避免有人误改索引模式或者执行大规模聚合把集群拖慢。比起权限，更经常被忽略的是“检索视觉”。日志里最核心的查看界面是 Discover，我会在数据视图里把常用字段固定为表格首列，比如@timestamp、app_id、level、content的前 100 个字符。这样打开即用，否则每次排障都要手动加字段，效率差很多。Kibana 查询语法里最有用的是level: ERROR、content: "NullPointerException"这类组合，配合range语法按绝对时间锁定窗口。告警方面我们用 Kibana 自带的 Alerting 接了一个 webhook 到群里，规则就是“某业务线 ERROR 数量 5 分钟内超过阈值”，不需要额外引入组件。4. 真正上线会碰到的坑：一次积压、一次写入降速和一个 grok 解析谜题4.1 第一次 Kafka 消费积压：LAG 越来越高，问题出在消费线程数上线大概一个月后某天，监控图上kafka-consumer-lag曲线开始持续爬坡，从几万条涨到上百万条。排障第一步很常规，先看最直接的指标：kafka-consumer-groups.sh --bootstrap-server kafka001:9092 \ --describe \ --group logstash-prod输出里LAG列高得让人头皮发麻，但 Logstash 进程的 CPU 看着并不高。继续看 Logstash pipeline stats，发现它的duration_in_millis很大，说明消息其实已经拉下来了，只是处理速度跟不上。再往 Kafka 方向看，consumer 线程数量只有 2，而 Topic 分区数是 12，也就是说有大量分区根本没有活跃消费者线程在拉取，Kafka 只能等那两个线程慢慢消费。原因查清之后就好办了：Logstash 配置里consumer_threads只写了 2，明显小于分区数。把consumer_threads改成 8，同时给 Logstash JVM 堆内存加了 2G，消费速度立刻跟上来，LAG 在一个小时内归零。这里有个教训：Kafka 的 LAG 不是单纯靠增加分区数就能解决，消费者线程数、Logstash 实例数都要跟着分区数匹配，否则 Topic 设计得再大也只是浪费。4.2 ES 集群突然写入变慢：分片过多和 refresh 参数都在拖后腿第二次问题更隐蔽，日志量总体并没有暴涨，但 ES 写入指标从正常的几百 ms 一路涨到几十秒，Kibana 上的查询也频频超时。先看集群状态，是 yellow 但不是 red，CPU 和磁盘都没到极限。再用_cat/indices?v看索引列表，发现app-logs-*索引数量多得吓人，几百个磁盘只有几百 MB 的小索引，每个索引还有 3 到 5 个分片，这样光分片总数就上千了。分片本身不是问题，问题是分片太多之后，各个节点之间的协调开销、字段缓存和段合并压力都上来了。针对日志这种小索引，最佳实践是分片数宁少勿多。我们通过索引模板把后续应用的默认分片数改成 1，对已经存在的小索引做收缩和删除。同时把refresh_interval从默认 1 秒调到 30 秒，写入压力明显降下来。这个优化做完之后，我的一个体会是：ES 日志场景的瓶颈经常不是内存和 CPU，而是因为数据组织方式不合理把自己拖垮。4.3 grok 解析失败：排查了半天，最后发现是日志格式根本不统一有一次我们看 Kibana，发现content字段全是原始日志串，level字段是空的，而tags里出现了_grokparsefailure。这说明 Logstash 的 grok 正则没有匹配上。我最初以为是正则写得不够健壮，把日志样本拿过来一遍遍调。后来才发现，这个应用的日志格式在不同版本之间变了，新版加了traceId字段，旧版没有，而 grok 正则还是按旧格式写的。新格式一进来就失败，大部分日志没有被正确解析，排障时没人能看清来龙去脉。这个问题最有效的解法是让 grok 正则基于稳定前缀，或者干脆放弃在 Logstash 里解析，直接让应用输出 JSON。对于实在改不动的遗留系统，我会保留一条兜底管线：如果_grokparsefailure出现，不丢弃日志，而是把原始内容原样写入另一个索引app-logs-parse-failure-*，方便后续定期治理，而不是让日志静默丢失。很多团队一遇到 grok 解析失败就选择 drop，这是最坏的选择——日志的价值在于事后追溯，哪怕字段没解析出来，原始内容也值得留着。5. 日志治理层面的经验：结构化、采样、脱敏与成本控制如果链路搭好了但日志内容本身是乱的，那整个系统最多算“能搜”，算不上“能用”。我们后来花了不少精力做日志治理，核心方向是四个：结构化、采样、脱敏和成本控制。结构化是第一位的。应用只要打印 JSON 日志，Logstash 就不需要 grok，ES 映射也稳定，后续告警聚合、字段查询都顺理成章。我见过很多团队把 grok 正则写得像天书，但真正的问题不是解析难度，而是日志源头没有规范化。与其在后端解析补丁补丁地修，不如从应用日志框架的 pattern 和字段约定开始定规范。日志里至少要有时间、级别、应用标识、追踪 ID、业务动作和关键参数；没有 traceId 的日志，分布式链路里基本找不到关联点。采样比很多人想象的更重要。我们需要全量日志和全量可观测性不能兼得吗？其实大多数 DEBUG 日志只在排查问题时有价值，平时全量存下来就是在烧钱。我们对 DEBUG 日志做了比例采样，比如只保留 10%，ERROR 和 WARN 全量保留。这样一个简单的策略，存储成本直接降了差不多一半，而排障能力几乎没受影响。采样位置放在 Logstash 过滤器里，离数据源头越近越好，否则 Filebeat 已经发出去了，采样就没什么意义。脱敏这件事必须做，但别指望在 Logstash 里用一两个正则解决所有问题。如果日志里出现手机号、身份证号、银行卡号这类信息，建议在应用日志框架层面就不要打印，从源头去掉；老系统实在控制不了，再用 Logstash 的mutate和substitute做后用正则替换。需要注意，JSON 日志中某个字段的值被替换后，字段类型还是字符串，不影响 ES 映射，但正则如果写得不严谨很容易误伤正常文本。所以我们内部约定：日志中不允许出现明文敏感字段，这条写进代码评审 checklist。成本控制是绕不开的话题。日志存储是长期开销，保留 30 天听起来简单，但如果每天 200G，30 天就是 6T，再算上副本就是 12T，这还不算重构和段合并的额外空间。所以我们会按业务价值分类：核心业务日志保留 30 天，运营分析类日志保留 15 天，未来大概率用不到的低价值日志保留 7 天，并且关闭_source里的冗余字段。协调 ILM 策略时，用索引模板统一套上去，避免每来一个新业务线都手工建索引再手动删。成本控制不是临到月底才看账单，而是从接入的第一天就按数据价值定策略。6. 一些长期维护的工作习惯，希望你能比我更早意识到链路搭完只是开始，后续真正决定系统质量的往往是那些看着不起眼的日常工作习惯。第一，所有配置必须入库管理。Filebeat 的 yml、Logstash 的 pipeline、ES 的索引模板和 ILM 策略，全部放到配置仓库里走版本化，任何变更都留痕。我吃过亏：临时手动改过一台 Logstash 配置，改了之后现场恢复了，但一个月后格式化机器再部署，那台机器的配置和别家不一致，问题又回来一次。第二，每个环节都要有自监控和自愈手段。Filebeat 看采集速率和是否有 filebeat 进程退出；Kafka 看 Topic 的 LAG；Logstash 看 pipeline 的duration_in_millis和失败日志；ES 看写入延迟、查询延迟、分片数和磁盘水位。这些指标不一定都要接入公司级的监控平台，至少你自己得有办法在出问题时快速看到。第三，定期做故障演练。我们每季度会人为停掉一个 Logstash 节点、或者把 ES 集群里的一个节点摘除一段时间，观察 Kafka 的 LAG 变化、恢复后的消费追赶情况。不演练的话，真实事故发生时你根本不确定链路是否真的扛得住。第四，日志系统的交付不是“能搜到日志”就结束。我会在接入完成后专门做一次面向研发的简单培训，告诉大家 traceId 怎么填、时间范围怎么选、常见检索语法有哪些、什么情况下去看 Kibana 而不是登服务器。很多人不愿意花这个时间，其实这笔投入的回报非常直接：研发少问一次“为什么 Kibana 里查不到”，就少占用一次你的排障时间。这个架构用到现在，最让我满意的不是吞吐量多高，也不是各种组件调参有多精妙，而是团队在线上出问题时能迅速聚焦到真正的故障点，不再靠登录一台台机器碰运气。