【kafka】记一次kafka磁盘空间爆满问题处理

最新推荐文章于 2025-05-13 00:05:07 发布

朝寒

最新推荐文章于 2025-05-13 00:05:07 发布

阅读量6.3k

点赞数 1

分类专栏： kafka 文章标签： kafka

本文链接：https://blog.youkuaiyun.com/weixin_42488171/article/details/127018500

版权

本文记录了一次处理Kafka节点磁盘使用率达到80%告警的经历。通过检查发现该节点异常，调整__consumer_offsets的cleanup.policy为compact，并观察到5分钟后磁盘使用率从90%降至20%。使用的是kafka_2.11-0.10.0.1版本。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

问题如下：
1、今天忽然出现告警，kafka某节点出现磁盘使用率超过80%告警，回顾最近操作，没有什么大业务变动，此kafka集群已经平稳运行1300多天；
2、检查集群发现，只有此节点有异常，磁盘空间消耗过度；
百度了下，然后如下方案成功解决

查看现有的__consumer_offsets清理策略

bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name __consumer_offsets --describe

会有如下输出可以看到 cleanup.policy=compact，则说明cleanup.policy是compact

Configs for topics:__consumer_offsets are segment.bytes=104857600,cleanup.policy=compact,compression.type=producer

__consumer_offsets的确与普通topic在清理策略上不同，也就是参数cleanup.policy上，给__consumer_offsets手动添加了清理策略

bin/kafka-configs.sh --zookeeper localhost:2181 --entity-type topics --entity-name __consumer_offsets --alter --add-config 'cleanup.policy=delete'

添加完后检查变成了：

bin/kafka-configs.sh --zookeeper localhost:

最低0.47元/天解锁文章

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

朝寒

关注关注

1
点赞
踩
7

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
举报

举报

专栏目录

Debezium系列之：详细记录一次在不重启kafka集群的情况下清空Kafka日志文件的方法

zhengzaifeidelushang的博客

10-12

1302

Debezium系列之：详细记录一次在不重启kafka集群的情况下清空Kafka日志文件的方法

kafka占用磁盘空间过大

mianhuabushitang的博客

09-30

6964

生产环境服务器目前生产上kafka占用磁盘地方过大。运维建议优化。因为数据量大。且数据会备份到mongodb，所以kafka数据不需要保存太久。目前kafka 使用的是默认配置，默认配置中有两项配置可优化 log.retention.hours清理超过指定时间清理 log.retention.bytes超过指定大小后，删除旧的消息目前默认配置存放时间是7天而且大小无限大，我们可以将存放时间缩小且设定默认大小（存在风险是可能会丢数据）注：日志的真正清除时间。...

参与评论您还未登录，请先登录后发表或查看评论

Kafka磁盘写满日志清理操作

qq_32323239的博客

10-24

4670

最近项目组的kafka集群，老是由于应用端写入kafka topic的消息太多，导致所在的broker节点占满，导致其他的组件接连宕机。这里和应用端沟通可以删除1天之前的消息来清理磁盘，并且可以调整topic的消息存活时间。

Kafka数据磁盘占满处理

m0_58377962的博客

05-02

321

如果对Kafka数据存储有一定了解，可以知道：Kafka主题数据是以分区为单位存储于磁盘中。在创建主题的时候，会往log.dir配置的磁盘按一定规则创建分区文件夹（不同副本的分区不会在同一节点上）。当往某个主题写数据时，broker会找到对应分区，然后数据根据算法（一般是Robin）写到对应分区。如果某个磁盘中的分区一直在往里写数据，但又未达到数据定期删除的时间阈值（默认7天），则很容易将磁盘写满，导致后续数据无法写入。此时该节点的broker很容易宕机，进而影响业务。

kafka磁盘爆满

qianzhina的专栏

06-28

4837

1，在cm上查询kafka数据目录： log.dirs：/var/local/kafka/data 2，查看目录下各子目录占用空间大小情况，过滤上G的topic数据 du -sh * | sort -nr | grep 'G' | grep 'channel' 3，修改topic数据的的有效期命令，优化 kafka-topics --zookeeper zk1:2181 -topic topicname --alter --config retention.ms=86400000 4..

kafka磁盘100%写满，数据不允许删除处理方案

sunxunyong的博客

07-22

482

