前几年我维护公司的日志平台最开始就是一套传统ELKElasticsearchLogstashKibana。日志量小的时候一切岁月静好Logstash采集、清洗、投递一条龙Kibana画图也顺手。可等服务规模一起来问题就开始扎堆Logstash在采集端频繁吃内存网络一抖动日志就断档ES在写入高峰期被打得抖动Kibana查起历史日志也跟着卡。后来我把采集端换成Filebeat中间塞了一个Kafka做缓冲链路变成ELFKK也就是ElasticsearchLogstashKibanaFilebeatKafka的组合才终于把日志这条线救回来。这篇文章我会把传统ELK和ELFKK这两套架构做一次完整的对比讲清楚各自适合什么场景、链路里每个组件到底承担什么职责以及从ELK平滑迁移到ELFKK时那些配置要怎么写、哪些坑是必须提前避开的。适合正在搭建日志系统的人、觉得现在日志链路越来越不稳定的同学以及想搞明白Filebeat和Kafka在日志采集里到底是什么角色的读者。整个过程我都会按实际运维视角来讲配置和命令也都是可以抄作业的那种。1. ELK与ELFKK两套架构的定位与边界1.1 先认清传统ELK的“舒适区”传统ELK采集端是Logstash。Logstash接收文件、syslog、JDBC等各类输入经过filter做解析和数据清洗再输出到Elasticsearch最后用Kibana做可视化展示和查询。这套架构的优点是组件少三条产品线就覆盖了从采集到展示的全部环节部署和维护成本低非常适合日志量可控的中小规模系统。我见过很多团队从单体应用起步日志就往一台机器上打ELK搭在一个节点上照样能跑。这个阶段Logstash虽然占用资源不少但问题不突出。真正让人头疼的是业务量上来以后Logstash既要读日志文件又要做正则解析还要批量写ES任何一个环节变慢采集端就会积压一旦积压实时性就没了Kibana上看到的日志滞后十几分钟是常有的事。用个生活化的类比传统ELK就像一条胡同里走的独木桥走的人少时畅通无阻人一旦多起来桥头就会堵。缺的不是通行能力而是一个疏散缓冲的空间。1.2 ELFKK到底改了什么ELFKK架构把采集和缓冲拆出来了Filebeat负责在每个业务节点上读取日志文件并推送到KafkaKafka作为消息缓冲层把日志流削峰填谷Logstash不再直接对接文件而是从Kafka消费数据解析后写入ElasticsearchKibana的使用方式不变。整体链路可以表述为业务日志文件 → Filebeat → Kafka → Logstash → Elasticsearch → Kibana。这个架构本质上做了一件事把“采集、缓冲、解析、存储、可视化”这五个环节解耦。采集端的Filebeat只负责轻量读取和传输不参与复杂解析资源占用小很多。Kafka放在中间后即使Elasticsearch出现短暂故障或者写入变慢上游Filebeat依然可以正常把数据推给Kafka数据不会在采集端积压也不会因为ES抖动导致日志丢失。从效果上来说我自己的经验是日志平台上下游一旦隔了一层Kafka故障的影响范围就被截断了。以前ES一抖动Logstash跟着积压最后连日志文件读取都受影响现在ES抖动只影响Logstash消费Kafka的速度业务节点上的日志采集完全不受牵连。1.3 用一张表说清两套架构的取舍很多选型场景不需要把架构推演得太复杂直接看规模和运维能力就能定。我把两套架构的差异整理成一张表方便对照对比维度传统ELKELFKK组件数量3个核心组件5个核心组件采集端资源占用Logstash占用较高JVM内存易吃紧Filebeat轻量内存占用低得多缓冲能力无缓冲Logstash直写ESKafka削峰填谷写入高峰更平稳数据可靠性传输链路中断容易丢数据Kafka可暂存数据支持回放运维复杂度低组件少易排障中需要维护Kafka和消费者组实时性高端到端链路短略低但消息堆积量正常时延迟可控适合日志规模日均GB级以下日均几十GB到TB级更安心扩展性采集端难以横向扩展Filebeat和Logstash均可横向扩容我的建议是如果日志量稳定在几十GB以下、业务要求能容忍偶尔丢少量日志、也不需要多套系统消费同一份日志那传统ELK完全够用没必要上Kafka给自己增加维护负担。但如果日志规模大、ES经常被写入高峰打垮或者有多个系统需要消费同一份日志ELFKK就值得认真考虑。2. 为什么说Filebeat和Kafka是日志链路的解药2.1 Logstash做采集端的三个代价Logstash做采集端最直接的问题是它依赖Java虚拟机。默认堆内存配置如果不调整遇到多行日志堆栈或者复杂grok正则时CPU和内存消耗非常夸张。我调过不少Logstash实例在日均日志量几百GB的场景下如果不对JVM做详细调优频繁Full GC导致采集卡顿是常态。第二个问题是职责过重。Logstash在传统ELK里既扮演采集器又扮演处理器还要扮演投递器。读文件、正则解析、字段映射、批量写ES所有工作都挤在一个进程里任何一个环节变慢都会拖累其他环节。最典型的场景是ES响应变慢时Logstash的输出线程阻塞输入队列持续堆积最终整个采集链路都跟着崩溃。第三个问题是扩展性差。Logstash虽然支持水平扩展但多实例采集同一个目录时必须依赖文件和目录的分配策略搞不好会产生重复或漏采。相比而言Filebeat也支持多实例但因为它的定位更轻、内存占用更低扩缩容的代价小得多。如果不想直接上Kafka先拿Filebeat替换Logstash采集端也是一条性价比很高的优化路径。2.2 Filebeat拿什么换取了“轻”Filebeat的核心优势是轻。它是用Go语言编写的不需要JVM默认内存占用通常只有几十兆到两三百兆对比Logstash动辄占用一两个G堆内存差距非常明显。它在日志采集场景下的核心机制可以概括为harvester逐行读取日志文件registry记录当前读取偏移然后批量把事件发往输出端。Filebeat配置里最核心的几块第一是input常见的是log类型和filestream类型。log类型是老牌写法filestream类型从7.x引入、8.x之后默认推荐对文件轮转和偏移管理的处理更完善。第二是multiline匹配处理Java异常堆栈时必须把多行日志合并成一条事件一般用pattern加negate加match的组合。第三是processors可以在发送前做字段裁剪、添加字段、丢弃指定事件等轻量处理。还有一个经常被忽略的点是registry偏移文件。Filebeat启动后会记录每个文件读到哪个位置如果registry文件损坏理论上可能导致重新发送整个文件的部分内容或跳过部分内容。所以Filebeat的data目录要有稳定的磁盘和合适的权限不要随便删data目录否则会出现“历史日志重新灌了一遍”这种诡异问题。2.3 Kafka在日志链路里到底顶什么用Kafka在日志链路里的作用我概括成四个词削峰、解耦、回放、多路消费。先看削峰日志采集天然有高峰比如业务请求集中在白天或者在某个时间点定时任务集中跑批日志量瞬间上去。没有Kafka时Logstash和ES就硬扛这些高峰扛不住就延迟有了Kafka缓冲层Filebeat只需要把数据持续推给KafkaLogstash按自己的节奏消费ES的写入压力就平稳了。解耦也很直观。以前Logstash和ES是强绑定关系ES挂了Logstash跟着堵现在Logstash和ES之间的问题只影响Kafka消费端上游采集端依然正常。回放则是Kafka特别有价值的能力消费端offset由消费者组维护如果Logstash解析逻辑出了问题需要重建索引把offset重置回去重新消费即可历史日志可以重新过一遍。不过要泼一盆冷水Kafka不是日志系统里的必需品。日均日志量不大时引入Kafka就意味着新增一套集群要运维还有Topic、消费者组、分区、副本这些概念要维护。我的判断标准是单日日志量超过几百GB、有明确的削峰或回放需求、外部系统也需要消费同一份日志这三个条件至少满足两个才值得上Kafka。3. 从ELK迁到ELFKK的落地实操3.1 版本选型与部署规划版本选型是个容易踩坑的环节。Elasticsearch、Logstash、Kibana、Filebeat这四件套最好保持同一个大版本比如都用7.17.x避免出现客户端和服务端版本不匹配导致的兼容问题。Kafka选型按已有生态来如果是新搭建环境Kafka 3.x比较省心新版支持KRaft模式可以不依赖ZooKeeper部署复杂度低很多。部署规划上ES生产环境至少一主两数据节点再小的规模也建议两个数据节点起步避免单点故障。Kafka生产环境建议至少三节点日志场景对分区副本要求不需要太高副本因子设为2通常够用。测试环境可以一台机器把五个组件全部塞下Kafka用单节点模式但你要明白这只是验证链路不是生产可用状态。顺带说一个很现实的注意点Elasticsearch从7.11版本开始采用了Elastic License和SSPL双许可模式基础功能仍然免费可用包括安全认证基础能力、监控等但部分高级功能需要订阅商业许可。比如ES 9版本中NRF等功能如果是企业版能力未订阅的情况下无法直接启用。如果你所在团队预算有限选型时可以提前确认哪些功能在免费版范围内必要时可以考虑开源分支OpenSearch避免项目做到一半发现某个关键能力被卡在收费项里。3.2 Filebeat接入Kafka的配置怎么写Filebeat接入Kafka核心是把output从Elasticsearch改成Kafka同时input按需配置。以下是一个比较完整的filebeat.yml示例适用于读取应用日志并推送Kafka的场景filebeat.inputs: - type: filestream enabled: true id: app-log paths: - /var/log/app/*.log parsers: - multiline: type: pattern pattern: ^[0-9]{4}-[0-9]{2}-[0-9]{2} negate: true match: after filebeat.config.modules: path: ${path.config}/modules.d/*.yml reload.enabled: true processors: - add_host_metadata: when.not.contains.tags: forwarded - add_cloud_metadata: ~ output.kafka: hosts: [kafka1:9092, kafka2:9092, kafka3:9092] topic: app-log partition.round_robin: reachable_only: true required_acks: 1 compression: gzip max_message_bytes: 1000000 logging: level: info to_files: true files: path: /var/log/filebeat name: filebeat.log这段配置里有几个细节要重点看。multiline匹配是按时间戳开头合并多行下一条日志以日期开头那么上一条日志就结束这样Java异常堆栈不会被拆分成七零八落的事件。output.kafka里的partition.round_robin表示轮询分区写入优点是能让Kafka各个分区相对均衡。required_acks设置为1表示Kafka leader写入成功就返回兼顾可靠性和速度日志场景没必要等所有副本都写完。还有一个容易忽略的配置是queueFilebeat内部有内存队列和磁盘队列两种缓冲机制默认使用内存队列如果数据量大而且担心Filebeat进程崩溃丢数据可以考虑开启磁盘队列。但磁盘队列会占用额外的磁盘I/O这个需要根据实际环境权衡。3.3 Kafka集群与Topic准备的实操指南如果之前没有Kafka集群最简单的验证方式是Docker Compose拉起一套。这里给一个可以直接用的docker-compose配置基于Apache Kafka 3.x镜像version: 3.8 services: kafka: image: bitnami/kafka:3.6 container_name: kafka ports: - 9092:9092 environment: - KAFKA_CFG_NODE_ID0 - KAFKA_CFG_PROCESS_ROLEScontroller,broker - KAFKA_CFG_CONTROLLER_QUORUM_VOTERS0kafka:9093 - KAFKA_CFG_LISTENERSPLAINTEXT://:9092,CONTROLLER://:9093 - KAFKA_CFG_ADVERTISED_LISTENERSPLAINTEXT://localhost:9092 - KAFKA_CFG_CONTROLLER_LISTENER_NAMESCONTROLLER - KAFKA_CFG_LISTENER_SECURITY_PROTOCOL_MAPCONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT - KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLEtrue volumes: - kafka_data:/bitnami/kafka volumes: kafka_data:日志场景中等规模部署建议用二进制包方式搭建独立集群明确指定broker.id、advertised.listeners和log.dirs。Topic的创建用命令行完成比如kafka-topics.sh --bootstrap-server localhost:9092 \ --create --topic app-log \ --partitions 6 \ --replication-factor 2分区数怎么定是很多人纠结的地方。我的经验是分区数至少要和Logstash的消费者线程数对齐最好略多一些。假如Logstash配置了3个消费者线程Topic有6个分区那么每个消费者线程能分到2个分区消费并行度高如果Topic只有1个分区那配置再多消费者线程也只有一个在消费。当然分区数也不是越大越好分区太多会让日志文件碎片化也增加Kafka元数据管理开销。Kafka日志保留时间生产环境建议设置72小时左右也就是retention.ms配置为259200000毫秒。太短会在Logstash故障恢复后来不及补数据太长则占用大量磁盘空间72小时是一个兼顾排查窗口和磁盘成本的经验值。如果你还想省心一点可以把auto.create.topics.enable设置成true让Kafka在Filebeat推送时自动创建Topic但生产环境不建议自动创建的Topic分区数默认值往往不满足你的并发需求。3.4 Logstash消费Kafka写ES的Pipeline配置Logstash从Kafka消费数据核心是input插件的配置。下面是一个可以直接用的pipeline配置示例input { kafka { bootstrap_servers kafka1:9092,kafka2:9092,kafka3:9092 topics [app-log] group_id logstash-app-log auto_offset_reset latest consumer_threads 3 codec json } } filter { if [kafka][topic] { mutate { remove_field [version, log, source, input] } } } output { elasticsearch { hosts [es1:9200, es2:9200] index app-log-%{yyyy.MM.dd} manage_template false } }这里面我觉得三个参数最值得关注。第一是group_id这是消费者分组的标识同一组内的Logstash实例会分摊不同分区不会重复消费。第二是auto_offset_reset只对新建消费者组或没有提交过offset的消费者组生效它可以选择earliest从头消费还是latest从新消息开始如果第一次上线就想把Kafka里已有的历史日志都补齐可以设置成earliest。第三是consumer_threads这个值要和Topic分区数配合。codec设置为json因为大部分应用日志本身是JSON格式Logstash拿到后可以直接解析成字段。如果你推送到Kafka的是纯文本这里就不用codec json改为普通文本然后在filter里用grok或dissect解析。Logstash写ES时建议把manage_template设为false索引模板统一在ES侧管理。这样可以避免Logstash每次启动时用默认模板覆盖你在ES里精心设计的mapping尤其是你想对特定字段做keyword或date类型映射的时候这一步特别重要。3.5 Elasticsearch侧如何接住Kafka带来的流量日志进了KafkaES侧的写入压力虽然被削峰了但不代表ES配置可以放松。首先是分片规划单个主分片的建议容量在三十到五十GB以内分片过大后续重建或迁移都很痛苦。其次日志索引建议按天滚动结合索引生命周期管理ILM实现自动删除或冷热分层避免索引无限增长拖垮集群。关于写入性能有几个参数是可以现场调节的。写入高峰时段把refresh_interval调大到30秒能显著降低段合并和磁盘I/O压力。副本数在写入高峰时先置为0等写入结束后再调整为1这种操作在日志场景下很常用代价是短期内数据没有副本保护适合在可控窗口内使用。ES节点角色划分也很关键。生产环境至少要把master节点和data节点分开master节点不做数据存储只负责集群状态管理。否则数据节点负载过高时master的响应也会跟着变慢整个集群的稳定性都会被拖累。查询压力大的场景还可以单独划出coordinating节点专门承接搜索请求。另外要给Filebeat或Logstash写入ES时启用bulk批量写。Filebeat默认就批量写Logstash的elasticsearch output默认使用bulk你只需要关注bulk的flush大小和间隔一般es_output里的pipeline配置是够用的。如果发现ES写入吞吐上不去先看数据节点磁盘I/O、段合并和refresh频率不要一上来就加机器。4. 链路里的典型坑与排查实录4.1 日志堆积Lag排查应该从哪里下手Kafka消费Lag上涨是ELFKK链路里最常见的故障现象。它的含义是消费端消费速度跟不上生产速度。正常情况Lag会在一个低位波动如果持续上涨说明消费环节堵住了。我的排查顺序一般是先看Logstash进程的CPU和JVM堆内存再看ES集群状态和索引健康然后再回到Kafka看消费者组状态。用命令可以快速定位kafka-consumer-groups.sh --bootstrap-server localhost:9092 \ --describe --group logstash-app-log输出结果里LAG列就是当前积压量如果有多个分区且某些分区Lag特别高可能是Logstash消费者线程数少于分区数或者某个消费者线程被GC拖住了。我遇到过一次很典型的场景ES集群某个数据节点磁盘接近满索引分配变得缓慢Logstash写入ES超时重试消费速度骤降Lag一路飙升到几千万条。等磁盘清理完ES恢复健康Logstash消费速度自动追上来数据一条没丢。这个案例说明Kafka缓冲层的价值在线路抖动时体现得最明显。Kafka侧的可视化工具推荐两个Kafdrop和kafka-ui可以从网页上直接查看Topic、分区、消费者组和Lag。不想装额外工具的话直接用命令行describe查看也足够。4.2 “同一个日志我收到了两份”重复消费问题剖析日志数据偶尔重复在检索场景里影响不大但如果基于日志做指标统计重复消费就麻烦。重复消费的本质是offset没有及时提交。Kafka消费者在拉取一批消息并处理后会提交这批消息的offset如果处理完但还没提交时消费者崩溃或Rebalance了这批消息就会被重新拉取相当于处理两遍。想减少重复可以从几个层面入手。第一是调大Logstash或消费者的poll间隔和max.poll.records减少因长时间处理导致消费者被认为失活进而触发Rebalance的概率。第二是尽量让消费者逻辑保持轻量不要在消费线程里做耗时太长的外部调用。第三是从设计上接受“至少一次”语义Kafka默认保证消息不丢但不保证不重复日志链路想完全避免重复几乎不可能。如果下游真的对重复敏感可以在ES写入时使用文档_id做幂等比如用日志内容加时间戳生成一个MD5作为_id这样重复写入同一份日志时ES会走覆盖更新而不是新增一条文档。这个方法在日志链路里很实用代价是多算一次哈希和ES层面的覆盖写开销。4.3 Kafka生产消费命令与Windows下的使用疑问很多从ELK迁移过来的同学第一次接触Kafka命令行会一直困惑“kafka-console-consumer启动一次会一直运行吗”答案是会的。它启动后就是一个持续运行的消费者进程不断从目标Topic拉取新消息并打印到控制台默认不会自己退出。想要退出用CtrlC。如果只是想消费固定条数验证数据可以加参数kafka-console-consumer.sh --bootstrap-server localhost:9092 \ --topic app-log \ --from-beginning \ --max-messages 10Windows环境下Kafka的所有命令行脚本都在bin/windows目录下后缀是.bat比如kafka-console-consumer.bat。对Windows用户来说最大的坑是路径和引号问题Kafka解压路径如果包含中文或者空格脚本经常报奇怪的类路径错误建议安装在纯英文且不带空格的目录或者直接用WSL跑Linux版脚本。另外如果只想快速验证生产者是否连通可以用kafka-console-producer手动输入几条消息测试但这个命令它也不会自动退出同样通过CtrlC结束。4.4 数据缺失与乱序的隐蔽问题Lag和重复消费是显性问题数据缺失和乱序则是藏得很深的坑。数据缺失常见原因是Filebeat的registry偏移文件出问题或者日志文件被移动、轮转后Filebeat没有正确跟踪到新文件。排查时先去Filebeat的logs目录看是否有读取异常再确认日志文件的权限和路径是否匹配配置。乱序问题在Kafka链路里要分情况看待。Kafka只保证单个分区内的消息有序跨分区不保证全局有序。如果你把同一业务下的日志都写入同一个分区那它们之间的顺序就是有保障的实现方式是用同一个key写入比如用业务订单号作为消息key。如果不用key走round-robin那么不同分区间的日志顺序可能交错这在大多数日志排查场景下可以接受。多行堆栈日志也容易造成日志解析乱象比如Java异常堆栈如果没配置multiline会被拆成几十条事件查询时只能看到异常信息分散在各行没法整体定位问题。解决办法就是前面filebeat配置里写的multiline匹配把异常堆栈按时间戳合并成一条。还有一个小细节是时区ES默认使用UTC存储时间Kibana展示时如果时区不对日志时间看起来会差八个小时记得在Kibana的高级设置里把时区切换成你本地的时区。最后再分享一个我自己的习惯。架构从ELK演进到ELFKK后我会把Kafka消费者组的Lag值做成监控指标设置阈值告警。这样Logstash或ES出问题的时候我能在积压还没影响业务时收到通知而不是等Kibana上查询明显变慢了才去排查。一条日志链路可靠性的关键往往不只在组件本身更要看你对链路每个环节有没有可见性。