全栈攻城狮

Appearance

实时监控与告警 ​

概述 ​

游戏服务必须"眼睛常亮"：QPS、RT、在线数、GC、CPU、内存、连接数，任何指标异常都要第一时间知道。Prometheus + Grafana 是标准组合：Prometheus 采集指标，Grafana 画面板 + 告警，告警推送到钉钉/企微。本文讲清楚指标体系、面板设计与告警规则。

一、监控指标体系 ​

1.1 指标分层 ​

指标分层：
  基础设施：CPU、内存、磁盘、网络、GC
  中间件：MySQL、Redis、MQ（连接数、延迟、队列深度）
  应用：QPS、RT、在线数、房间数、错误率
  业务：充值金额、活跃、留存、功能使用率

游戏特有指标：
  在线人数（峰值/分布）
  房间数（进行中/等待）
  匹配队列长度/等待时间
  登录成功率/登录耗时
  关键玩法参与率
// 指标采集（Micrometer + Prometheus）
@Timed(name = "game.match.queue", ...)
public MatchResult match(...) {...}

// 或埋点
Counter loginCounter = meter.counter("game.login.total");
loginCounter.increment();

1.2 采集架构 ​

Prometheus 架构：
  服务暴露 /metrics 端点（Micrometer）
  Prometheus 定时抓取（scrape）
  指标存储（时序库）
  Grafana 查询展示 + 告警

游戏服务对接：
  Spring Boot + Micrometer（自动暴露）
  JVM 指标（内存/GC/线程）
  Netty/自定义指标（连接数、队列长度）
# Prometheus 抓取配置
scrape_configs:
  - job_name: game-logic
    metrics_path: /actuator/prometheus
    static_configs:
      - targets: ["game-logic-1:8080", "game-logic-2:8080"]

二、Grafana 监控面板 ​

2.1 面板设计 ​

核心面板：
  总览：在线数、QPS、RT 曲线、错误率
  资源：CPU/内存/GC（按节点聚合）
  连接：连接数、断线率、重连数
  对局：房间数、对局时长、匹配等待
  业务：充值金额、活跃玩家、关键玩法

布局原则：
  红色系 = 严重指标（错误/超时）
  绿色系 = 正常指标
  趋势图 + 阈值线
// 面板查询示例（PromQL）
// 在线人数（Gauge 实时值）
sum(game_online_total)

// QPS（Counter 求速率）
sum(rate(game_request_total[1m]))

// RT P95（Histogram）
histogram_quantile(0.95, 
  sum(rate(game_request_ms_bucket[1m])) by (le))

// GC 暂停
sum(rate(jvm_gc_pause_seconds_sum[5m]))

2.2 指标口径 ​

关键口径：
  QPS：按类型细分（登录/对战/聊天）
  RT：p50/p95/p99 分位（看长尾）
  在线：实时 + 日峰值 + 分服
  连接：总连接、节点分布、空闲比例

告警阈值设定：
  基于压测数据（见压测章节）
  留余量（压测上限 × 0.7 告警）
  分级阈值（WARN 预警 / CRITICAL 故障）

三、自定义告警规则 ​

3.1 告警规则定义 ​

Prometheus 告警（Alertmanager）：
  规则：指标表达式 + 阈值 + 持续时间
  分组/去重：同类型合并
  路由：按严重级别发不同渠道

示例规则：
  WARN：CPU > 80% 持续 5min
  CRITICAL：在线数掉到 0（服务全挂）
  WARN：RT p95 > 200ms 持续 5min
  CRITICAL：充值失败率 > 5%
# Prometheus 告警规则
groups:
  - name: game.rules
    rules:
      - alert: GameLogicDown
        expr: up{job="game-logic"} == 0
        for: 1m
        labels: { severity: critical }
      - alert: HighRT
        expr: histogram_quantile(0.95,
          sum(rate(game_request_ms_bucket[5m])) by (le)) > 200
        for: 5m
        labels: { severity: warning }

3.2 Alertmanager 路由 ​

Alertmanager 配置：
  group_by：按告警名/服务分组
  路由：severity=critical → 电话/短信；warning → 群通知
  抑制：父级故障抑制子级（服务挂了不发内部指标告警）
  静默：维护窗口静默

通知渠道：
  钉钉 Webhook / 企微 Webhook / 邮件 / 短信
  告警内容：名称、级别、指标值、时间、节点、链接
# Alertmanager 路由
route:
  group_by: ['alertname']
  routes:
    - match: { severity: critical }
      receiver: phone-team
    - match: { severity: warning }
      receiver: dingtalk-group

四、钉钉/企微通知 ​

4.1 Webhook 接入 ​

钉钉机器人：
  群 → 智能群助手 → 添加机器人
  获取 Webhook URL + 加签密钥
  Alertmanager webhook receiver 配置

// 钉钉消息（Markdown）
{
  "msgtype": "markdown",
  "markdown": {
    "title": "游戏服务告警",
    "text": "### 高 RT 告警\n> 节点: game-logic-1\n> P95: 350ms\n> 持续: 5 分钟"
  }
}
// Alertmanager webhook 配置
receivers:
  - name: dingtalk-group
    webhook_configs:
      - url: "https://oapi.dingtalk.com/robot/send?access_token=xxx"

4.2 告警闭环 ​

告警闭环流程：
  告警触发 → 通知值班 → 处理 → 恢复通知 → 复盘
  关键：告警必须有人认领处理
  复盘：根因分析 → 改进 → 规则优化

告警质量检查：
  是否误报（阈值调整）
  是否漏报（规则补充）
  是否有效（处理了多少真问题）

五、实现要点 ​

监控告警核心：
  指标分层（基础设施/中间件/应用/业务）
  Prometheus 采集 + Grafana 面板
  自定义告警（阈值 + 持续时间 + 分级）
  Alertmanager 路由 + 钉钉/企微通知
  告警闭环（处理 + 恢复 + 复盘）

常见坑：
  指标不全 → 出事没数据
  告警风暴 → 失去价值（去重/分级）
  阈值拍脑袋 → 依据压测数据
  只告警不闭环 → 问题反复

与其他系统衔接：
  压测数据 → 阈值设定依据
  日志告警 → 日志收集章节
  全链路 → 链路追踪章节
  发布对比 → 灰度发布章节