var/log/system.log、exception.log 或第三方模块日志每天增长几十 GB，很快占满磁盘并拖慢站点。直接删除日志只能释放一次空间；如果同一错误每秒写数百行，文件几分钟又会回来。第一步是找出最高频的错误指纹和触发来源。
先按文件和时间确认增长点
du -h var/log/* | sort -h
tail -n 5000 var/log/system.log
find var/log -type f -printf '%s %p\n' | sort -n | tail生产日志可能在其他目录、容器 stdout 或集中系统中，先确认真正占磁盘的位置。不要对仍在写入的大文件直接反复复制，否则会加重 I/O。
把动态值去掉后统计错误指纹
同一个异常可能因订单号、SKU、时间或 request ID 不同，看起来每行都不一样。抽样后识别异常类、文件行号、SQL 错误码和固定消息，用日志系统聚合计数。重点是每分钟出现多少次、从何时开始、与哪个发布或流量来源相关。
常见放大器包括：机器人访问不存在 URL、Cron 每分钟失败、消费者遇到坏消息无限重试、模板每个商品循环记录 warning、第三方 API 超时后无退避重试。
先停止重复触发，再讨论日志级别
如果消费者处理同一消息不断失败，暂停该 consumer 或隔离坏消息比关闭日志安全；如果机器人制造异常，可在保持正确状态码的前提下通过 WAF/速率限制控制；如果 Cron 配置错误，应修复任务而不是删除 cron_schedule。
把 logger 调到更高等级会隐藏症状，但业务仍在失败。只有确认信息没有行动价值时，才降低某条可预期日志的等级或增加去重/采样。
检查是否记录了敏感数据
支付、API 和登录模块可能把 Authorization、Token、客户地址或完整请求写入日志。日志暴涨同时扩大泄露面。立即脱敏并轮换可能暴露的凭据，访问日志文件应受最小权限控制。
正确轮转避免应用继续写旧 inode
使用 logrotate 或日志平台生命周期按大小和日期轮转、压缩、保留。直接 rm 一个被进程打开的文件，磁盘空间可能直到进程重启才释放。轮转方案要支持当前 PHP/consumer 的 reopen 或 copytruncate 策略，并评估 I/O。
异常修复后继续记录关键错误，但设置告警：增长速率、磁盘水位、单一指纹频率和丢日志。验证至少覆盖一个 Cron 周期和队列高峰，确认日志回到正常基线，业务功能也恢复。
