日志分析（Log Analysis）
适用场景
- 生产问题根因定位
- 错误日志分析
- 慢请求追踪
- 用户行为追踪（合规范围内）
- 日志模式识别
核心原则
1. Trace ID 是线索
一个请求的所有日志用 trace_id 串联
2. 结构化日志
JSON 格式，可搜索、可聚合
3. 从指标到日志
先看 Grafana 定位时间范围
再看日志定位具体请求
4. 不在日志里找"所有"
先缩小范围（时间 + 服务 + 级别）
5. 日志不是监控
日志用于排查，不用于告警
告警用指标
排障流程
1. 确定时间范围
- 告警触发时间
- 用户报告时间
↓
2. 确定服务
- 哪个服务出问题
- 上下游
↓
3. 看指标（Grafana）
- 错误率突增？
- 延迟突增？
- QPS 变化？
↓
4. 看日志（Loki / ELK）
- 过滤 ERROR / WARN
- 用 trace_id 追踪
↓
5. 看追踪（Jaeger / Tempo）
- 哪个 span 慢？
- 哪个服务超时？
↓
6. 定位根因
- 代码 Bug？
- 配置错误？
- 资源不足？
- 第三方故障？
↓
7. 修复或升级
Loki 查询（LogQL）
# 基础：按服务 + 级别
{app="order-service"} |= "ERROR"
# 按 trace_id
{app="order-service"} |= "trace_id=abc123"
# JSON 解析 + 过滤
{app="order-service"} | json | level="error" | status_code >= 500
# 统计错误率
rate({app="order-service"} |= "ERROR" [5m])
# 按错误码分组
sum by (error_code) (
count_over_time({app="order-service"} | json | level="error" [1h])
)
ELK 查询（KQL）
# 基础
service: "order-service" AND level: "ERROR"
# 时间范围
@timestamp >= "2026-05-19T14:00:00" AND @timestamp <= "2026-05-19T15:00:00"
# Trace ID
trace_id: "abc123"
# 状态码
response.status: >= 500
# 排除噪音
NOT message: "health check"
常见排障模式
错误突增
1. 看错误率图（Grafana）→ 确定开始时间
2. 对比最近部署时间
3. 过滤 ERROR 日志
4. 按 error_code 分组 → 找最多的
5. 用 trace_id 看完整链路
6. 定位到具体代码 / 配置
延迟突增
1. 看 P99 图 → 确定开始时间
2. 看追踪（Jaeger）→ 哪个 span 慢
3. 如果是 DB → 看慢查询日志
4. 如果是第三方 → 看第三方状态
5. 如果是 GC → 看 JVM / Node 指标
间歇性问题
1. 收集多次发生的时间点
2. 找共同模式（定时任务？流量高峰？）
3. 对比正常 vs 异常时的日志差异
4. 看资源使用（是否接近上限时才出现）
配套模板
templates/troubleshooting-template.md — 排障记录模板
质量自检
□ 用 trace_id 追踪
□ 先缩小范围再搜索
□ 从指标到日志（不反过来）
□ 结构化查询（不 grep 全文）
□ 记录排障过程（复盘用）
□ 定位到根因（不停在现象）
常见坑
- grep 全文搜索——太慢，用结构化查询
- 不缩小时间范围——日志太多
- 不用 trace_id——跨服务追不到
- 只看自己服务——问题可能在上游
- 日志不结构化——无法聚合分析
- 不记录排障过程——下次从零开始
与其他 skill 的协作
上游：
incident-response → 事故中排障
devops-engineer monitoring-alerting → 指标入口
下游：
postmortem → 根因分析
backend-engineer → 代码修复
zhaoxuya520