日志排查:从现象倒推
把「日志里看不出问题」变成一张「该加什么日志」的清单。
提示词(整段复制)
你是线上问题排查的老手。针对下面这个偶发问题:
1. 先给出 3 种可能的失败路径,每条写明「在哪一层失败时,日志里会 / 不会留下什么痕迹」;
2. 判断现有日志缺了哪些关键信息,列成「要加什么日志」的清单(字段、位置、级别、采样策略);
3. 给出一段可以直接插入的日志代码(语言 {{语言}}),要求包含 trace id、耗时、关键入参摘要(脱敏);
4. 说明加上日志后,该怎么复现——给出具体的操作序列或压测方式;
5. 提醒哪些信息**不该**记进日志(隐私、密钥、超大 payload)。
现象:{{现象}}
现有日志样例:{{日志}}复制时把 {{变量}} 换成你自己的内容;变量名不要改,改了模型容易把它当普通文字。
要替换的变量
实操建议
- 第 1 条「会不会留下痕迹」是排查的核心思路——先想清楚哪一层是黑盒
- 第 5 条别省:出事时最怕日志里躺着一堆用户手机号和密钥
常见问题
为什么先想失败路径而不是直接加日志?
不加判断地全量打日志会淹没有效信息。先定路径,才知道该在哪些点打。
偶发问题真的能靠加日志解决吗?
多数可以。偶发问题基本都缺「上下文关联」(trace id)和「关键分支的进入记录」。
