Kafka服务端认证日志导致磁盘空间占满案例

鼠扑  论坛元老 | 2024-12-21 14:37:35 | 显示全部楼层 | 阅读模式
打印 上一主题 下一主题

主题 1072|帖子 1072|积分 3216

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有账号?立即注册

x


     某IP为44.2的服务器挂载的硬盘 服务器磁盘空间占满突然
<a name="2056-1718601914154">
故障排查过程

查看docker容器磁盘SIZE
<a name="5916-1718596204561">


查看docker容器 使用磁盘大小
<a name="2815-1718596024397">
此现在单独挂载路劲/data/docker
<a name="1686-1718595989289">

使用 du -sh * 查看, 发现kafka容器消耗91G空间
<a name="8871-1718596113106">



查看详细容器,判断是kafka
<a name="5176-1718596393990">


kafka容器状态
<a name="5047-1718596298732">





是客户端认证识机制,Kafka日志 每秒一直刷屏
<a name="9742-1718595123669"> Failed authentication with with IP  unexpected Kafka request for type METADATA during SASL handshake

现实是在消耗我们服务器磁盘空间
<a name="1754-1718595202078">

客户端日志如下
<a name="8625-1718595160954">





解决方案

1.操作我们使用docker-compose删除 kafka重启,重新构建后,磁盘空间规复
<a name="4233-1718602073547">

2. IP为44.1服务器环境中控系统连接Kafka认证失效异常必要修复


<a name="7764-1718602108642">

其他参考


Kafka集群日志数据过大堆积磁盘
<a name="3341-1718595859570">生产者在推送数据后,kafka通常会在data目录下对应的topic数据目录中生成日志信息,随着时间的增长,假如没有对日志作清算动作,那么必定导致磁盘的不可用。
清算策略</b>
<a name="5220-1718595859570">l log.cleanup.policy=delete,kafka日志的清算策略,默认是delete,就是根据设置的时间空间来清算日志;还可以设置成compact,当旧数据的回收时间大概尺寸限制到达时,会进行日志压缩。
# 必要自己根据现实环境设置log.retention.bytes=-1# 默认的保留时间是7天log.retention.hours=168
<a name="9538-1718595859570">值得注意的是log.retention.bytes表示的是每个topic下每个partition保存数据的总量;注意,这是每个partitions的上限,因此这个数值乘以partitions的个数就是每个topic保存的数据总量。同时注意:假如log.retention.hours和log.retention.bytes都设置了,则超过了任何一个限制都会造成删除一个段文件。这项设置可以由每个topic设置时进行覆盖。


结论

一、日志管理的重要性

Kafka的日志文件是其数据持久化和消息可靠性的基础,但日志文件过大也会占用大量磁盘空间,甚至导致服务异常。因此,有效的日志管理是至关重要的。
二、公道设置日志策略


  • 日志保留时间:Kafka允许设置消息的保留时间,超过该时间的消息将被删除。通过公道设置log.retention.hours等参数,可以有效控制日志文件的增长。
  • 日志压缩:Kafka提供了多种日志压缩策略,如启用日志清算工具等,以减小日志文件的大小,从而节流磁盘空间。
三、监控与预警机制


  • 实时监控:使用监控工具(如Prometheus、Grafana等)实时监控Kafka的磁盘使用环境,当磁盘空间靠近满时,可以收到警报并及时采取步伐。
  • 定期审查:定期审查Kafka的日志文件,确保没有异常增长或不必要的日志文件占用空间。
四、扩展磁盘容量

当现有的磁盘空间无法满足Kafka的存储需求时,应考虑扩展磁盘容量。这可以通过添加新的磁盘、升级现有磁盘或使用网络附加存储(NAS)等方式实现。
五、数据备份与规复


  • 数据备份:在清算日志文件或进行磁盘扩展之前,务必备份重要数据,以防止数据丢失或不一致。
  • 数据规复:在发生数据丢失或磁盘故障时,可以或许迅速规复数据,确保Kafka服务的一连性。
六、综合考量与平衡

在解决Kafka磁盘满的问题时,必要综合考虑日志清算、设置调整、监控、磁盘扩展等多个方面。同时,还必要根据现实环境衡量消息的可用性和磁盘空间的占用,选择符合的解决方案。


今天先到这儿,希望对云原生,技术领导力, 企业管理,系统架构设计与评估,团队管理, 项目管理, 产品管理,信息安全,团队建设 有参考作用 , 您大概感兴趣的文章:
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker先容
Docker与CI连续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理先容
软件项目乐成之要素
人际沟通风格先容一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才雇用与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通筹划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略订定与实验流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变 如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯,请关注我的微信订阅号:

作者:Petter Liu
出处:http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面显着位置给出原文连接,否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。


免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

鼠扑

论坛元老
这个人很懒什么都没写!
快速回复 返回顶部 返回列表