5、data01修改recovery-point-offset-checkpoint 和 replication-offset-checkpoint 文件。1、在重启Broker的过程中服务不会中断，但是从每个Broker重启完成之后的5分钟内消费的分区消息可能会发生乱序。3、重启Broker期间，各个分区处理的消息量也会出现一定的不均衡，需要您评估一下升级变更对您业务可能产生的影响。2、重启过程中已有的客户端连接可能会中断。需要您的客户端有自动重连功能，服务端的其他Broker会自动接替服务。

【KAFKA】KAFKA磁盘爆满

shen12138的博客

03-31

4114

磁盘爆满后，cd /data/kafka_log/ du -sh *|grep 'G'查看发现dbaudit的topic占用很多，所以通过以下命令进行数据清理。 # 设置删除超过24小时数据清除 ./bin/kafka-configs.sh --zookeeper 10.35.16.252:2181 --alter --entity-name dbaudit --entity-type topics --add-config retention.ms=86400000 # 如果一天磁盘仍然不够，设置删

kafka磁盘写满处理

replaceit的博客

02-28

4335

kafka日志写满处理

记一次ecs云盘满的处理docker 磁盘日志爆满的处理

wuqingsssss的博客

12-29

432

案发现场：测试服务器，CPU&内存2 核8 GiB，系统盘100G，跑着gitlab，docker，没有其他什么玩意，正式的代码基本还没有扔上去。docker里跑着kafka，apollo，redis，eureka，zentao，postgre，mysql等常用的组件。gitlab里跑着开发的仓库。案情：服务器磁盘使用88%，快满了，读写小于10M，iops500，cpu 25%，内存87%，分析由于使用着docker，本身就吃内存，内存87%可以理解，但是磁盘明显不对劲，筛查 df明细

高吞吐与低延迟的博弈：Kafka与RabbitMQ数据管道实战指南

最新发布

lgf228的专栏

05-13

1340

本文全面对比Apache Kafka与RabbitMQ在数据管道中的设计哲学、核心差异及协同方案。结合性能指标、应用场景和企业级实战案例，揭示Kafka在高吞吐流式处理中的优势与RabbitMQ在复杂路由和低延迟传输方面的独特特点；介绍了使用Java生态成熟第三方库（如Apache Kafka Client、Spring Kafka、RabbitMQ Java Client、Spring AMQP等）的快速集成与性能调优方法。通过流程图、表格化分析和代码实例，提供从技术选型到全链路集成的完整实践指南。

ElasticSearch-Kafka-RabbitMQ

weixin_73241486的博客

04-04

1562

Elasticsearch 是基于 Lucene 的 Restful 的分布式实时全文搜索引擎，每个字段都被索引并可被搜索，可以快速存储、搜索、分析海量的数据。Kafka是分布式发布-订阅消息系统是一个可划分的，冗余备份的持久性的日志服务，它主要用于处理流式数据。组件:主题(Topic)：Kafka主题是一堆或一组消息。生产者(Producer)：在Kafka，生产者发布通信以及向Kafka主题发布消息。消费者(Consumer)：Kafka消费者订阅了一个主题，并且还从主题中读取和处理消息。

kafka高速导入数据引发的磁盘占满问题

weixin_38932035的博客

06-01

1556

今天Kafka出现了一个问题，测试多线程高速生产数据，造成磁盘占满了。我们的kafka配置文件策略如下： log.retention.bytes=1073741842 # topic每个分区的文件存储大小 1G log.segment.bytes=536870921 # topic每个分区的每个段的文件存储大小 512M log.retention.check.interval.ms=60000 #检测时间60s log.segment.delete.delay.ms = 60000 #标记删除延时

Kafka __consumer_offsets 占用磁盘空间过大处理

Li Nan 的博客

06-20

3310

kafka 位移分区清理策略

kafka linux根目录满,Linux磁盘空间满的诡异问题解决方案

weixin_35733151的博客

04-29

460

问题描述：今天登上一台服务器，df -h 发面根目录磁盘已经满了解决过程：cd /du -sh * 发现并没有大文件，占用的空间没多大根据经验，先通过lsof | grep deleted查找有没有没有释放空间的进程，然后 kill -9 pid也没有发现这下诡异了，然后仔细分析根目录下各个目录，发现 /data目录，使用的是挂载盘，而且挂载盘的空间利用很小，那么问题来了。挂载盘的空间，是放ES...

