镜像仓库监控需聚焦存储空间增长、满盘预警和gc释放效果，而非仅关注镜像删除；应组合实际占用量、增长速率、gc偏差三类指标，分层设置告警，并确保delete.enabled和storage.delete.enabled开启以实现物理删除。
镜像仓库监控报警不能只盯着“删没删镜像”，关键要盯住存储空间谁在涨、什么时候会满、删了为什么还不释放——尤其是 Docker Registry 这类私有仓库，物理删除默认关闭，指标不细、告警不分层，很容易漏掉真实风险。
抓准核心指标：不只是磁盘使用率
Registry 的磁盘压力主要来自 /var/lib/registry/storage/blobs 目录，但单纯看 node_filesystem_usage_percent 容易误判。必须组合三类指标：
-
实际占用量：用
node_filesystem_size_bytes{mountpoint="/var/lib/registry/storage"} - node_filesystem_free_bytes{mountpoint="/var/lib/registry/storage"}算出真实用量（单位字节） -
增长速率：用
rate(node_filesystem_avail_bytes{mountpoint="/var/lib/registry/storage"}[1h])看每小时掉多少空间，比绝对值更早发现突增 -
GC 效果偏差：每15分钟对比
curl -s http://registry:5000/v2/_catalog?n=1 | jq '.repositories | length'和du -sh /var/lib/registry/storage/blobs | awk '{print $1}'，条目减少但 blobs 大小不变，说明 GC 没生效
配好分层告警规则，拒绝“狼来了”
一个阈值打天下容易疲劳，建议按影响程度分级触发不同动作：
-
预警级（85%）：
node_filesystem_usage_percent{mountpoint="/var/lib/registry/storage"} > 85→ Slack 发通知，人工核查最近推送的镜像和构建缓存 -
紧急级（95% 或 1h 掉超 500MB）：任一满足即自动执行清理脚本 → 停止 registry 写入、运行
registry garbage-collect /etc/docker/registry/config.yml --dry-run=false -
异常波动级：用
stddev_over_time(container_fs_usage_bytes{image=~".*ci.*|.*build.*"}[6h]) / avg_over_time(...)识别 CI 构建镜像层暴增，这类通常伴随日志写爆或中间层未清理
确保 GC 真正生效，否则报警只是摆设
Registry 默认只逻辑删除，blob 文件还在。必须确认配置已启用物理删除：
-
delete.enabled: true（开放 DELETE API） -
storage.delete.enabled: true（允许真正删 blob） - GC 执行前加校验：检查
config.yml中是否配置了storage.cache.blobdescriptor: inmemory，否则 GC 可能跳过部分 blob
联动构建与日志，从源头控增长
光清 registry 不够，得管住“进水口”：
- CI 流水线中加入镜像大小检查，超 500MB 自动失败并提醒优化基础镜像
- 所有构建容器挂载
/tmp和/var/log为 tmpfs，防止构建过程写爆宿主机磁盘 - 定期清理构建缓存：
docker builder prune -f --keep-storage 2g，避免 buildkit 缓存无声膨胀
