为什么周审比实时看日志有用
单看实时日志只能看到碎片，错误日志真正的价值在聚合后的分布与变化：哪几类错误占了大多数、环比涨了多少、是不是集中在某次发布之后。推理服务的日志尤其嘈杂，客户端断连、超时重试、参数校验失败会大量重复出现，如果不定期治理，真信号迟早被淹没。
基本信息
| 适用对象 | 推理服务的应用日志、网关访问日志与引擎日志 |
|---|---|
| 执行频率 | 每周一次，固定时间点 |
| 处理手段 | 日志文本聚合与归一化，或日志平台的分组统计 |
| 输出物 | 错误排行榜、环比变化、归属分类、行动项清单 |
| 责任人 | 当周值班负责人牵头，问题归属方认领 |
典型使用场景
- 找涨幅靠前的错误：环比变化最大的几类，往往直接对应最近的发布或新接入方
- 区分已知噪声与真实问题：客户端主动取消产生的错误属噪声，需要过滤而非修复
- 定位归属：把错误划到代码、配置、依赖服务或硬件，指派给对应团队
- 验证修复效果：上周立案的错误本周是否归零，闭环情况一目了然
- 优化日志本身：长期高频但无意义的日志降级或合并，降低存储与阅读成本
本地聚合思路
本地聚合思路
# 抓取错误行，把可变部分归一化后统计频次
grep -iE 'error|exception|timeout' <应用日志> \
| sed -E 's/[0-9a-f]{8,}/<ID>/g; s/[0-9]+/N/g' \
| sort | uniq -c | sort -rn | head -20
# 与上周结果对比，只看名次或数量发生变化的条目
diff <(cat last_week_top.txt) <(cat this_week_top.txt)错误分类与处置
| 类别 | 典型来源 | 处置方式 |
|---|---|---|
| 客户端断开 | 用户关闭页面、上游取消 | 降级为信息级或加白名单，不计入错误率 |
| 参数与鉴权失败 | 调用方传错字段、密钥过期 | 反馈给调用方，必要时增加入参校验提示 |
| 依赖超时 | 模型引擎、向量库、外部接口变慢 | 推进上游优化并调整超时与重试策略 |
| 服务端异常 | 代码缺陷、显存不足、序列化失败 | 建工单修复，补充回归用例 |
| 资源类告警 | 显存水位、连接数、文件描述符逼近上限 | 转入容量与配置调整流程 |
评审要盯变化量而不是绝对值：某个一直存在的错误并不可怕，可怕的是本周突然从个位数涨到上千，这类突变几乎总能对应到一次变更。
行动项必须有负责人与期限：只记录不指派，下周审阅时还是同一份榜单，噪声源不会自己消失。