巡检指标设计：核心指标选取原则
指标设计这事儿，我踩过不少坑。刚开始做巡检的时候，恨不得把所有能监控的数据都抓过来，结果呢？告警风暴，谁也受不了。后来我总结出一个原则：少即是多，精准为王。
核心指标选取原则
我个人习惯，选指标先问三个问题：
- 这个指标能反映系统健康度吗？ 说白了，它是不是“体温计”？
- 指标异常了，我能快速定位吗？ 如果看到告警还得查半天，那这指标就没用。
- 指标之间有没有冗余？ 比如CPU使用率和CPU负载，其实看一个就够了。
嗯，这里要注意：不要追求“全”，要追求“准”。我见过有人把/proc/stat里几十个字段全拉出来，结果真正用到的就三五个。
核心原则总结：
- 可量化：指标必须能数值化，不能是“感觉系统有点慢”
- 可对比：要有基线值，比如“CPU使用率超过80%”才算异常
- 可行动：看到指标异常，你知道该干啥
CPU指标详解
CPU这块，我建议重点关注三个维度：使用率、负载、上下文切换。
CPU使用率
这个大家最熟悉。但我要提醒一句：别只看整体使用率。我曾经遇到一个案例，整体CPU才30%，但业务已经卡得不行了。为什么？因为有个进程在疯狂占用单核，其他核闲着。所以，我习惯同时看top里的%Cpu(s)和每个进程的CPU占用。
CPU负载（Load Average）
这个指标很多人理解有偏差。负载不是使用率，它表示的是正在运行+等待运行的进程数。我一般看1分钟、5分钟、15分钟三个值。如果1分钟远高于15分钟，说明负载在飙升，得赶紧查。
我的经验： 负载值超过CPU核心数的2倍，基本就要告警了。比如4核机器，负载超过8，系统响应就会明显变慢。
上下文切换
这个容易被忽略。上下文切换过高，说明CPU在频繁切换进程，真正干活的时间反而少了。我一般在vmstat里看cs列，如果持续超过10万次/秒，就得优化程序了。
内存指标详解
内存指标，我把它分成容量维度和性能维度。
容量维度
- 总内存 vs 已用内存：这个不用多说，但要注意
buff/cache。Linux会把空闲内存拿来当缓存，这其实是好事。我见过有人看到内存用了90%就报警，结果一看，60%都是缓存。 - Swap使用率：这个要重点盯。一旦开始用Swap，性能就会断崖式下跌。我建议Swap使用率超过10%就告警。
性能维度
- 缺页中断：特别是
major fault，说明内存不够，系统在频繁从磁盘换入换出。这个指标一高，基本就是内存瓶颈了。 - OOM Killer：这个不用多说，一旦触发，进程直接被干掉。我建议把
dmesg里的OOM日志也纳入巡检。
避坑指南： 我曾经遇到一个Java应用，堆内存设置过大，导致系统内存不足。结果OOM Killer把SSH进程给杀了，服务器直接失联。从那以后，我巡检必看oom_score_adj配置。
磁盘指标详解
磁盘指标，我关注空间、性能、健康度三个层面。
空间维度
- 磁盘使用率：超过80%就要关注，超过90%必须处理。为什么？因为很多日志系统在磁盘满时会直接挂掉。
- inode使用率：这个很多人忽略。小文件太多，inode用完了，磁盘还有空间也写不进去。我吃过这个亏，一个缓存目录生成了几百万个小文件，系统直接报
No space left on device。
性能维度
- IOPS和吞吐量：用
iostat看r/s和w/s。如果IOPS接近磁盘极限，性能就会下降。 - IO等待时间：
await值超过20ms，说明磁盘响应慢了。如果是SSD，超过5ms就得查。 - 队列长度：
avgqu-sz持续大于2，说明IO请求在排队，磁盘忙不过来了。
健康度维度
- SMART信息：重点关注
Reallocated_Sector_Ct和Pending_Sector。这两个值一旦非零，磁盘离报废就不远了。
网络指标详解
网络指标，我分成流量、连接、错误三类。
流量维度
- 带宽使用率：超过80%就要关注，特别是出口带宽。我遇到过业务高峰期带宽打满，结果数据库同步超时。
- PPS（每秒包数）：小包攻击时，带宽不高但PPS很高。我一般用
sar -n DEV看。
连接维度
- TCP连接数：特别是
TIME_WAIT和CLOSE_WAIT。TIME_WAIT太多，说明连接没复用；CLOSE_WAIT太多，说明程序没正确关闭连接。 - 连接失败率：用
netstat -s看failed connection attempts。这个值突然升高，可能是端口被占满或者防火墙拦截。
错误维度
- 丢包率：用
ping或者mtr看。超过1%就要查原因。 - 重传率：用
sar -n EDEV看。重传率高，说明网络质量差或者带宽不够。
业务指标与系统指标
这个我重点说说。很多运维只看系统指标，不看业务指标，这是不对的。系统指标是“因”，业务指标是“果”。
系统指标
就是上面说的CPU、内存、磁盘、网络。这些指标告诉你系统本身的状态。
业务指标
这些指标告诉你用户感受到的服务质量。比如：
- 请求延迟：P99延迟超过1秒，用户就会觉得卡
- 错误率：5xx错误超过1%，就得赶紧查
- 吞吐量：QPS/TPS，看系统能不能扛住当前流量
- 成功率：比如支付成功率、登录成功率
我的做法： 把业务指标和系统指标放在同一个看板上。比如，当P99延迟升高时，我同时看CPU使用率和磁盘IO。这样能快速判断：是系统瓶颈导致的，还是业务代码本身的问题。
如何关联两者？
举个例子：
- 业务指标：用户登录失败率突然升高
- 系统指标：CPU使用率正常，但磁盘IO等待时间飙升
- 结论：可能是数据库磁盘性能问题导致登录验证慢，超时失败
你看，只看业务指标，你只知道“出问题了”；结合系统指标，你才知道“哪里出问题了”。
知识体系结构图
下面这张图，是我自己梳理的巡检指标设计框架，你可以参考：
这张图的核心逻辑是：从原则出发，到四大指标，再到业务与系统结合。你照着这个框架去设计，基本不会漏。
最后说一句： 指标设计不是一劳永逸的。系统在变，业务在变，指标也要跟着调整。我每季度会复盘一次巡检指标，把没用的去掉，把新的加进来。保持精简，才能保持高效。