国庆值班应急排障看板建设核心业务 5 个金牌指标与一键定位 Root Cause 实操在很多技术团队的监控系统中往往存在一种非常恶劣的现象Grafana 上配置了几十个仪表盘、上百个图表密密麻麻全是折线图。一旦国庆长假期间线上发生故障报警值班工程师打开 Grafana 后需要在几十个看板中反复翻找看了半天 CPU、看了半天内存、又去查磁盘 I/O眼花缭乱却始终找不到问题到底出在哪白白浪费了宝贵的止血黄金 5 分钟。小厂的应急排障看板“多即是空少即是精”。在长假值班场景下我们只需要一个专用的“国庆应急值班大盘Emergency On-Call Dashboard”聚焦核心业务的5 个金牌黄金指标并在出现异常时提供一目了然的“根因排查定位路径Root Cause Decision Tree”。一、黄金指标体系RED 方法与 USE 方法的完美结合针对微服务与后端应用业内最经典的可观测性指标是 Google 的RED 方法Rate 吞吐量, Errors 错误率, Duration 响应延迟针对底层硬件基础设施则是 Brendan Gregg 的USE 方法Utilization 使用率, Saturation 饱和度, Errors 错误数。我们将二者提炼为长假值班必须盯紧的5 个金牌指标┌─────────────────────────────────────────────────────────┐ │ 国庆值班 5 个金牌指标大盘 │ └──────────────────────────┬──────────────────────────────┘ │ ┌─────────────┼─────────────┐ ▼ ▼ ▼ ┌──────────────────┐ ┌──────────────────┐ ┌──────────────────┐ │ 1. 全局业务吞吐量│ │ 2. 核心接口 5xx │ │ 3. P95 / P99 端 │ │ (Rate - QPS) │ │ 错误率 (Errors) │ │ 到端延迟 (Duration│ │ (实时流量是否跌零)│ │ (是否突破 1% 阈值)│ │ (是否发生慢调用) │ └──────────────────┘ └──────────────────┘ └──────────────────┘ │ │ └─────────────┬─────────────────────┘ │ ┌─────────────┴─────────────┐ ▼ ▼ ┌─────────────────────────┐ ┌─────────────────────────┐ │ 4. 依赖中间件饱和度 │ │ 5. Pod 异常重启与 OOM │ │ (Saturation - 连接池/MQ)│ │ (CrashLoopBackOff) │ │ (DB连接池/Redis/Kafka积压│ │ (协程泄漏/内存爆满信号) │ └─────────────────────────┘ └─────────────────────────┘二、生产级 Grafana 值班大盘 PromQL 配置清单以下是在生产环境中可直接导入使用的 5 大黄金图表 PromQL 表达式1. 全局业务 QPS 与同比环比排查流量突增或跌零# 核心交易网关当前总 QPS sum(rate(http_requests_total{jobapi-gateway}[1m]))2. 核心业务 HTTP 5xx 错误率判定业务受损面# 核心接口 5xx 错误率占比 sum(rate(http_requests_total{status~5.., jobapi-gateway}[1m])) / sum(rate(http_requests_total{jobapi-gateway}[1m]))3. P95 / P99 响应时间热力分布排查慢接口# P99 延迟分位数 histogram_quantile(0.99, sum(rate(http_request_duration_seconds_bucket[2m])) by (le, service))4. 数据库连接池与消息积压饱和度排查瓶颈中间件# MySQL 活跃连接数占最大连接数比例 (饱和度) mysql_global_status_threads_connected / mysql_global_variables_max_connections # Kafka 核心消费组积压量 (Lag) sum(kafka_consumergroup_lag{topicorder-topic}) by (consumergroup)5. Kubernetes Pod 异常重启计数排查 OOM 与 Panic# 过去 15 分钟内发生过重启的 Pod 列表 sum(increase(kube_pod_container_status_restarts_total[15m])) by (pod, namespace) 0三、一键定位 Root Cause 的 4 步排障决策树当值班手机收到报警时值班工程师只需打开应急大盘按照以下决策树在 2 分钟内完成根因归类[发现系统告警: 错误率上升 或 P99 延迟暴增] │ ▼ [检查指标 1: 流量 QPS 是否异常飙高 3 倍以上?] ├── 是 ──► [判定: 遭遇突发大流量或爬虫攻击] ──► 动作: 开启网关自适应限流与 IP 封禁 └── 否 ──► 继续检查下游 │ ▼ [检查指标 4: MySQL 活跃连接或 Kafka Lag 是否打满?] ├── 是 ──► [判定: 下游数据库慢查询或锁阻塞] ──► 动作: 查杀长事务 SQL开启读写分离 └── 否 ──► 继续检查计算层 │ ▼ [检查指标 5: 是否有 Pod 在频繁发生 Restart 重启?] ├── 是 ──► [判定: 发生 OOM 或空指针 Panic] ──► 动作: 查看 Pod 退出事件临时扩容内存 └── 否 ──► [判定: 上游公有云或第三方依赖抖动] ──► 动作: 一键开启本地旁路降级四、国庆值班的 3 项纪律准备值班手册存入手机离线备忘录包含数据库紧急查杀连接 SQL、一键降级 Curl 命令、云厂商售后电话。防止外出在无电脑环境时也能通过手机 SSH 终端执行应急操作。所有大盘配置全局时间变量$__rate_interval确保在缩放时间窗口从 15 分钟切到 6 小时时PromQL 不会发生计算点稀疏或语法错误。节前与全员同步一键回滚发布机制确保所有值班人员都清楚如何在 1 分钟内执行kubectl rollout undo deployment/xxx遇到疑难杂症“先回滚再排查”。