Storm 1.2.3 如何清理已终止作业日志 解决自动清理配置不生效问题

内置清理功能失效的核心原因 #

• 作用域配置错配：Storm 1.2.3的Logviewer清理逻辑分为两条独立链路，logviewer.cleanup.*开头的参数仅作用于Logviewer进程管理的常规logs/工作目录，不会自动扫描清理workers-artifacts/路径下的作业归档内容。后者由专门的artifact清理线程管控，对应配置项默认处于关闭状态，不会自动启动，这是配置修改后清理功能完全不触发的核心原因。
• 配置生效流程缺失：所有logviewer.*开头的配置项修改完成后，必须重启集群全部节点上的Logviewer进程才能加载生效，仅修改storm.yaml不重启进程时，新配置完全不会被读取。
• 状态同步校验不通过：Logviewer的清理逻辑在执行删除前，需要从Nimbus拉取实时的活跃作业ID列表作为校验基准，若节点到Nimbus的网络连通性异常、状态缓存同步超时，清理线程会直接跳过本轮执行，不会触发任何删除动作。

让内置清理功能正常覆盖目标路径的修复步骤 #

• 开启artifact清理线程：在storm.yaml中追加对应配置，启用workers-artifacts目录的清理规则，将该目录纳入Logviewer的扫描范围：

  logviewer.artifact.cleanup.enabled: true
  logviewer.artifact.cleanup.age.mins: 30
  

  注意需要和原有常规日志清理配置区分：原配置中的logviewer.cleanup.age.mins仅对常规运行日志生效，artifact目录的清理时长由独立的配置项控制，两者不可混用。
• 完成配置加载校验：重启所有节点的Logviewer进程后，查看Logviewer的运行日志，确认启动流程中出现Starting artifact cleanup worker的输出，若没有该日志则说明配置未正常加载，需要排查storm.yaml的语法格式错误。
• 打通节点状态同步链路：逐节点验证Logviewer进程到Nimbus服务端口的连通性，确保每个节点能实时拉取到最新的活跃作业列表——只有拿到准确的作业运行状态，清理逻辑才会自动跳过仍在运行的作业对应的目录，仅清理已终止作业、且超过配置保留时长的归档目录。

低误删风险的替代清理方案 #

如果内置清理逻辑调试复杂度较高，可以采用带作业状态校验的自定义规则，从根源上避免误删运行中作业的日志：

• 基于Storm原生CLI的定时清理脚本
  调用Storm官方命令拉取当前所有活跃运行的作业ID列表，遍历workers-artifacts/下的所有目录，按照目录命名规则提取对应的jobID，仅当匹配不到活跃作业、且目录最后修改时间超过设定的保留阈值时，才执行删除操作。参考实现逻辑：

  # 拉取集群当前所有活跃作业的ID列表
  ACTIVE_JOB_IDS=$(storm list 2>/dev/null | grep -E '^[0-9a-f]{24}' | awk '{print $1}')
  # 遍历目标日志目录
  for dir in /path/to/storm_log_path/workers-artifacts/*/; do
    dir_name=$(basename "$dir")
    job_id=$(echo "$dir_name" | cut -d'-' -f1)
    # 校验规则：不在活跃列表、且目录超过30分钟无更新才删除
    if ! echo "$ACTIVE_JOB_IDS" | grep -q "$job_id" && [ $(( $(date +%s) - $(stat -c %Y "$dir") )) -gt 1800 ]; then
      rm -rf "$dir"
    fi
  done
  

• 适配logrotate的安全清理规则
  调整原有logrotate的配置文件，在规则中增加prerotate前置执行段，每次触发清理前先调用Storm API获取活跃作业列表，自动跳过所有匹配活跃作业ID的目录，从规则层面避免纯时间匹配逻辑带来的误删风险。

内容的提问来源于stack exchange，提问作者Tarek