先看现象。新版模型灰度上线时把日志级别调到 debug 以便观察，两天后节点磁盘写满 100%，kubelet 开始驱逐 Pod，灰度被迫中断。
排查方向其实有限，先把可能性排一排。debug 级别把完整 prompt 与响应都写进日志。也可能是日志没有按天轮转，单文件涨到 60GB。
另外，采集端全量上报，没有采样与丢弃策略。
少数情况下是灰度结束后日志级别没有恢复。
先看哪个目录涨得最快
du -sh /var/log/containers/* | sort -h | tail -5接着把日志级别调回 info 并开启轮转
kubectl set env deploy/llm-api LOG_LEVEL=info LOG_MAX_SIZE=500MB然后对采样日志按 trace 比例上报
python -c "print('sample_ratio 0.05 by trace_id hash % 20 == 0')"末了确认磁盘水位与写入速率回落
df -h /var/lib/docker && kubectl top pod -l app=llm-api同事提醒我看一下最近一次发布，时间点确实对得上。
怎么算真的好了，看的是同一批现象。磁盘水位从 100% 回落到 42%，单 Pod 日志日增量从 30GB 降到 1.2GB，灰度观察所需的错误日志仍然完整。
灰度期要看的是错误与延迟分布，不需要全量正文，采样加轮转两项配好，比事后清理磁盘省事。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。