监控告警方案

版本：v1.0 最后更新：2025-01 负责人：基础架构组 状态：已评审

1. 监控体系架构

1.1 监控分层

本平台采用"全栈可观测性"理念，从基础设施到业务层实现全覆盖。

1.2 数据流

┌─────────────┐     ┌──────────────────┐     ┌───────────────────────────────┐
│   应用服务   │────▶│ OTel Agent/Sidecar│────▶│   OTel Collector              │
└─────────────┘     └──────────────────┘     │  ├─→ Prometheus（指标）         │
┌─────────────┐     ┌──────────────────┐     │  ├─→ Jaeger（链路追踪）         │
│   基础设施   │────▶│ Node Exporter    │────▶│  └─→ Loki（日志）              │
└─────────────┘     └──────────────────┘     └───────────────────────────────┘
┌─────────────┐     ┌──────────────────┐
│   数据库     │────▶│ PG Exporter      │────▶ Prometheus
└─────────────┘     └──────────────────┘
┌─────────────┐     ┌──────────────────┐
│   缓存       │────▶│ Redis Exporter   │────▶ Prometheus
└─────────────┘     └──────────────────┘
┌─────────────┐     ┌──────────────────┐
│   消息队列   │────▶│ RabbitMQ Exporter│────▶ Prometheus
└─────────────┘     └──────────────────┘

数据流路径：应用 → OpenTelemetry Agent → Collector → Prometheus + Jaeger + Loki

1.3 技术选型依据

1.4 部署架构

┌─────────────────────────────────────────────────┐
│               Grafana（统一看板）                  │
│         告警 → Alertmanager → 飞书/短信/电话        │
└─────────────────────────────────────────────────┘
         ▲              ▲              ▲
    Prometheus      Loki           Jaeger
         ▲              ▲              ▲
         └──────────────┴──────────────┘
                        ▲
              OTel Collector（网关）
         ▲         ▲         ▲         ▲
      应用服务   基础设施   数据库    中间件

2. 业务指标监控

2.1 核心业务指标

2.2 业务看板

2.2.1 实时大屏（运营中心）

• 顶部指标卡：实时 QPS、成功率（试单/订单）、P99 延迟、活跃供应商数
• 时序趋势图：查价 QPS 24h 趋势、成功率趋势、延迟分位图
• 地图视图：查询热力分布（按城市/区域）
• 告警横幅：当前活跃告警数量及最高级别

2.2.2 供应商健康度矩阵

• 按可用率排序，红黄绿三色标记
• 点击可下钻到供应商详情页
• 支持按城市、星级筛选

2.2.3 代理商 TOP10

• 下单量 TOP10
• GMV TOP10
• 查价频次 TOP10
• 异常行为检测（频繁试单不下单）

2.2.4 收入趋势

• 日/周/月 GMV 趋势
• 各供应商收入占比
• 佣金收入趋势
• 同比/环比分析

2.3 自定义指标接入规范

// 应用内 Metrics 定义示例
var (
    rateRequestTotal = promauto.NewCounterVec(
        prometheus.CounterOpts{
            Name: "b2b_rate_request_total",
            Help: "Total number of rate requests",
        },
        []string{"supplier", "hotel_code", "status"},
    )

    rateLatency = promauto.NewHistogramVec(
        prometheus.HistogramOpts{
            Name:    "b2b_rate_latency_seconds",
            Help:    "Rate request latency",
            Buckets: []float64{.01, .025, .05, .1, .25, .5, 1, 2, 5, 10},
        },
        []string{"supplier", "hotel_code"},
    )
)

3. 系统指标监控

3.1 服务器监控

3.1.1 基础指标

3.1.2 Docker 容器监控

3.2 数据库监控

3.2.1 PostgreSQL 核心指标

3.2.2 慢查询监控

# 慢查询采集配置
pg_stat_statements:
  min_execution_time: 1000  # > 1s 记录为慢查询
  track: all
  max: 10000

• 所有 > 1s 的查询自动记录到 pg_stat_statements

