监控指标如何设置？

本文目录导读：

1. 第一步：明确监控的5个核心目标
2. 第二步：遵循“黄金信号”原则（技术监控）
3. 第三步：按监控层级分层设置
4. 第四步：指标设置的“4个不要”原则（避坑指南）
5. 第五步：一个实战示例：设置“用户登录”接口的监控
6. 设置监控指标的最佳实践路线图

监控指标的设置是一个系统性的工作，核心原则是“先明确目标，再定义指标”，不能为了监控而监控,而是要通过监控来回答关于系统状态和业务健康度的关键问题。

下面是一套从战略到战术的完整设置框架，适用于IT系统、业务运营或项目管理。

第一步：明确监控的5个核心目标

在设置指标前，先问自己：“我要通过监控避免什么？”

1. 故障发现与告警：最快速度知道系统挂了（如：服务器宕机、服务无响应）。
2. 性能瓶颈分析：定位系统慢在哪里（如：数据库查询慢、CPU负载高）。
3. 容量规划：预测未来是否需要扩容（如：磁盘使用率趋势、带宽增长）。
4. SLA/SLO保障：对外承诺的可用性是否达标（如：99.9%可用性）。
5. 业务洞察：技术指标对业务的影响（如：支付成功率下降是否由API延迟升高导致）。

第二步：遵循“黄金信号”原则（技术监控）

对于大部分技术系统，Google SRE 提出的 “四个黄金信号” 是最佳起点，这里做了一点扩展,形成五个核心维度：

延迟（Latency）- 响应时间

• 关键问题：请求处理需要多久？用户是否觉得慢？
• 常用指标：P50（中位数，反映一般体验）、P99（百分位数，反映最差的那1%用户的体验）、平均延迟、最大延迟。
• 设置技巧：不要只看平均值，必须看高百分位数,因为慢请求非常影响用户体验。
• 示例：API接口 P99 延迟 < 500ms。

流量（Traffic）- 请求量

• 关键问题：系统在承受多大压力？
• 常用指标：QPS（每秒查询数）、RPS（每秒请求数）、TPS（每秒事务数）、活跃用户数、带宽使用率。
• 设置技巧：与历史同期数据对比，识别流量异常激增或骤降，按时间段（如高峰/低谷）设置不同基线。

错误（Errors）- 错误率

• 关键问题：请求处理是否失败？产生了多少垃圾数据？
• 常用指标：
  • 显式错误：HTTP 5xx 状态码、业务返回的错误码、异常抛出次数。
  • 隐式错误：HTTP 200 但返回了错误数据（如返回空页面、返回“操作成功”但数据没写进去）。
• 设置技巧：错误率必须设置告警，对于关键业务，即使错误率是 0.1% 也要告警。

饱和度（Saturation）- 资源利用率

• 关键问题：系统还有多少余量？何时会崩？
• 常用指标：CPU使用率、内存使用率、磁盘I/O利用率、磁盘空间使用率、网络带宽饱和度、线程池/连接池占用率、队列长度（如：待处理的任务数）。
• 设置技巧：关注 “即将耗尽” 的临界点，例如磁盘使用率达到 80% 告警（提前扩容），而不是等到 99%。

可用性（Availability）- 正常运行时间

• 关键问题：服务是否正常提供服务？
• 常用指标：Uptime（在线时间）、健康检查通过率、探活失败次数。
• 设置技巧：结合 “断路器” 模式，当连续N次健康检查失败时，视为服务不可用,立即触发高级别告警。

第三步：按监控层级分层设置

不同层级关注不同的指标：

第四步：指标设置的“4个不要”原则（避坑指南）

1. 不要只设一个静态阈值：
   • 错误做法：CPU > 90% 告警。
   • 正确做法：动态基线告警，系统在高峰期CPU 80%是正常的，但如果是凌晨3点突然从10%飙到80%,这就是异常。
2. 不要指标过多（告警疲劳）：
   • 错误做法：监控所有1000个指标,对每个都设告警。
   • 正确做法：先覆盖核心黄金信号，非核心指标只做看板展示，不告警，告警数量控制在每天可处理的范围内（< 5个/人/天）。
3. 不要忽略“业务指标”：
   • 错误做法：只监控服务器健康,不管业务逻辑。
   • 正确做法：将技术指标与业务指标关联。支付成功率下降 -> 排查API超时或数据库锁。
4. 不要设“无法操作”的告警：
   • 错误做法：设置一个告警：“TCP连接数增加”。
   • 正确做法：告警信息要能指导行动。“应用程序数据库连接池已满 (100/100)，需重启或排查慢查询”，如果收到告警不知道怎么办,这个指标就是无效的。

第五步：一个实战示例：设置“用户登录”接口的监控

假设我们要监控一个 POST /api/login 接口：

1. 延迟（Latency）：
   • 指标名：login_api_p99_latency_ms
   • 阈值：P99 > 3000ms 告警（超过3秒用户会不耐烦）。
2. 流量（Traffic）：
   • 指标名：login_api_qps
   • 基线：正常100 QPS，如果突降到0 QPS（可能服务挂了），告警；如果突增到1000 QPS（可能被攻击）,告警。
3. 错误（Errors）：
   • 指标名：login_api_error_rate
   • 阈值：登录失败率（HTTP 5xx + 业务错误码“账号或密码错误”） > 5% 告警。
4. 饱和度（Saturation）：
   • 指标名：backend_pool_usage
   • 阈值：处理登录请求的线程池使用率 > 90% 告警。
5. 可用性（Availability）：
   • 指标名：login_api_availability
   • 阈值：连续3次健康检查失败，触发P0级告警（即最高级别告警）,通知值班人员。

设置监控指标的最佳实践路线图

1. 建看板：先用所有指标建一个仪表盘（Dashboard）,观察运行一周。
2. 抓关键：从中筛选出最能反映系统健康度的 5-10个核心指标。
3. 定阈值：先设保守的静态阈值（如 CPU 80%），然后利用工具学习历史数据生成动态基线。
4. 设告警：对核心指标设置告警，区分告警级别（如：P0=立即叫醒，P1=工作时间处理，P2=记录）。
5. 持续优化：每周/每月复盘，如果某个告警从未响应过，删除或降低级别，如果某个事故被漏掉了,补充对应指标。
6. 工具选择：
   • 开源：Prometheus (指标存储) + Grafana (可视化) + Alertmanager (告警管理),这是当前云原生的标准组合。
   • 商业：Datadog, New Relic, Dynatrace.
   • 云厂商自带：AWS CloudWatch, Azure Monitor, 阿里云云监控.

标签： 监控指标 设置方法