现场是这样的。服务把请求和响应整体序列化进访问日志，一次长文生成有三万 token，单条日志 30MB，日志盘 40GB 两天就满，采集端还因为单行过长直接丢弃。
中间走过弯路，把「行内 JSON 没有长度上限保护」当成主因，改完现象没变。
这类报错背后常见的原因有几处，逐个排除就行。日志直接打完整响应体，没有任何截断；流式分片被拼进同一行，长度随生成线性增长；采集端单行上限默认只有 64KB，超长被丢。
先统计日志单行长度的分布
awk '{print length($0)}' app.log | sort -n | tail -3只记录首尾片段与 token 计数
python -c "print({'head':200,'tail':200,'tokens':0})"给日志加轮转与压缩
logrotate -f /etc/logrotate.d/app采集端调大单行上限并加截断
python -c "print('max_line_bytes=1048576')"别只看报错消失，验证要多做一步。单条日志长度小于 4KB，日志日增量小于 2GB，采集端不再报行超长，排障需要的字段仍能查到。
容易忽略的是，排查时想留全文，跑起来又嫌太大，折中是单独落一份带轮转的样本目录，不要全塞进访问日志。报错文案容易误导，真正的原因往往在相邻那一层的日志里。