• 5s 的查询触发 P2 告警

• 30s 的查询触发 P1 告警

• 慢查询 Top10 看板每小时更新

3.2.3 表大小增长趋势

• 每日采集前 20 大表及其增长速率
• 表大小增长率 > 10%/天 触发 P3 通知
• 自动生成清理建议（vacuum/归档）

3.2.4 死锁检测

-- 死锁监控查询
SELECT datname, query, wait_event, state, wait_event_type
FROM pg_stat_activity
WHERE wait_event_type = 'Lock'
  AND state = 'active'
  AND query_start < now() - interval '30 seconds';

• 任何死锁立即触发 P1 告警
• 自动记录死锁详情到日志
• 与 AI Agent 联动自动分析死锁原因

3.3 缓存监控（Redis）

3.4 消息队列监控（RabbitMQ）

4. 告警分级与路由

4.1 告警分级

4.2 告警规则

4.2.1 基础设施告警规则

4.2.2 数据库告警规则

4.2.3 应用告警规则

4.2.4 业务告警规则

4.2.5 中间件告警规则

4.3 告警抑制与聚合

4.3.1 抑制规则

# Alertmanager 抑制配置
inhibit_rules:
  # P0 抑制同服务 P1/P2
  - source_match:
      severity: P0
    target_match_re:
      severity: 'P1|P2'
    equal: ['alertname', 'service']

  # 节点 down 抑制该节点所有其他告警
  - source_match:
      alertname: NodeDown
    target_match_re:
      alertname: '.*'
    equal: ['instance']

  # PG 主库 down 抑制从库告警
  - source_match:
      alertname: PGPrimaryDown
    target_match_re:
      alertname: 'PGReplicationLag.*'
    equal: ['cluster']

4.3.2 聚合规则

# Alertmanager 路由与聚合
route:
  group_by: ['alertname', 'cluster', 'service']
  group_wait: 30s        # 同组告警等待 30s
  group_interval: 5m     # 同组新告警 5min 后发送
  repeat_interval: 4h    # 重复告警 4h 一次
  routes:
    - match:
        severity: P0
      repeat_interval: 5m    # P0 每 5min 重复
    - match:
        severity: P3
      group_interval: 1h
      repeat_interval: 24h   # P3 每日一次

4.3.3 维护窗口静默

# 创建静默规则示例（维护窗口）
amtool silence add \
  --author="ops" \
  --comment="计划维护：数据库版本升级" \
  --duration=2h \
  matcher="cluster=hotel-prod" \
  matcher="severity=~P1|P2|P3"

• 发布流程自动创建静默窗口
• 维护结束后自动解除
• 静默期间 P0 告警仍然发出

4.4 告警通知模板

4.4.1 飞书机器人消息模板

🚨 [P1-严重] PG 主库复制延迟过高

📌 告警详情
  • 集群：hotel-prod-pg-primary
  • 指标：复制延迟 = 32.5s
  • 阈值：> 10s
  • 持续：2 分钟
  • 时间：2025-01-15 14:32:18

🔗 快速链接
  • Grafana 看板：https://grafana.internal/d/pg-overview
  • 值班手册：https://wiki.internal/runbook/pg-replication-lag
  • 确认处理：https://alertmanager.internal/silence/xxx

👤 通知人：@值班-DBA @值班-运维

5. AI Agent 自动响应

与第 12 章 AI 智能运营层联动，实现告警的自动诊断与修复。

5.1 分级自动处理策略

5.2 AI Agent 能力

5.2.1 自动诊断

告警触发 → AI Agent 接收
  ├─ 收集上下文（指标、日志、链路追踪、变更记录）
  ├─ 关联分析（最近部署、配置变更、流量变化）
  ├─ 根因推断（基于知识库 + 历史案例）
  └─ 输出诊断报告

5.2.2 自动止血操作

5.2.3 自动修复与验证

