因为这个配置，我差点搞垮了生产环境——5GB 日志 3 分钟定位根因

# 1. 确定故障时间窗口（人工翻看时间戳）
# 2. grep 提取异常
grep -c " 502 " /var/log/nginx/access.log
# 输出: 342 次 502

# 3. 看应用日志
grep -i "error\|timeout\|exception" /var/log/app/app.log | tail -20
# 输出: 线程池拒绝、连接超时

# 4. 看 DB 慢查询
grep "Query_time:" /var/log/mysql/slow.log | tail -5
# Query_time: 28.3s  ← 有一条 28 秒的慢查询

# 5. 人工推理：这三层日志的因果顺序是什么？

#!/bin/bash
# trim_logs.sh — 故障日志裁剪工具
# 用法: ./trim_logs.sh "2026-06-28 22:00" "2026-06-28 22:20"

START="$1"; END="$2"
OUTDIR="/tmp/fault_analysis_$(date +%s)"
mkdir -p "$OUTDIR"

# 裁剪三层日志
awk -v s="$START" -v e="$END"'$0 >= s && $0 <= e' /var/log/nginx/access.log > "$OUTDIR/nginx_access.log"
awk -v s="$START" -v e="$END"'$0 >= s && $0 <= e' /var/log/app/app.log > "$OUTDIR/app.log"
awk -v s="$START" -v e="$END"'$0 >= s && $0 <= e' /var/log/mysql/slow.log > "$OUTDIR/slow.log"

# 脱敏
sed -i 's/password=[^ ]*/password=***REDACTED***/g'"$OUTDIR"/*.log
sed -i 's/[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}/x.x.x.x/g'"$OUTDIR"/*.log

echo"✅ 完成，日志已保存到: $OUTDIR"

## 根因分析报告

### 异常模式识别
- 22:05-22:12 集中出现 502 错误（共 347 次）
- 影响路径：/api/payment/*（占 89%）
- 上游响应时间：50ms → 30s+（暴增 600 倍）

### 因果链还原
1. 22:03  MySQL 慢查询开始出现
   → slow.log "Query_time: 28.3s"（orders 表全表扫描）
2. 22:04  应用线程池耗尽
   → app.log "ThreadPool exhausted, rejecting task"
3. 22:05  Nginx upstream 超时，返回 502
   → access.log "upstream_timeout" + 502 status
4. 22:12  MySQL 慢查询消失，应用逐步恢复

### 根因
MySQL 订单表 status 字段缺少索引，
一条慢查询（28s）阻塞了数据库连接池，
引发应用线程池耗尽，最终表现为 Nginx 502。

### AI 额外发现（我漏掉的）
22:08 秒杀活动开始，流量突增 3 倍，
在慢查询的基础上加剧了线程池压力。
如果只修索引不处理秒杀流量的限流，下次还会出问题。

-- 为 orders 表添加联合索引
ALTER TABLE orders
ADD INDEX idx_status_created (status, created_at);
-- 影响: 全表扫描 → 索引扫描，耗时从 28s → 28ms

// 连接池超时和熔断配置
@Configuration
publicclassResilienceConfig {
@Bean
public RestTemplate paymentRestTemplate() {
returnnewRestTemplateBuilder()
            .setConnectTimeout(Duration.ofSeconds(3))
            .setReadTimeout(Duration.ofSeconds(10))
            .build();
    }

@Bean
public CircuitBreakerFactory paymentCircuitBreaker() {
// 当失败率超过 50% 时熔断，30秒后恢复
returnnewResilience4JCircuitBreakerFactory();
    }
}

# prometheus 告警规则
groups:
-name:mysql_slow_query
rules:
-alert:MySQLSlowQuerySpike
expr:rate(mysql_global_status_slow_queries[5m])>10
for:1m
labels: { severity:warning }
annotations:
summary:"MySQL 慢查询突增（当前 {{ $value }}/s）"

sed 's/^\(.\{500\}\).*/\1... [truncated]/' /tmp/app.log > /tmp/app_trimmed.log

□ 今天：把 trim_logs.sh 脚本部署到跳板机
□ 本周：在 3 个服务上测试 AI 日志分析
□ 本月：接入 Prometheus 慢查询监控
□ 持续：积累 AI 分析的 Prompt 模板库