监控系统基础：常用监控指标
搞监控这么多年，我见过太多团队一上来就铺几百个指标，结果告警轰炸，谁都睡不着觉。其实核心就四个维度：CPU、内存、磁盘、网络。这四样抓准了，系统大半的根因你都能摸到。
嗯，咱们一个一个来拆。
CPU 指标
CPU 是系统的算力出口，你想想看，它要是跑满了，所有进程都得排队。我个人习惯先看这五个关键指标：
| 指标名称 | 含义 | 典型阈值 |
|---|---|---|
| user | 用户态 CPU 使用率（应用代码） | < 70% |
| system | 内核态 CPU 使用率（系统调用） | < 30% |
| iowait | CPU 等待磁盘 I/O 完成的时间占比 | < 10% |
| steal | 虚拟化环境下被宿主机"偷"走的 CPU | < 5% |
| load average | CPU 运行队列长度（1/5/15 分钟均值） | ≤ 核心数 × 0.7 |
我曾经踩过一个坑：只看 CPU 总使用率，结果 iowait 飙到 40%，应用卡成狗，指标却显示 CPU 只有 60%。后来我把 iowait 单独拎出来告警才抓到真凶——磁盘阵列里的坏道。
排查小技巧：用 top 看 %CPU 列，按 1 看每个核的分布；再用 vmstat 1 看 procs 列的 r 和 b，r 是正在跑的线程数，b 是卡在 I/O 上的线程。如果 b > 0 持续 10 秒，基本可以判定 I/O 瓶颈。
内存指标
内存这玩意儿，一不够就 OOM killer 乱杀进程，令人头大。但别只看 used/total 百分比，那会骗人——Linux 会把空闲内存当缓存用，实际可回收。我推荐盯住：
- available：真正可用的内存（不含不可回收的缓存），这是最靠谱的。
- swap used：如果交换分区被用了超过 10%，物理内存很可能不够了。
- cached + buffers：文件系统缓存，正常情况应该占不少。
- 内存泄漏特征：进程 RSS 持续增长，不会回落。
| 场景 | 我常用的阈值 | 告警级别 |
|---|---|---|
| available 小于总内存 20% | Warning | 通知 |
| available 小于总内存 10% | Critical | 立即响应 |
| swap used 超过 5% 且持续增长 | Warning | 排查是否有泄漏 |
| 单进程 RSS 超过预留内存的 150% | Critical | 检查日志、dump |
# 一条命令看内存全景（RHEL/CentOS）
$ free -h
total used free shared buff/cache available
Mem: 31Gi 12Gi 4.2Gi 1.3Gi 15Gi 17Gi
Swap: 4.0Gi 0.3Gi 3.7Gi
# 注意 available 那一列，它才是系统觉得“能给你用的内存”
磁盘指标
磁盘监控最容易被忽略，可它一出问题，数据库直接卡死。我建议按“容量 + 性能 + 健康”三个维度设看板：
容量维度
- 使用率（used%）：常规设 80% Warning，90% Critical。
- inode 使用率：很多小文件场景（比如容器日志），容量没满但 inode 爆了。我还记得某次排查写文件失败，df 显示还有 200GB，结果
df -i一看 inode 用完了……
性能维度
- await：平均每次 I/O 响应时间（毫秒）。普通 HDD 建议 < 20ms，SSD < 5ms。
- svctm：平均服务时间，接近 await 说明队列深度正常，差太远说明有排队等待。
- %util：磁盘忙碌百分比。注意了，如果磁盘是多队列 SSD，%util 可能超过 100% 还正常——别被吓到，关键看 await。
我的经验法则：磁盘告警优先级是 I/O 延迟 > 使用率 > inode。业务卡的时候，往往是 await 先飙升，然后使用率才慢慢跟上。
网络指标
网络监控比前三种更“玄”，丢一个包、延迟波动一下，整个分布式集群都可能雪崩。你需要分清应用视角和设备视角：
| 指标 | 含义 | 说明 |
|---|---|---|
| 带宽使用率 | 当前流量 / 链路带宽 × 100% | 一般超 80% 丢包概率上升 |
| 丢包率 | 重传报文 / 总报文 | TCP 重传率 > 2% 就要警惕 |
| TCP 连接状态 | ESTABLISHED / TIME_WAIT / CLOSE_WAIT | CLOSE_WAIT 堆积 = 代码没关 socket |
| 延迟 RTT | 往返时延 | 同机房 < 1ms，跨可用区 < 5ms |
| 错误包（errors / dropped） | 网卡硬件/驱动层的丢包 | 一旦出现基本可以换网卡或查链路 |
# 用 ss 看 TCP 连接状态分布
$ ss -s
Total: 1234 (kernel 0)
TCP: 678 (estab 412, closed 200, orphaned 0, synrecv 0, timewait 66/0), ports 0
Transport Total IP IPv6
* 0 - -
RAW 0 0 0
UDP 12 12 0
TCP 678 452 226
INET 690 464 226
FRAG 0 0 0
# 如果 timewait 持续飙升且导致端口耗尽，用 net.ipv4.tcp_tw_reuse / tcp_fin_timeout 调优
我曾经遇过：某微服务网关机的网卡 dropped 字段每小时涨几百，业务反馈偶发超时。查驱动版本、换光纤模块，最后发现是机房网线头接触不良。
四大指标的关系图
下面这张图总结了四个维度以及它们之间的关联——CPU 等 I/O 时卡在 iowait，内存不足触发 swap 又会拖慢磁盘，磁盘 I/O 高反过来增加 CPU 的 iowait……这些循环你值得记心里：
如何组合使用这些指标？
单独看一个指标很容易误判。举个例子：CPU 100% + 内存 available 充足 + 磁盘 await 正常，这大概率是应用层计算密集，直接压应用代码就行。但如果是CPU 70% + 内存 available 骤降 + 磁盘 await 飙到 50ms，那就是内存泄漏导致大量交换，磁盘成为瓶颈——这时候优化代码释放内存才是正解，加 CPU 没用。
我个人习惯建一个综合评分：四个维度各取一个代表性指标，设置红黄绿。一旦超过 2 个进入黄色或 1 个进入红色，就触发告警。这样能避免半夜被某台机器的 IOPS 微波动吵醒。
避坑指南：我曾经看到有些团队给磁盘的 %util 设 90% 告警，结果 SSD 多队列下 90% 根本不算事。后来我改成 await > 10ms 告警，安静多了。同样的，swap 使用不要只设百分比，如果机器只有 2GB 内存，swap 占 5% 不过 100MB，根本不用管；但如果是 64GB 内存，swap 占 5% 就 3.2GB 了，需要关注。所以阈值要根据机器规格动态调整，死数字会坑死人。
这四个指标看完，你已经能覆盖 90% 的日常巡检了。每次新上线一个服务，我都会先用上述指标跑一周基线——看看常态值是多少，再设告警。记住：不了解常态的告警就是噪音。