容器重建之后，昨天的证据还在不在

结论先行：容器带来一个很少被提前想到的副作用——出问题的那个实例，往往在排查开始之前就被重建掉了。容器本身是一次性的，日志与指标如果跟着它一起消失，事后能拿到的只有一段空白。要留住证据，取决于三件事：采集组件能不能随实例自动挂载而不需要改镜像、数据是不是落在实例之外、以及检测到异常时采集策略会不会从抽样切到全量。

本文只谈容器环境下观测数据的留存与取证，不谈终端采集该收哪些字段，也不谈网络侧怎么隔离容器之间的访问。

为什么这里的问题和传统环境不一样

在物理机或虚拟机上，排查的默认前提是「现场还在」。机器还在，日志文件还在，可以登录上去看、去 grep、去抓当前状态。

容器把这个前提取消了。一个实例因为内存超限被重启，原来的容器连同它的文件系统一起消失；一次滚动升级把旧实例逐个替换，出问题的那个版本在几分钟内就不存在了。等值班的人从告警里看到异常、打开平台、定位到是哪个实例，那个实例可能已经不在列表里。

所以容器环境的排查要换一个基本假设：不能假定现场存在，只能假定数据已经出去了。凡是需要「事后登录上去看」的东西，都要重新设计，让它在实例还活着的时候就离开实例。

其一：采集组件怎么进到容器里

这是最基础的一层，也是最容易被做成「需要改业务镜像」的一层。

如果采集组件要打进业务镜像，会遇到三个问题：镜像体积变大、每次升级业务都要跟着改镜像、以及多环境（开发、测试、生产）的镜像不一致。三个问题叠起来，结果是很多业务干脆不接采集——理由很正当：改镜像的风险归业务方承担，收益归运维。

可行的做法是让采集组件由平台侧注入，而不是由镜像携带。放到运行层做，业务镜像不动，新实例创建时自动挂上采集组件，实例销毁时随之退出。这样做还有一个附带好处：上线哪些业务接采集，变成平台侧的一个配置项，不再需要与每个业务方逐个协商改镜像。

注入方式要对业务透明，还有一层含义：不能要求容器以特权账号运行。有些采集手段需要访问宿主机的内核信息，实现方式是给容器特权，这在多数企业的安全规范里是过不去的。选型时要把「非特权模式下能不能采集」当作一项明确的核对项。

其二：数据落在哪里

这是决定证据能不能留住的核心。

三种落法各有代价。

三行里第三行是常规选择，但它带出一个必须解决的问题：网络断了怎么办。容器到采集端的链路中断，如果没有本地缓冲，这段数据就永久缺失，而链路中断往往与故障同时发生——恰好是最需要数据的那段时间。

所以核对项要加上一条：断连期间数据是否有本地缓冲、恢复后是否自动补传、缓冲的上限是多少（超出上限之后丢哪一段）。第三个问题最少被问到，但它在长时段断连时决定了损失范围。

其三：抽样还是全量

为了控制存储成本，调用链类数据通常按比例抽样。这在平时没有问题，出问题时会变成麻烦：异常请求恰恰是少数，抽样很容易把它们漏掉。

可行的做法是动态策略：日常低比例抽样，检测到错误率升高、超时增多或某类异常时，自动切到全量采集，并维持一段时间。这样成本在平时是可控的，在故障期间则拿得到完整数据。

这里要定一个容易忽略的细节：切换的判据是什么。用「错误率超过某个固定阈值」作判据，在低流量业务上会误触发（十个请求里一个失败就是百分之十）；用动态基线更稳，但建立基线需要历史数据。两种做法各有适用场景，关键是判据要写清，而不是留成「系统会自动判断」。

拓扑也要跟着实例走

容器环境下，服务之间的调用关系变化很快。实例重建后地址变了，拓扑如果还画着旧地址，排查时看到的是一张过期的地图。

可行的要求是拓扑随实例变化自动更新，且实例销毁后其观测数据要归档而不是丢弃——归档的意义在于，事后要看「上周那个版本的表现」时还有数据可查。这一点在滚动升级出问题时尤其重要：新版本表现异常，需要拿旧版本同时段的数据做对照，而旧实例早就没了。

另外要确认资源限额的使用情况能被观测到。容器被资源限制直接杀掉时，往往没有任何应用层日志，能说明问题的只剩宿主机侧记录的限额与使用曲线。缺少这一项，这类故障会被长期误判为「应用自己挂了」。

一个可以自查的顺序

不需要一次做完，按影响大小排顺序更实际。

• 先确认误杀类故障能被看见：容器因限额被杀时，有没有对应的记录。
• 再确认数据不随实例消失：采集组件是否平台注入、数据是否发往实例之外。
• 然后确认断连不丢数据：本地缓冲、自动补传、缓冲上限三项是否明确。
• 接着确认异常时切全量：判据写清、维持时长写清。
• 最后确认归档：实例销毁后数据保留多久、能不能按版本与时段检索。

五步里，起步那一步的投入最小、收益最直接。它解决的是「明明重启了却说不出为什么」这一类反复发生的困惑。

落地清单

• 采集组件由平台注入，不改业务镜像；确认非特权模式下可采集。
• 数据直接发往实例之外，不依赖容器内文件系统留存。
• 明确断连期间的本地缓冲、自动补传与缓冲上限。
• 日常抽样、异常全量，切换判据与维持时长写成明确规则。
• 拓扑随实例变化自动更新，不保留过期地址。
• 实例销毁后观测数据归档，可按版本与时段检索。
• 先做容器限额与误杀的可观测，这是投入最小的一步。

边界与前提

三点说明。其一，文中所述的采集注入、落点与抽样策略属一般性梳理，具体实现取决于所选的编排平台与监测产品能力，须以实际验证为准。其二，采集组件的资源占用、缓冲容量等指标会随业务规模变化，属参考性指标，落地前应在本环境测试。其三，涉及数据留存期限与归档要求的，须按行业监管与内部审计规定执行，本文不提供具体留存年限建议。

深圳市奇摩计算机有限公司是一家 IT 解决方案服务商，在可观测类项目里会把「实例没了数据还在不在」当作一项验收条件，而不是上线之后才发现证据跟着容器一起走了。预约咨询，可以先从容器限额与重启的记录查起。