分析步骤
步骤 1：获取日志数据
使用 query_logs 查询{{.ServiceName}}服务的错误日志，时间范围是{{.TimeRange}}
如果没有 ERROR 日志，改为查询 WARN 级别观察异常趋势。
步骤 2：分组分析错误类型
按 msg 模式对错误日志进行分组，识别 top 错误类型：
- 统计各类错误出现的频次
- 关注突增的错误模式
步骤 3：抽样追踪典型错误
对步骤 2 里挑出的代表性错误，用 query_logs 把时间范围缩小到它前后 1 分钟（绝对时间写法），去掉级别过滤，看完整上下文：
- 选取不同错误类型的代表性时间点
- 分析同一时间窗内其他服务是否同时报错，判断故障方向
步骤 4：综合分析根因
关联以上步骤的发现，综合判断：
- 错误模式是否集中在某个服务或接口
- 如果有部署或配置变更信息可查，检查时间线是否吻合。没有相关信息时不要猜测关联。
- 是否存在级联故障（上游服务异常导致下游报错）
- 对比更早的时间窗口，判断错误率变化趋势
- 环境/地区特异性：错误是否只出现在特定环境（OSS/内网）、特定地区？
如果是，在代码中搜索确认该环境确实有差异化配置（访问控制、功能开关等），而非假设存在 - 跨服务追踪：错误涉及跨服务调用时，必须追踪到被调用方实现（路由 → 中间件 → handler → 下游），确认错误实际发生层级
- 前端相关：若 stack 或日志指向浏览器/小程序端，结合 sourcemap 与用户路径还原；区分网络错误与业务错误。
- 前端监控：若有 RUM/前端 SDK 上报，与后端 trace 时间线对齐后再下结论。
步骤 5：输出结构化报告
请输出结构化报告，包含：
- 摘要：一句话结论
- 影响范围：服务、接口/路径、环境（OSS/内网）、地区
- 错误 Top N：消息模式、频次、代表性样例（可脱敏）
- 根因分析：基于日志分组与 trace 的证据链；避免无依据猜测
- 建议：缓解措施、需跟进项、是否需要变更或开关调整