# AI Agent 修复流程
ai_remediation:
  steps:
    1. 诊断：
       - 执行根因分析
       - 匹配 Runbook
    2. 执行：
       - 调用运维 API 执行修复
       - 记录操作审计日志
    3. 验证：
       - 检查指标是否恢复
       - 确认告警自动解除
    4. 通知：
       - 发送处理报告
       - 更新事故单状态
    5. 沉淀：
       - 生成事故复盘草稿
       - 更新知识库

5.3 AI Agent 接口规范

{
  "alert": {
    "id": "alert-20250115-001",
    "severity": "P1",
    "name": "PGReplicationLagHigh",
    "instance": "hotel-prod-pg-primary",
    "value": 32.5,
    "threshold": 10,
    "duration": "2m"
  },
  "ai_response": {
    "diagnosis": "从节点 IO 压力过大导致复制延迟，根因为大批量数据导入任务",
    "action": "暂停数据导入任务，复制延迟预计 30s 内恢复",
    "confidence": 0.92,
    "requires_approval": false,
    "knowledge_base_refs": ["KB-PG-001", "RUNBOOK-PG-LAG"]
  }
}

6. 值班与响应流程

6.1 值班制度（OPC 模式）

6.1.1 值班模式

┌─────────────────────────────────────────┐
│              AI 7×24 全天候监控           │
│  ┌─────────┐  ┌──────────┐  ┌────────┐ │
│  │ 指标监控 │  │ 日志分析  │  │ 异常检测│ │
│  └────┬────┘  └────┬─────┘  └───┬────┘ │
│       └────────────┼────────────┘       │
│                    ▼                     │
│         ┌──────────────────┐            │
│         │  AI Agent 诊断    │            │
│         └────────┬─────────┘            │
│                  ▼                      │
│    ┌─────────────┼──────────────┐       │
│    │ L1 自动处理  │ L2/L3 升级   │       │
│    └─────────────┘    ▼          │       │
│              ┌──────────────┐    │       │
│              │  人工值班响应  │    │       │
│              └──────────────┘    │       │
└─────────────────────────────────────────┘

6.1.2 值班排班

6.1.3 值班交接

• 每日 09:00 前完成交接
• 交接内容：昨日告警汇总、未解决事项、今日变更计划
• AI 自动生成值班日报

6.2 事故响应流程

6.2.1 五步事故响应

1. 发现（Detect）           2. 诊断（Diagnose）
┌──────────────┐            ┌──────────────────┐
│ 监控告警触发  │───────▶    │ AI 自动诊断        │
│ 用户反馈     │            │ • 指标分析        │
│ 定期巡检     │            │ • 日志分析        │
└──────────────┘            │ • 变更关联        │
                            │ • 历史对比        │
                            └────────┬─────────┘
                                     ▼
3. 止损（Mitigate）        4. 修复（Resolve）
┌──────────────────┐       ┌──────────────────┐
│ AI/人工执行止血    │       │ 根因修复          │
│ • 降级/限流       │◀──────│ • 代码修复        │
│ • 切换/回滚       │       │ • 配置修正        │
│ • 扩容            │       │ • 架构优化        │
└──────────────────┘       └────────┬─────────┘
                                     ▼
5. 复盘（Review）
┌──────────────────────────────────────────┐
│ 事故复盘会议（P0/P1 必须，P2 建议）        │
│ • 根因分析（5 Why）                       │
│ • 时间线梳理                              │
│ • 改进措施                                │
│ • 知识库更新                              │
└──────────────────────────────────────────┘

6.2.2 各阶段 SLA

6.2.3 升级机制

6.3 事故复盘模板

6.3.1 复盘文档结构

# 事故复盘报告

## 基本信息
- **事故编号**：INC-2025-001
- **事故等级**：P0
- **影响时间**：2025-01-15 14:30 ~ 15:45（75 分钟）
- **影响范围**：全部查价服务，影响约 2,000 家代理商
- **负责人**：张三
- **复盘日期**：2025-01-16

## 事故描述
（简要描述事故现象及用户影响）

