直接检查JENKINS_HOME/jobs/下log文件数量比查磁盘空间更能快速定位inode耗尽根源，因Jenkins默认不轮转构建日志，每个build生成一个log文件，长期运行易突破ext4 inode上限。
直接看 JENKINS_HOME/jobs/ 下的构建日志数量，比查磁盘空间更能快速定位 inode 耗尽的根源。Jenkins 默认不轮转构建日志，每个 build 生成一个 log 文件（哪怕只有几 KB），长期运行后极易突破 ext4 文件系统的 inode 上限。
确认是否为 inode 耗尽而非磁盘空间不足
执行以下命令快速验证：
-
df -i—— 查看各挂载点的 inode 使用率，重点关注JENKINS_HOME所在分区（如/var或/home）是否接近 100% -
find $JENKINS_HOME/jobs -name "log" | wc -l—— 统计所有构建日志文件总数；超 5 万条即属高风险 -
ls -l $JENKINS_HOME/jobs/*/builds/ | head -20—— 抽样观察是否存在大量低序号（如#1、#2）但未被清理的旧构建目录
临时止血：手动清理陈旧构建日志
避免服务中断，优先清理明确无用的历史产物：
Zenlink - Node SDK for ZenHeart
下载
ZenHeart zenlink 与 zenlink-mcp 为 OpenClaw，涵盖安装、MCP 注册、钩子接线、入站轮询及升级维护。
- 进入 Jenkins Web 界面 → 每个 job → “配置” → 勾选“丢弃旧的构建”，设置“保持构建的最大个数”（建议 ≤ 30）
- 对已废弃或低频 job，可直接在文件系统执行：
find $JENKINS_HOME/jobs/*/builds/ -maxdepth 1 -mindepth 1 -type d ! -name "[0-9]*" -delete（清理非数字命名的异常目录）find $JENKINS_HOME/jobs/*/builds/ -maxdepth 1 -mindepth 1 -type d -name "[0-9]*" -not -newermt "90 days ago" -exec rm -rf {} +（删除 90 天前的构建目录） - 清理后再次运行
df -i，确认 inode 使用率回落
根治方案：启用两级日志生命周期管控
仅靠 Jenkins 内置保留策略不可靠（依赖定时任务、易被跳过），必须结合外部轮转与 Jenkins 自身配置：
-
一级：logrotate 管控
builds/*/log文件
新建/etc/logrotate.d/jenkins-buildlogs：$JENKINS_HOME/jobs/*/builds/*/log {<br> daily<br> rotate 7<br> compress<br> missingok<br> notifempty<br> create 644 jenkins jenkins<br>}
注意：需确保 logrotate 用户（如jenkins）有读写权限；测试运行logrotate -d /etc/logrotate.d/jenkins-buildlogs -
二级：Jenkins 全局策略兜底
管理界面 → “系统配置” → “全局构建日志清理策略” → 启用“按天清理”并设为 60 天；同时为每个 job 单独配置“丢弃旧的构建”，数值略低于 logrotate 的rotate值（如设为 5）
长效监控与告警建议
将 inode 风险纳入日常运维闭环：
- 添加定时检查脚本（如每日 6 点执行）：
if [ $(df -i | grep "$(dirname $JENKINS_HOME)" | awk '{print $5}' | sed 's/%//') -gt 85 ]; then echo "ALERT: Jenkins inode usage >85%" | mail -s "Jenkins inode warning" admin@example.com; fi - 在 Prometheus + Grafana 中采集
node_filesystem_files_free指标，对JENKINS_HOME分区设置 90% inode 使用率告警 - 每季度审计
$JENKINS_HOME/jobs/*/builds/下平均构建数，若持续高于 50，说明策略未生效或 job 设计不合理（如误配“始终构建”）
