如何测量Docker镜像中实际被容器内进程访问的内容占比？

容器镜像未使用文件检测方案 #

容器专属工具

有和dive定位类似的专用工具可以直接完成这类检测，不需要手动造轮子：

• SlimToolkit（原docker-slim）：是目前最匹配需求的工具，核心功能就是动态分析容器运行时的文件访问行为。你只需要用它启动你的容器执行业务测试流程，它会自动跟踪所有被进程访问的文件，最终输出两份核心结果：一是镜像中所有未被访问的多余文件列表，二是镜像的实际使用率统计，甚至可以直接基于分析结果自动构建裁剪后的精简镜像，全程不需要修改原有镜像的任何内容。
• Trivy：知名的镜像安全扫描工具，在v0.38.0之后新增了未使用内容扫描能力，可以识别镜像中未被进程依赖的系统库、二进制文件、静态资源等，也能直接输出资源浪费比例，适合集成到CI流水线里做自动检测。

通用Linux技术实现方案

如果不想引入额外的容器专属工具，用原生Linux能力也可以实现：

• 基于inotify的用户态监控：在容器启动时，通过宿主机进入容器的mount namespace，启动inotifywait监控容器根目录的所有文件读取事件，待业务流程跑完后，把收集到的访问文件列表和镜像的原始文件列表做差集，即可得到未使用的文件清单，计算使用率。
• 基于eBPF的内核态监控：用bpftrace或者自定义eBPF脚本，在内核态捕获对应容器PID namespace下的所有文件打开/读取操作，开销远低于用户态监控，适合生产环境下无侵入的在线检测。

atime的可靠性说明 #

默认场景下不建议用atime做文件访问判断，原因有两个：

• 绝大多数Linux发行版默认使用relatime挂载参数，只有当文件的mtime/ctime比atime更新，或者atime超过24小时未更新时才会刷新atime，短生命周期的容器中大量文件访问不会触发atime更新，统计结果会严重不准。
• 很多容器运行时（比如Docker、Containerd）为了提升文件系统性能，会默认给容器根目录添加noatime挂载参数，直接关闭atime的更新，这种场景下atime完全没有参考意义。

auditd的适用性 #

不需要给镜像内置auditd：

• 内置auditd不仅会增大镜像体积，还需要容器运行在特权模式才能加载审计规则，侵入性极高，不推荐这种方案。
• 如果你确实想用审计能力，可以直接在宿主机侧配置audit规则，定向监控对应容器的文件系统路径，不需要修改镜像，但相比SlimToolkit或者eBPF方案，auditd的配置复杂度更高，事件噪音也更多，没有特殊需求不需要优先选用。

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