log-analysis

Log Analysis

Applicable Scenarios

• Root cause localization for production issues
• Error log analysis
• Slow request tracing
• User behavior tracking (within compliance scope)
• Log pattern recognition

Core Principles

1. Trace ID 是线索
   一个请求的所有日志用 trace_id 串联

2. 结构化日志
   JSON 格式，可搜索、可聚合

1. From metrics to logs First look at Grafana to locate the time range Then look at logs to locate the specific request

2. Don't search for "everything" in logs First narrow the scope (time + service + level)

3. Logs are not monitoring Logs are for troubleshooting, not for alerting Use metrics for alerting

## 排障流程

```text
1. 确定时间范围
   - 告警触发时间
   - 用户报告时间
   ↓
2. 确定服务
   - 哪个服务出问题
   - 上下游
   ↓
3. 看指标（Grafana）
   - 错误率突增？
   - 延迟突增？
   - QPS 变化？
   ↓
4. 看日志（Loki / ELK）
   - 过滤 ERROR / WARN
   - 用 trace_id 追踪
   ↓
5. 看追踪（Jaeger / Tempo）
   - 哪个 span 慢？
   - 哪个服务超时？
   ↓
6. 定位根因
   - 代码 Bug？
   - 配置错误？
   - 资源不足？
   - 第三方故障？
   ↓
7. 修复或升级

Loki Query (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 Query (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"

Common Troubleshooting Patterns

Sudden Error Spike

1. 看错误率图（Grafana）→ 确定开始时间
2. 对比最近部署时间
3. 过滤 ERROR 日志
4. 按 error_code 分组 → 找最多的
5. 用 trace_id 看完整链路
6. 定位到具体代码 / 配置

Sudden Latency Spike

1. 看 P99 图 → 确定开始时间
2. 看追踪（Jaeger）→ 哪个 span 慢
3. 如果是 DB → 看慢查询日志
4. 如果是第三方 → 看第三方状态
5. 如果是 GC → 看 JVM / Node 指标

Intermittent Issues

1. 收集多次发生的时间点
2. 找共同模式（定时任务？流量高峰？）
3. 对比正常 vs 异常时的日志差异
4. 看资源使用（是否接近上限时才出现）

Supporting Templates

• templates/troubleshooting-template.md — Troubleshooting record template

Quality Self-Check

□ 用 trace_id 追踪
□ 先缩小范围再搜索
□ 从指标到日志（不反过来）
□ 结构化查询（不 grep 全文）
□ 记录排障过程（复盘用）
□ 定位到根因（不停在现象）

Common Pitfalls

1. grep full-text search——too slow, use structured queries
2. Not narrowing the time range——too many logs
3. Not using trace_id——cannot trace across services
4. Only looking at your own service——the problem may be upstream
5. Logs are not structured——cannot perform aggregation analysis
6. Not recording the troubleshooting process——next time you start from scratch

Collaboration with Other Skills

上游：
  incident-response → 事故中排障
  devops-engineer monitoring-alerting → 指标入口

下游：
  postmortem → 根因分析
  backend-engineer → 代码修复