## 时间线
| 时间 | 事件 |
|------|------|
| 14:30 | 监控告警触发：Redis P99 延迟 > 5s |
| 14:32 | AI Agent 诊断：Redis 大 Key 导致阻塞 |
| 14:35 | 值班人员认领，确认影响 |
| 14:40 | 执行手动清理大 Key |
| 14:45 | 服务逐步恢复 |
| 15:45 | 全部恢复正常 |

## 根因分析（5 Why）
1. Why 查价服务不可用？→ Redis 响应超时
2. Why Redis 超时？→ 存在超大 Key（800MB）
3. Why 存在超大 Key？→ 缓存预热逻辑未做分片
4. Why 未做分片？→ 代码 Review 未覆盖此场景
5. Why Review 未覆盖？→ 缺少大 Key 检测规范

## 影响评估
- 查价请求失败：约 45,000 次
- 订单损失：约 120 单
- 预估 GMV 损失：约 ¥180,000

## 修复措施
- [x] 紧急：手动清理大 Key
- [x] 修复：缓存预热增加分片逻辑
- [x] 部署：上线 v2.3.1 hotfix
- [ ] 长期：引入 Redis 大 Key 自动检测告警

## 预防措施
1. 增加 Redis 大 Key 监控告警（> 10MB）
2. 代码 Review Checklist 增加缓存设计规范
3. 压测场景增加异常数据构造

## 经验教训
- 缓存设计需要考虑数据量上限
- 监控需要覆盖中间件内部状态

6.3.2 自动沉淀机制

事故关闭 → AI 自动生成复盘草稿
  ├─ 提取告警时间线
  ├─ 关联变更记录
  ├─ 匹配相似历史事故
  ├─ 生成根因建议
  └─ 创建复盘文档 + 知识库条目

• P0/P1 事故 24h 内必须完成复盘
• P2 事故 1 周内完成复盘
• 复盘结论自动转化为改进项（Jira/飞书任务）
• 改进项纳入下一次迭代 Review

附录

A. Prometheus 关键配置

global:
  scrape_interval: 15s
  evaluation_interval: 15s

alerting:
  alertmanagers:
    - static_configs:
        - targets: ['alertmanager:9093']

rule_files:
  - /etc/prometheus/rules/*.yml

scrape_configs:
  - job_name: 'otel-collector'
    scrape_interval: 15s
    static_configs:
      - targets: ['otel-collector:8889']

  - job_name: 'node-exporter'
    static_configs:
      - targets: ['node-exporter:9100']

  - job_name: 'pg-exporter'
    static_configs:
      - targets: ['pg-exporter:9630']

  - job_name: 'redis-exporter'
    static_configs:
      - targets: ['redis-exporter:9121']

  - job_name: 'rabbitmq-exporter'
    static_configs:
      - targets: ['rabbitmq-exporter:9419']

B. Grafana 看板清单

C. Runbook 索引

D. 告警规则 YAML 示例

groups:
  - name: b2b-business-alerts
    rules:
      - alert: RateSuccessRateLow
        expr: |
          (
            sum(rate(b2b_rate_request_total{status="success"}[5m]))
            /
            sum(rate(b2b_rate_request_total[5m]))
          ) < 0.5
        for: 3m
        labels:
          severity: P1
          team: platform
        annotations:
          summary: "查价成功率低于 50%"
          description: "当前成功率: {{ $value | humanizePercentage }}"
          runbook: "https://wiki.internal/runbook/rate-success-low"
          dashboard: "https://grafana.internal/d/overview"

      - alert: CacheHitRateLow
        expr: |
          (
            sum(rate(b2b_cache_hit_total[5m]))
            /
            sum(rate(b2b_cache_request_total[5m]))
          ) < 0.3
        for: 1m
        labels:
          severity: P0
          team: platform
        annotations:
          summary: "缓存命中率低于 30%，疑似缓存雪崩"
          description: "当前命中率: {{ $value | humanizePercentage }}"
          runbook: "https://wiki.internal/runbook/cache-avalanche"

本文档随系统演进持续更新。如有疑问请联系基础架构组。