更新时间:2024-12-06 GMT+08:00

ALM-38001 Kafka磁盘容量不足

告警解释

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

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

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

告警属性

告警ID

告警级别

是否自动清除

38001

重要

告警参数

参数名称

参数含义

来源

产生告警的集群名称。

服务名

产生告警的服务名称。

角色名

产生告警的角色名称。

主机名

产生告警的主机名。

设备分区名

产生告警的磁盘分区。

Trigger Condition

系统当前指标取值满足自定义的告警设置条件。

对系统的影响

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

可能原因

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

处理步骤

检查Kafka数据的磁盘配置。

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

    • 是,执行6
    • 否,手动清除该告警,操作结束。

  6. 检查“磁盘”区域中包含该告警中的磁盘分区使用率是否达到百分之百。

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

  1. 选择“集群 > 待操作集群的名称 > 服务 > Kafka > 配置 > 全部配置”。
  2. 查看“disk.adapter.enable”参数是否配置为“true”。

    • 是,执行10
    • 否,执行9

  3. 将“disk.adapter.enable”配置为“true”,开启该功能。然后查看“adapter.topic.min.retention.hours”所配置的数据最短保存周期是否合理。

    • 是,执行10
    • 否,根据业务需求合理调整数据保存周期。

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

  4. 等待10分钟,查看故障磁盘的使用率是否有减少。

    • 是,继续等待直到告警消除。
    • 否,执行11

检查Kafka数据规划。

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

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

    图1 Broker磁盘使用率

  3. 根据12的显示信息,查看是否只有2中上报告警的磁盘分区。

    • 是,执行14
    • 否,执行15

  4. 重新进行磁盘规划,挂载新的磁盘,进入当前问题节点“实例配置”页面,重新配置“log.dirs”,增加其他磁盘相应路径,重启当前Kafka实例。

    如果当前为滚动重启且当前Topic存在多副本,则对业务无影响。否则重启期间会导致Kafka服务不可用,依赖该服务的上层服务也将受到影响。

  5. 查看Kafka配置的数据保存时间配置,根据业务需求和业务量权衡,考虑是否需要调小数据保存时间。

    • 是,执行16
    • 否,执行17

  6. 在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=“保存时间

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

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

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

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

    • 是,执行18
    • 否,执行19

  8. 通过Kafka客户端对Topic的Partition进行扩展,命令行操作命令如下:

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

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

  9. 考虑是否需要扩容。

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

    • 是,执行20
    • 否,执行21

  10. 扩展磁盘容量,扩展后检查告警是否消失。

    • 是,操作结束。
    • 否,执行22

  11. 检查告警是否清除。

    • 是,操作结束。
    • 否,执行22

收集故障信息。

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

告警清除

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

参考信息

  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实例的运行状态是否为“良好”