kafka磁盘100%数据清理方式恢复

sunxunyong的博客

07-22

725

3-找到占用空间较多或者明确不需要的Topic，选择其中某些Partition，从最早的日志数据开始删除。2、将业务日志数据（非Kafka内部Topic数据）按照从旧到新的方式删除，直到释放出足够的空间。1-不能删除Kafka内部的Topic数据，即不能删除以下划线（_）开头命名的Topic。3、重启磁盘被写满的相应的Broker节点，使日志目录online。2-不可直接删除Kafka的数据目录，避免造成不必要的数据丢失。1、到对应主机的磁盘找到可以删除的业务数据。写满磁盘存在允许删除的业务数据。

kafka存储数据量过大，导致磁盘爆满

weixin_33862514的博客

04-26

9517

问题：注意到自己负责kafka的某个topic最小的偏移量为0，而最大的偏移量都7亿多了，说明存储在kafka里面的数据没有定时删除，通过登陆到kafka服务器，查看配置文件services.properties，发现log.retention.hours=876000（100年），我猜想配置kafka的人是怕数据丢失，直接保存了所有的数据。方法：我这边修改为log.retention...

kafka日志文件容量过大导致服务器磁盘爆满

热门推荐

DreamsArchitects的博客

09-18

1万+

问题：由于kafka的数据量太大，倒是日志文件太大，将磁盘撑爆了，集群宕机。解决方法：先进入主题分区将.log文件删除，然后修改kafka配置文件server.properties:

如何估算和监控kafka持久化对磁盘的占用避免磁盘满导致的服务故障

2301_77020411的博客

05-16

1026

**总体磁盘占用**：总磁盘占用 = topic数 * partition数 * 分区大小 + Kafka元数据和其他开销。- **Kafka自带的脚本**：Kafka提供了一些脚本如`kafka-log-dirs.sh`和`kafka-topic.sh`，可以帮助你查看topic和broker级别的磁盘使用情况。- **定期审查topic和partition**：检查是否有不再使用的topic或过度分割的partition，及时清理或调整以减少不必要的磁盘占用。这取决于消息体的内容和编码方式。

kafka java jvm 优化_kafka-jvm内存大小设置以及优化

weixin_31608325的博客

02-26

1976

[root@soa-prod-elasticsearch-010171107044 /usr/local/services/elasticsearch-5.1.2/bin] 21:34:31 0vim elasticsearch#!/bin/bash# CONTROLLING STARTUP:## This script relies on few environment variables to...

mq的死信队列解释一下

03-01

