docker inspect 无法监控系统调用，因其仅读取配置文件（config.v2.json、hostconfig.json）和内存状态，不对接 perf/ebpf/strace 等 syscall 跟踪机制；需用 strace、bpftrace、perf 或 containerd debug 日志替代。
docker inspect 本身不采集或显示系统调用（syscall）开销。它是一个只读元数据查询命令，输出容器的配置、网络、挂载、状态等静态和运行时快照信息，但不包含系统调用频次、耗时、上下文切换或内核态行为等低层性能指标。
为什么 inspect 无法监控系统调用
docker inspect 读取的是 Docker 守护进程维护的 JSON 配置文件（如 config.v2.json、hostconfig.json）和内存中的状态结构（State），其数据源来自：
- /var/lib/docker/containers/
/config.v2.json（启动配置） - /var/lib/docker/containers/
/hostconfig.json（资源限制、网络等） - 运行时由 dockerd 维护的 in-memory state（如 StartedAt、ExitCode、OOMKilled）
这些文件不含 perf、eBPF、strace 或 /proc/
真正能监控系统调用开销的替代方案
若需在容器生命周期各阶段（如 start → running → paused → exited）分析 syscall 行为，应结合以下工具链：
-
使用 strace 进入容器进程空间跟踪：
docker top <container_id></container_id>获取主进程 PID →strace -p <pid> -e trace=all -T -o /tmp/strace.log</pid>（注意：需宿主机有 strace 且容器未禁用 ptrace） -
利用 eBPF 工具（推荐）：
使用
bpftrace或bpftool编写脚本，监听特定 PID 或 cgroup 路径下的 syscall 事件；例如：bpftrace -e 'tracepoint:syscalls:sys_enter_openat { printf("openat by %s\n", comm); }' -
通过 cgroup v2 + perf event：
容器运行时（如 runc）会将其进程归入对应 cgroup 路径（如 /sys/fs/cgroup/system.slice/docker-
.scope）；可用 perf record -e syscalls:sys_enter_* -C <cpu> --cgroup <path></path></cpu>捕获指定 cgroup 内所有 syscall -
配合 containerd 或 runc 的 debug 日志：
启动 containerd 时加
--log-level debug，可看到 runc exec/start/pause 等操作触发的底层 clone()、setns()、prctl() 等调用日志（非实时性能数据，但反映关键生命周期 syscall）
inspect 可辅助定位 syscall 分析时机
虽然 inspect 不提供 syscall 数据，但它能帮你精准锚定分析窗口：
- 用
docker inspect --format='{{.State.StartedAt}}' <id></id>获取精确启动时间，对齐 strace/perf 时间戳 - 用
docker inspect --format='{{.State.Paused}}' <id></id>确认 pause 是否生效，避免在 paused 状态下误抓 syscall - 检查
.HostConfig.CpusetCpus或.HostConfig.Memory，判断是否启用了严格资源隔离——这会影响 syscall 上下文切换开销 - 查看
.NetworkSettings.SandboxID，定位容器 netns 路径（/proc/<pid>/ns/net</pid>），便于用nsenter进入后执行 syscall 分析
