ALM-38001 Kafka磁盘容量不足

告警解释

系统按60秒周期检测Kafka磁盘空间使用率，并把实际磁盘使用率和阈值相比较。磁盘使用率默认提供一个阈值范围。当检测到磁盘使用率高于阈值时产生该告警。

用户可通过“运维 > 告警 > 阈值设置”，在服务列表下面，选择“Kafka > 磁盘 > Broker磁盘使用率 (Broker)”修改阈值。

平滑次数为1，Kafka磁盘使用率小于或等于阈值时，告警恢复；平滑次数大于1，Kafka磁盘使用率小于或等于阈值的90%时，告警恢复。

告警属性

告警参数

对系统的影响

磁盘容量不足会导致Kafka写入数据失败。

可能原因

• 用于存储Kafka数据的磁盘配置（如磁盘数目、磁盘大小等），无法满足当前业务数据流量，导致磁盘使用率达到上限。
• 数据保存时间配置过长，数据累积达到磁盘使用率上限。
• 业务规划不合理，导致数据分配不均，使部分磁盘达到使用率上限。

处理步骤

检查Kafka数据的磁盘配置。

1. 在FusionInsight Manager管理界面，选择“运维 > 告警 > 告警”。
2. 在告警列表中单击该告警，从“定位信息”中获得主机名。
3. 选择“集群 > 待操作集群的名称 > 主机”。
4. 在“主机”页面单击2中获取的主机名称。
5. 检查“磁盘”区域中是否包含该告警中的磁盘分区名称。
   • 是，执行6。
   • 否，手动清除该告警，操作结束。

6. 检查“磁盘”区域中包含该告警中的磁盘分区使用率是否达到百分之百。
   • 是，参考参考信息进行处理。
   • 否，执行7

检查Kafka数据保存时间配置。

7. 选择“集群 > 待操作集群的名称 > 服务 > Kafka > 配置 > 全部配置”。
8. 查看“disk.adapter.enable”参数是否配置为“true”。
   • 是，执行10。
   • 否，执行9。

9. 将“disk.adapter.enable”配置为“true”，开启该功能。然后查看“adapter.topic.min.retention.hours”所配置的数据最短保存周期是否合理。
   • 是，执行10。
   • 否，根据业务需求合理调整数据保存周期。
   

   启用磁盘自适应功能可能导致Topic的历史数据被清除，如果有个别Topic不能做保存周期调整，单击“全部配置”，将Topic配置在“disk.adapter.topic.blacklist”参数中。

10. 等待10分钟，查看故障磁盘的使用率是否有减少。
    • 是，继续等待直到告警消除。
    • 否，执行11。

检查Kafka数据规划。

11. 选择上报告警实例主机名对应的角色“Broker”。单击图表区域右上角的下拉菜单，选择“定制”，来自定义监控项。
12. 在弹出的“定制”对话框中，选择“磁盘 > Broker磁盘使用率”，并单击“确定”。

    关于Kafka磁盘使用情况信息会被显示。

    图1 Broker磁盘使用率
    

13. 根据12的显示信息，查看是否只有2中上报告警的磁盘分区。
    • 是，执行14。
    • 否，执行15。

14. 重新进行磁盘规划，挂载新的磁盘，进入当前问题节点“实例配置”页面，重新配置“log.dirs”，增加其他磁盘相应路径，重启当前Kafka实例。
15. 查看Kafka配置的数据保存时间配置，根据业务需求和业务量权衡，考虑是否需要调小数据保存时间。
    • 是，执行16。
    • 否，执行17。

16. 在FusionInsight Manager界面，选择“集群 > 待操作集群的名称 > 服务 > Kafka > 配置 > 全部配置”，在右侧搜索框中填写配置项名称“log.retention.hours”，然后会显示该配置的当前值，此处的值为Topic默认的数据保存时间，可以适当调小该值。
    

    • 对于单独配置数据保存时间的Topic，修改Kafka服务配置页面上配置的数据保存时间不生效。

    • 如果需要对某个Topic单独配置的话，可以使用Kafka客户端命令行，来单独配置该Topic。

      例如：kafka-topics.sh --zookeeper “ZooKeeper地址:2181/kafka” --alter --topic “Topic名称” --config retention.ms=“保存时间”

