先把当时的情况摆出来。排查问题时把日志级别临时调成 debug，忘了改回来，模型请求和响应全文都写进日志，一天写了 40GB，磁盘告警之后服务开始写失败。
原因不止一个，得分开看。debug 级别把请求体和响应体全量落盘。另一种情况是没有按天轮转和保留策略。
还有一种情况，临时调整没有到期自动恢复。另外，日志目录和数据目录在同一块盘。
第一件事是看日志目录增长速率
du -sh /var/log/app && ls -lt /var/log/app | head随后把全文日志改成只记摘要字段
python -c "print('log_fields=trace_id,model,tokens,latency')"接着配置按大小轮转并限制保留份数
python -c "print({'max_bytes':104857600,'backup_count':5})"末了把日志目录迁到独立分区
df -h /var/log/app恢复的判定其实很直接。日志目录日增从 40GB 降到 1.2GB，磁盘使用率稳定在 60% 以下，排查需要的字段仍然完整。
补一句。debug 级别在 LLM 服务里等于把全文写盘，量级和普通业务不是一个数量级；临时改动要带过期时间，或者用动态日志级别。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。