MONITORING · 指标体系 / 告警治理
监控告警速查
从 RED / USE / 黄金四指标的选型方法论，到 Prometheus 指标类型与 PromQL、告警分级路由，再到 Grafana 看板、日志链路与 SLO 治理，监控告警方向的 39 条高频要点一张表收齐，随查随用。
39条速查
6大主题
∞持续更新
📖 速查表
点击展开各小节
📊 指标方法论
| 方法论 | 核心维度 | 适用场景 |
|---|---|---|
| RED 方法 | Rate 请求速率、Errors 错误率、Duration 耗时分布，三个指标刻画一个服务的外在健康面 | 在线服务（Web / RPC / API）首选 面向服务 |
| USE 方法 | Utilization 使用率、Saturation 饱和度、Errors 错误数，从资源视角回答「忙不忙、撑不撑得住、坏没坏」 | 基础设施资源（CPU / 内存 / 磁盘 / 网络）面向资源 |
| 谷歌黄金四指标 | 延迟、流量、错误、饱和度，直接对应用户可感知的服务质量，是 SLO 目标的天然来源 | 整体服务质量度量与 SLO 制定 面向用户 |
| 组合用法 | 服务层用 RED、资源层用 USE、全局用黄金四指标，三层拼出完整指标体系，避免「只有 CPU 曲线」式监控 | 自上而下补齐三层 |
🌡️ Prometheus 核心
| 类型 / 函数 / Exporter | 说明 | 示例 / 要点 |
|---|---|---|
| Counter 计数器 | 只增不减的累计值，适合请求数、错误数、任务完成数；直接看原始值无意义，必须算速率 | rate(http_requests_total[5m]) 配 rate 使用 |
| Gauge 仪表盘 | 可增可减的瞬时值，适合内存占用、并发连接数、队列长度、温度等「当前水位」 | jvm_memory_used_bytes |
| Histogram 直方图 | 服务端分桶统计样本分布，可跨实例聚合后再算分位数，是请求耗时统计的首选 | http_request_duration_seconds_bucket |
| Summary 摘要 | 客户端预计算好分位数直接输出，无法把多实例聚合到一起算全局 P99 | 分布式场景优先 Histogram 可聚合优先 |
| rate() | 取区间内的平均增长率，自动处理计数器重置（进程重启），平滑适合做告警判断 | rate(errors_total[5m]) > 0 告警常用 |
| irate() | 只用区间内最后两个样本算瞬时速率，反应灵敏但毛刺多，适合看板观察突变 | irate(http_requests_total[5m]) 看板用 irate，告警用 rate |
| histogram_quantile() | 从直方图 bucket 计算分位数，P99 延迟告警与看板的标准写法 | histogram_quantile(0.99, sum by (le) (rate(d_bucket[5m]))) |
| node-exporter | 主机层指标采集：CPU、内存、磁盘、网络、文件系统，每台机器部署一个实例 | 配 USE 方法看资源三件套 主机标配 |
| mysqld / redis-exporter | 中间件指标：连接数、QPS、慢查询、主从延迟、缓存命中率等，暴露给 Prometheus 抓取 | 连接池打满、慢查询突增告警的主数据源 |
| blackbox-exporter | 黑盒拨测：从外部发起 HTTP / TCP / ICMP / DNS 探测，监控端到端可用性与证书有效期 | 证书 30 天 过期预警 站在用户视角 |
🚨 告警规则与路由
| 主题 / 级别 | 说明 | 要点 |
|---|---|---|
| 规则书写要点 | 指标语义明确、阈值基于容量评估而非拍脑袋、必须带 for 防抖、标签标注 severity 与 team 便于路由 | 一条规则只回答一个问题 可行动性优先 |
| for 持续时间 | 条件持续满足一段时间才触发，过滤瞬时抖动；一般取 1~5 分钟，按业务容忍度调整 | for: 3m 防毛刺误报 |
| P0 致命 | 核心功能完全不可用、数据丢失、资金损失，影响面大且扩散中 | 5 分钟内响应，电话 / 短信唤醒 7×24 |
| P1 严重 | 核心功能部分受损或降级运行，用户可感知但还有绕过手段 | 15 分钟内响应，IM 群 + 电话 |
| P2 一般 | 非核心功能异常、指标越过水位线但服务仍正常 | 工作时间 IM 处理，当日闭环 |
| P3 提醒 | 预警类：容量趋势、证书临期、版本陈旧，不紧急但放着会变成事故 | 日报 / 周会跟进排期 隐患清零 |
| Alertmanager 路由 | 按 severity、team 等标签把告警树状分发到不同接收器：邮件、IM 群机器人、电话平台 | route → matchers → receiver 按标签分发 |
| 抑制与静默 | 抑制：高级别告警存在时压掉同批低级别（宕机压掉一切衍生告警）；静默：发布窗口临时屏蔽指定标签的告警 | inhibit_rules / silence 降噪两大件 |
groups:
- name: http-alerts
rules:
- alert: HighErrorRate
expr: rate(http_requests_total{status=~"5.."}[5m]) / rate(http_requests_total[5m]) > 0.01
for: 3m
labels: { severity: P1, team: backend }
annotations:
summary: "5xx 错误率超过 1%，已持续 3 分钟"
📈 Grafana 看板
| 主题 | 说明 | 要点 |
|---|---|---|
| Time series 时序面板 | 最常用的趋势面板：请求速率、错误率、延迟分位数随时间的变化曲线，看拐点与突变最直观 | 配 rate() 与分位数函数 默认首选 |
| Heatmap / 表格 / 仪表 | 热力图看耗时分布随时间的变化；表格看 TopN 排行（最慢接口、最多错误实例）；仪表看单一水位（磁盘使用率） | 分布用热力、排行用表格 按数据形态选型 |
| 变量与看板复用 | 用 $env、$service 等模板变量做成一套看板，切换下拉框即可在不同环境 / 服务间复用 | 一套看板多环境 |
| 看板组织 | 总览层（全局健康水位）→ 服务层（RED 三指标）→ 实例层（单机明细），逐层下钻定位 | 总览 → 服务 → 实例 |
| 看板纪律 | 一张看板回答一个核心问题；大屏只放核心水位与 SLO 达成率，装饰性图表一律不放 | 少即是多 信息密度优先 |
📜 日志与链路
| 组件 / 概念 | 说明 | 要点 |
|---|---|---|
| ELK 组件分工 | Elasticsearch 负责存储与全文检索，Logstash 负责采集与解析，Kibana 负责查询与可视化 | 功能全但资源开销大 全家桶 |
| EFK 轻量采集 | 用 Filebeat / Fluentd 替代 Logstash 做采集端，资源占用更低，Kubernetes 场景多以 DaemonSet 方式部署 | 采集轻量化 K8s 标配 |
| Loki 一句话定位 | 只对标签建索引、不对正文建全文索引的轻量日志系统，与 Grafana 原生集成，存储成本远低于 ES | 先按标签过滤再看原文 省成本 |
| Trace 分布式链路 | OpenTelemetry / SkyWalking 记录一次请求跨服务的完整调用路径与各段耗时，一眼定位慢在哪一环 | 微服务排障的地图 跨服务定位 |
| TraceId 贯通三支柱 | 日志、指标、链路统一携带 TraceId：从告警指标下钻到链路，再一键跳到相关日志，三支柱串成一条线 | 可观测性三支柱 |
🎯 SLO 与告警治理
| 概念 / 实践 | 说明 | 要点 |
|---|---|---|
| SLI 指标 | 服务质量的测量口径：如请求成功率、P99 延迟、数据新鲜度，从用户视角选取 | 先定口径再定目标 |
| SLO 目标 | 对 SLI 设定的内部目标值，如「成功率 ≥ 99.9%」「P99 < 300ms」，决定研发与运维的优先级 | 留有余量、可达成 内部承诺 |
| SLA 协议 | 对外的合同条款，含违约赔偿，是法律承诺；SLO 要比 SLA 收得更紧才守得住 | SLA < SLO 留缓冲 |
| 错误预算 | 1 - SLO 目标的可失败余量：99.9% 即每月约 43 分钟；预算烧完就冻结功能发布、优先修稳定性 | 烧完即冻结发布 |
| 误报治理 · 合并 | 同一根因引发的多条告警聚合为一条事件，按事件响应而非逐条轰炸，降低告警疲劳 | 收敛后再通知 聚合降噪 |
| 误报治理 · 根因消除 | 同一条告警反复触发说明阈值或基线错了：重评容量、改用分位数或同环比，而不是简单调灵敏度 | 治标更治本 基线重估 |
| 值班 Oncall 要点 | 交接记录未闭环问题与风险点；每个 P0 / P1 告警配 Runbook（现象 → 定位 → 处置 → 升级路径），值班照单执行 | 交接 + Runbook |