常见运维监控指标 20 个你都掌握了吗？关键指标详解与实战应用

时间：2025-06-23

编辑：tance.cc

监控指标.png

“CPU 占用多少算高？”
“这条告警为什么一直在跳？”
“这个指标有什么用啊？我们是不是监控太多了？”

——如果你是一个网站或系统的运维人员，相信这些疑问并不陌生。你打开 Grafana、Zabbix、阿里云云监控，全是图表、数值、告警闪烁，却依旧对问题一头雾水。

问题的根本不是“缺监控”，而是你可能还不够理解指标的价值与边界。别担心，这篇文章我们不只告诉你“该监什么”，更告诉你“为什么这么监、怎么用、用错会怎样”。

不谈玄学，不整指标大词，我们来一波硬核讲解。

一、为什么监控指标不止是数字，而是“健康信号”？

监控不是为了收集数字，而是为了：

预测风险（看趋势）
提前发现（识别异常）
准确定位（查根因）
评估效果（看优化）

就像人去体检，医生不会只看体温。他要同时看血压、心率、血糖、肝功能，组合起来分析你到底哪出问题了。系统也是一样，一个“CPU 90%”到底该不该报警，要结合上下文判断。

所以我们今天讲的 20 个指标，每一个都会告诉你：

它代表什么
它为什么重要
怎么监
监控时的常见误区

准备好了？我们开干。

二、系统资源类指标（7项）

1. CPU 使用率（CPU Utilization）

含义：系统总 CPU 使用情况，通常以百分比表示。
重要性：高 CPU 使用率可能意味着服务压力大、死循环、垃圾回收过于频繁等。
建议阈值：单核 70%–85%，多核场景根据负载类型浮动。
误区：只看平均值，不关注“单核满载”。

2. 内存使用率（Memory Usage）

含义：进程、服务实际占用内存总量。
重要性：OOM（Out of Memory）崩溃的元凶之一。
建议监控项：

used memory
buffer/cached
swap in/out

误区：看到“内存占满了”就慌，Linux 本来就喜欢把内存都“用掉”。

3. Load Average（系统负载）

含义：系统等待 CPU 的平均进程数。
推荐指标：

1m, 5m, 15m 平均负载
核心数比对：负载 > 核心数 = 过载

误区：以为负载=CPU 使用率，它其实代表“拥堵情况”。

4. I/O 等待时间（iowait）

含义：CPU 等待 I/O 的时间百分比。
场景：磁盘过慢、数据库读写拥堵时飙高。
误区：CPU 空着不代表系统轻松，iowait 高也是“拥堵”。

5. 磁盘使用率（Disk Usage）

建议关注：

分区剩余空间（特别是 /, /var/log）
inode 使用情况

风险：磁盘满 = 服务无法写日志、缓存挂掉、应用崩溃。

6. 磁盘 IOPS（Disk IO Per Second）

含义：磁盘每秒读写次数。
意义：衡量磁盘压力，与数据库和日志相关性高。

7. 网络带宽与连接数（Network Bandwidth & Conn）

指标：

上下行带宽（bps）
当前连接数（netstat）
TCP Retransmits（重传率）

误区：只看带宽，不看 TCP 错误率和连接异常。

三、应用性能类指标（7项）

8. QPS（Queries Per Second）

含义：每秒处理的请求数量。
用途：衡量系统吞吐能力，是压测重要参考。
注意：QPS 高不等于好，还得看响应时长。

9. 响应时间（Latency）

推荐区间：P50、P95、P99
用途：查看大部分请求耗时，也能判断系统“尾部性能”是否拖后腿。

10. 错误率（Error Rate）

如何衡量：

4xx、5xx 比例
自定义错误码

重点：突然上升的错误率通常是服务故障信号。

11. 超时率（Timeout Rate）

场景：微服务之间依赖断裂、接口挂死。
建议：监控上游请求的“重试+超时”，不是越多越好。

12. 应用重启次数（Restart Count）

用途：Kubernetes 中容器频繁重启，表示健康状态差。
误区：别忘了监控重启频率，而不是单一次数。

13. GC 次数与时间（垃圾回收）

指标来源：JVM / Go / Node 等语言运行时。
风险：Full GC 时间过长会卡顿整个服务。

14. 请求排队时间（Queue Time）

意义：如果请求排队太久，说明并发处理能力不足。

四、服务可用性与健康类（6项）

15. 服务健康检查（Health Check）

指标类型：

HTTP 200 / 非200 返回
响应时长

告警建议：连续3次失败触发问题。

16. 服务注册状态（Service Registry）

例如：Eureka、Consul、K8s Service。
状态变化：UP → OUT_OF_SERVICE，务必监控。

17. 数据库连接池使用率

过高：可能连接泄露或查询阻塞；
过低：说明连接设置过多，资源浪费。

18. 消息队列堆积量（MQ Backlog）

系统：Kafka / RabbitMQ / RocketMQ
建议监控项：

当前待消费条数
消费延迟（Lag）
消息堆积趋势

19. 缓存命中率（Cache Hit Ratio）

场景：Redis / Memcached
命中率低：说明缓存策略出问题或没生效。

20. 证书/配置过期（Expiry Monitoring）

常被忽略！

SSL证书有效期
Kubernetes Secret 配置过期
API Token 更新失效

一场证书到期引发的“全站502”，足以写成一次事故复盘了。

五、常见组合策略与实战建议

别光收集，还要“组合使用”。推荐几个实战组合：

应用服务三件套

QPS + 错误率 + 响应时间
→ 判断请求是否高峰 + 服务是否健康 + 体验是否变差

系统资源三板斧

CPU + 内存 + 磁盘
→ 资源层面可用性与瓶颈判断

爆发故障排查路径

是否重启？（Restart）
错误率上升？（5xx）
响应时长拉长？（Latency）
后台日志是否异常？
DB / MQ / 缓存有无压力？
网络或配置变更？

六、如何避免“监控疲劳”和无效告警？

有些团队监控一上来就配置几十上百条指标，结果呢？

告警成了“背景音乐”
图表复杂没人看
误报频发导致真故障反而没引起注意

所以监控要有策略：

类别	作用	告警方式
核心服务	稳定性关键指标	实时 + 严格
辅助指标	性能优化判断	周报 / 仪表盘
异常分析	根因定位线索	事件驱动分析

监控本质不是数据堆砌，是“视角提炼”。

尾声：你会看的指标，才是有价值的指标

20 个指标讲完了，看到这里你也许会问：
“我真的要监控这20个吗？我用得上吗？”

答案是——

与其监一堆你看不懂的数据，不如搞懂几个你能用的关键指标。

监控的目标不是“数据齐全”，而是“用得上、用得好”。

真正的高手不是画最多图的人，而是能从图里读出问题的人。

资讯与帮助