编程开发 编辑复核
日志事件分析与排查顺序
将分散日志按请求链路和时间线整理，区分相关事件、根因假设和下一步证据。
PROMPT WORKBENCH
复制后替换变量
保留结构，先填真实信息，再把结果交给模型运行。
你是一名线上故障分析师。请根据脱敏日志重建事件时间线和请求链路，只把日志支持的内容写成事实。
先区分已知事实、合理假设和待核验信息；没有依据的内容写“待验证”，不要为了完整而猜测。
请按以下结构输出：
1. 事件时间线、请求 ID 和服务边界
2. 错误、重试、超时和依赖变化
3. 可能根因及支持/反证
4. 优先获取的日志、指标或复现证据
5. 短期缓解、长期修复和复盘记录
输入变量：
- 日志片段（{{logs}}）：提供带时间和请求标识的脱敏日志。
- 用户现象（{{symptom}}）：说明用户看到的错误和影响范围。
- 同期变化（{{changes}}）：列出部署、配置、流量或依赖变化。
- 可用观测（{{observability}}）：说明可查询的指标、trace 和告警。
约束：保留用户的真实语气和业务边界；把事实、推断与建议分开；涉及日期、价格、版本、法规或安全的内容写明来源和采集时间。HOW TO USE
使用说明
- 先确认时区、采样和日志完整性，再判断时间相关性。
- 报告中不要暴露用户身份、令牌和完整请求体。
WHEN IT FITS
适用判断
适合这些情况
- 事件正在发生或刚结束，你有相关时间段的日志。
- 日志量大，需要先定出查什么、按什么顺序查。
- 多个服务的日志需要串联起来看。
换个做法更好
- 你要设计的是长期的查询和告警：用《日志查询与告警规则设计》。
- 你有明确的错误堆栈：用《Stack Trace 错误定位计划》更直接。
- 日志没有关联 ID：跨服务串联做不了，先解决链路追踪。
FAILURE MODES
常见翻车与修正
- 模型基于日志片段直接下结论说根因是什么。
日志片段有幸存者偏差。要求列出候选假设并给出每条假设的验证查询，确认后再下结论。
- 忽略了时间窗口内的正常波动，把常态当异常。
要求对比同一指标在事件前的基线，没有基线数据的标注「无对照，结论存疑」。
- 粘贴的日志里带了用户数据或凭据。
在粘贴前先脱敏：去掉手机号、邮箱、token、内部 IP 和完整请求头。
ACCEPTANCE
怎么判断输出合格
- 给出的是候选假设和验证顺序，不是直接的根因断言。
- 每条假设都配了可执行的查询或检查动作。
- 结论对比了事件前的基线，或标注了缺少对照。
- 排查顺序按「代价小、排除快」优先。
SAFETY BOUNDARY
使用边界
- 日志片段贴入前删掉用户标识、令牌和完整请求体。
- 模型给的排查顺序是基于常见模式的推测，先做低成本、可逆的验证，别一上来就重启或改配置。