17. 查看是否由于某些Topic的Partition配置不合理导致部分磁盘使用率达到上限（例如：数据量非常大的Topic的Partition数目小于配置的磁盘个数，导致各磁盘上数据分配无法均匀，进而部分磁盘达到使用率上限）。
    

    如果不清楚哪些Topic业务数据量较大，可以参考如下步骤查询：

    1. 根据2中获取到的主机节点信息，登录实例节点。
    2. 进入对应的数据目录（即14中“log.dirs”修改之前的配置路径）。
    3. 执行以下命令查看该目录下哪些Topic的Partition目录占用的磁盘空间比较大。

       du -h --max-depth=1 ./

    • 是，执行18。
    • 否，执行19。

18. 通过Kafka客户端对Topic的Partition进行扩展，命令行操作命令如下：

    kafka-topics.sh --zookeeper “ZooKeeper地址:2181/kafka” --alter --topic “Topic名称” --partitions=“新Partition数目”

    

    • 新Partition数目建议配置为Kafka数据磁盘数量的倍数。
    • 当前步骤修改可能不会很快解决当前告警，需要结合11中的数据保存时间逐渐均衡数据。

19. 考虑是否需要扩容。
    

    建议当前Kafka磁盘使用率超过80%时，则需要扩容。

    • 是，执行20。
    • 否，执行21。

20. 扩展磁盘容量，扩展后检查告警是否消失。
    • 是，操作结束。
    • 否，执行22。

21. 检查告警是否清除。
    • 是，操作结束。
    • 否，执行22。

收集故障信息。

22. 在FusionInsight Manager界面，选择“运维 > 日志 > 下载”。
23. 在“服务”中勾选待操作集群的“Kafka”。
24. 单击右上角的设置日志收集的“开始时间”和“结束时间”分别为告警产生时间的前后10分钟，单击“下载”。
25. 请联系运维人员，并发送已收集的故障日志信息。

告警清除

此告警修复后，系统会自动清除此告警，无需手工清除。

参考信息

1. 登录FusionInsight Manager，选择“集群 > 待操作集群的名称 > 服务 > Kafka > 实例”，将运行状态为“正在恢复”的Broker实例停止并记录实例所在节点的管理IP地址以及对应的“broker.id”，该值可通过单击角色名称，在“实例配置”页面中选择“全部配置”，搜索“broker.id”参数获取。
2. 以root用户登录记录的管理IP地址，并执行df -lh命令，查看磁盘占用率为100%的挂载目录，例如“${BIGDATA_DATA_HOME}/kafka/data1”。
3. 进入该目录，执行du -sh *命令，查看该目录下各文件夹的大小。查看是否存在除“kafka-logs”目录外的其他文件，并判断是否可以删除或者迁移。
   • 是，删除或者迁移相关数据，然后执行8。
   • 否，执行4。

4. 进入“kafka-logs”目录，执行du -sh *命令，选择一个待移动的Partition文件夹，其名称命名规则为“Topic名称-Partition标识”，记录Topic及Partition。
5. 修改“kafka-logs”目录下的“recovery-point-offset-checkpoint”和“replication-offset-checkpoint”文件（两个文件做同样的修改）。
   1. 减少文件中第二行的数字（若移出多个目录，则减少的数字为移出的目录个数）。
   2. 删除待移出的Partition所在的行（行结构为“Topic名称 Partition标识 Offset”，删除前先将该行数据保存，后续此内容还要添加到目的目录下的同名文件中）。

6. 修改目的数据目录下（例如：“${BIGDATA_DATA_HOME}/kafka/data2/kafka-logs”）的“recovery-point-offset-checkpoint”和“replication-offset-checkpoint”文件（两个文件做同样的修改）。
   • 增加文件中第二行的数字（若移入多个Partition目录，则增加的数字为移入的Partition目录个数）。
   • 添加待移入的Partition行到文件末尾（行结构为“Topic名称 Partition标识 Offset”，直接复制5中保存的行数据即可）。

7. 移动数据，将待移动的Partition文件夹移动到目的目录下，移动完成后执行chown omm:wheel -R Partition目录命令修改Partition目录属组。
8. 登录FusionInsight Manager，选择“集群 > 待操作集群的名称 > 服务 > Kafka > 实例”，启动停止的Broker实例。
9. 等待5至10分钟后查看Broker实例的运行状态是否为“良好”。
   • 是，修复完成后按照“ALM-38001 Kafka磁盘容量不足”告警指导彻底解决磁盘容量不足问题。
   • 否，联系运维人员。