<think>好的，我现在需要解释MQ中的死信队列。首先，用户可能已经了解过Feign和MQ的区别，现在想深入理解死信队列的概念。用户可能是开发人员或者系统架构师，需要在实际项目中使用或优化消息队列。首先，我应该回忆死信队列的基本定义。死信队列（Dead Letter Queue，DLQ）是用于存储无法被正常消费的消息的队列。当消息在特定条件下无法被处理时，会被转移到DLQ中，以便后续处理或分析。接下来，需要确定触发消息进入死信队列的条件。根据之前的知识，常见的条件包括消息被消费者明确拒绝、消息过期（TTL）、队列达到最大长度等。需要逐一列出这些条件，并给出具体例子，比如消息重试次数超过限制。然后，解释死信队列的作用。用户可能想知道为什么需要这个机制，比如处理异常情况、避免消息丢失、方便问题排查等。要强调DLQ在系统健壮性和可维护性中的重要性。可能用户还会关心如何配置死信队列，比如在RabbitMQ或Kafka中的具体实现方式。但用户的问题主要是解释概念，所以需要保持简洁，但可以提到常见MQ系统的处理方式。需要举一个实际的应用场景，比如订单超时未支付的处理，用死信队列来实现延迟重试或记录日志。这样用户能更好地理解其实际用途。另外，需要区分死信队列和其他机制，比如重试队列。死信队列是最终处理无法消费的消息，而重试队列可能还会尝试重新投递。这一点要说明清楚，避免混淆。还要注意结构清晰，分点列出触发条件、核心作用、应用场景和配置示例。可能使用代码片段或配置示例来增强理解，比如RabbitMQ的配置参数。最后，总结死信队列的重要性，并提醒用户在处理消息时合理配置DLQ，以提高系统的可靠性和可维护性。确保语言通俗易懂，避免过于技术化的术语，但又要准确无误。</think>--- ### 死信队列（Dead Letter Queue, DLQ）核心解析 **一句话定义**：死信队列是消息队列中专门存储 **"处理失败消息"** 的隔离队列，相当于消息系统的 **"急诊室"**，用于隔离、诊断和处理异常消息。 --- ### 一、消息进入死信队列的 **3大触发条件** | 触发条件 | 典型场景示例 | 处理逻辑 | |-------------------------|----------------------------------|-----------------------------------| | **消息被明确拒绝** | 消费者手动发送`basic.reject`或`basic.nack`且不重新入队 | 消息立即进入DLQ | | **消息存活超时（TTL）** | 消息设置10秒有效期，超时未被消费 | 到期后自动转入DLQ | | **队列达到最大限制** | 队列设置最大长度1000，新消息超出限制 | 最旧的消息被挤出队列进入DLQ | --- ### 二、死信队列的 **4个核心作用** 1. **故障隔离** - 将异常消息与正常业务流量分离，避免"毒药消息"（反复失败的消息）阻塞正常处理 - 示例：错误格式的消息会持续导致消费者崩溃，隔离后不影响其他消息处理 2. **重试管理** - 通过TTL+DLQ实现 **延迟重试机制**（比直接重试更可控） - 典型方案：首次失败 → 进入DLQ → 设置5分钟延迟 → 重新投递回业务队列 3. **审计追踪** - 保留所有失败消息，便于事后分析系统问题 - 可通过DLQ中的消息反推业务逻辑缺陷或数据异常 4. **最终兜底** - 防止消息永久丢失，为人工干预提供最后机会 - 运维人员可手动从DLQ取出消息进行补偿处理 --- ### 三、经典应用场景 #### 案例1：支付订单超时关闭 ```plaintext 正常队列：order_pay DLQ：order_pay_dlq 1. 用户下单生成消息（TTL=15分钟） 2. 若15分钟内未支付，消息自动进入DLQ 3. 监听DLQ的服务触发订单关闭操作 ``` #### 案例2：消息格式升级兼容 ```plaintext 旧版本服务无法解析新格式消息 → 消息进入DLQ 运维人员将DLQ消息转换格式后重新投递 ``` --- ### 四、RabbitMQ配置示例 ```java // 声明死信交换机和队列 @Bean public DirectExchange dlxExchange() { return new DirectExchange("dlx.exchange"); } @Bean public Queue dlxQueue() { return new Queue("dlx.queue"); } @Bean public Binding dlxBinding() { return BindingBuilder.bind(dlxQueue()).to(dlxExchange()).with("dlx.routingKey"); } // 业务队列绑定死信配置 @Bean public Queue businessQueue() { Map<String, Object> args = new HashMap<>(); args.put("x-dead-letter-exchange", "dlx.exchange"); // 指定死信交换机 args.put("x-dead-letter-routing-key", "dlx.routingKey"); // 指定路由键 args.put("x-message-ttl", 60000); // 消息存活时间60秒 args.put("x-max-length", 1000); // 队列最大容量1000条 return new Queue("business.queue", true, false, false, args); } ``` --- ### 五、最佳实践建议 1. **监控告警** - 对DLQ设置消息数量阈值告警（如1小时内积累超过100条即报警） 2. **TTL分层** ```plaintext 首次失败 → DLQ1（延迟1分钟重试）二次失败 → DLQ2（延迟10分钟重试）三次失败 → 人工处理队列 ``` 3. **消息染色** - 在消息头添加`retry-count`字段记录重试次数 4. **清理策略** - 设置DLQ消息保留时间（如最多保存7天），避免磁盘爆满 --- ### 六、与重试队列的区别 | | **死信队列** | **重试队列** | |------------------|----------------------------------|----------------------------------| | 定位 | 最终兜底机制 | 临时缓冲机制 | | 消息处理 | 需要人工介入或特殊处理 | 系统自动重新投递 | | 典型实现 | RabbitMQ的DLX机制 | Kafka消费者自行维护重试逻辑 | | 消息生命周期 | 可能永久留存 | 达到最大重试次数后进入DLQ | 通过合理使用死信队列，可使消息系统具备 **自我修复能力** 和 **故障容忍度**，是构建可靠分布式系统的必备机制。