第6章 容器与分布式取证

第 6 章 · 容器与分布式取证

章节摘要：容器和微服务给取证带来两类新麻烦：命名空间与 cgroup 让传统工具"看不见"或"看错"（盲区），跨服务的调用链让单机证据无法解释端到端延迟（断层）。本章处理盲区修复、链路追踪的证据链组织，以及持续剖析这种"常驻线上的广域监控"模式。

学习目标

1. 列举容器环境的三类观测盲区及其修复手段；
2. 解释分布式追踪的 trace/span 模型与采样策略；
3. 说清持续剖析的架构与开销预算；
4. 用"控制面取证"思路处理多机案件的归因。

核心概念速览

单机时代证据在 /proc 里；分布式时代证据在"上下文传播"里——谁带着 trace 上下文，谁就在作证。

子章节导航

6.1 容器现场：命名空间下的观测盲区

/proc 的骗局、cgroup 指标错位、PMC 不可用，三类盲区的解法。

6.2 跨服务追踪：分布式链路的证据链

trace/span 模型、采样策略与尾部采样、从链路到根因的推理。

6.3 持续剖析：常驻线上的广域监控

always-on profiling 的架构、开销预算与数据价值。

子章节之间的逻辑关系

6.1 修复"看不见"（单机盲区）
        │
        ▼
6.2 组织"跨机证据链"（链路追踪）──→ 6.3 把剖析常态化（持续剖析）
​

前置知识与后续延伸

• 前置：第 4 章的单机排查、第 2 章的采样机制。
• 为后续铺垫：第 7 章的低延迟与 AI 辅助分析都建立在常驻观测之上。

本章的观测拼图

单机取证的证据形态在容器与分布式环境下各有缺口：容器一节补的是"视角"缺口——cgroup 配额、宿主与容器两套 /proc 口径、sidecar 旁路采集的部署形态；链路一节补的是"关联"缺口——trace 上下文传播的完整性验证与从链路图到单机证据的三步定罪法；持续剖析一节补的是"历史"缺口——常驻采样让任意时间窗都有画像可回溯。速查：

# 视角对账: 配额与实际用量
cat /sys/fs/cgroup/.../memory.{current,events} && crictl stats
# 链路完整性: 找断链的一跳
grep -R traceparent config/ | grep -v propagate
# 画像回溯: 异常窗口与基线差分
./prof-diff.sh --svc payment --window "$WIN" --baseline 7d-ago
​

落地顺序建议

如果团队从零建设：先上链路追踪（解决"案发在哪个服务"的定向问题），再上持续剖析（解决"服务内哪个函数"的定位问题），最后补齐容器视角对账（防止容量类误判）。顺序反了会出现"有画像不知道该看哪个实例"或"有链路下钻后无证据可看"的断层。三块拼齐后，一次 P99 劣化案件的定罪时间可以从小时级压到分钟级——这正是取证体系化对单次工具调用的复利优势。

一句话记住每节

容器一节：指标口径先问"谁的视角"，配额与用量分属两套读数，混淆即误判。链路一节：trace 完整性先于一切分析，断链的一跳本身就是线索；从最长 span 与最长 gap 入手做减法。持续剖析一节：先编资源预算再谈常驻，画像的价值靠与指标、告警的联动查询兑现。三句话分别对应视角、关联、历史三个缺口，也是分布式环境相对单机取证的全部新增复杂度——理解了缺口在哪，工具怎么选就不再是问题。