一、为什么主机监控永远是第一步？
在所有监控体系中，主机监控一定是地基。
不管你跑的是 Web 服务、数据库、微服务还是容器：
CPU 跑满了 → 服务一定慢
内存耗尽了 → 进程直接被 OOM Kill
磁盘满了 → 日志写不进去，服务直接崩
IO 异常 → 数据库、NFS 全部遭殃
👉所以，任何运维监控，第一件事永远是：先看主机。
二、CPU 监控：不只是“用没用满”
1️⃣ CPU 监控到底在看什么？
很多新手只看一个指标：
CPU 使用率 90% 了！
但在运维里，这远远不够。
CPU 监控，至少要关注三类信息：
使用率（Usage）
负载（Load Average）
上下文切换 / 等待时间
2️⃣ 常用 CPU 监控命令
🔹top / htop（最常用）
top重点关注：
%us：用户进程占用 CPU%sy：内核占用 CPU%id：空闲 CPU（越低压力越大）%wa：IO 等待时间（磁盘问题的重要信号）
💡经验判断：
us 高 → 应用本身压力大
wa 高 → 磁盘 IO 可能有问题
🔹uptime / load average
uptime输出示例：
load average: 2.15, 1.98, 1.76含义：
1 分钟 / 5 分钟 / 15 分钟平均负载
负载 ≠ 使用率
👉 判断是否正常：
Load ≤ CPU 核心数 → 正常
Load 长期 > CPU 核心数 → 有性能瓶颈
🧠小案例：CPU 监控在真实场景中的作用
场景： 用户反馈系统“偶尔很卡”。
排查思路：
top # 查看 CPU 使用情况 uptime # 查看系统负载发现：
CPU 使用率不高
但 Load Average 持续偏高
👉 结论： 不是算力不足，而是进程阻塞 / IO 等待问题。
三、内存监控：别等 OOM 才后悔
1️⃣ 内存监控重点看什么？
内存监控不是只看“还剩多少”。
真正要关注的是：
已用内存
可用内存（available）
Swap 使用情况
2️⃣ 常用内存监控命令
🔹free -h（最常用）
free -h重点看：
available：真正还能用的内存
swap used：是否开始使用交换分区
⚠️ 一旦开始大量使用 swap，性能一定下降
🔹vmstat（看趋势）
vmstat 1重点字段：
si / so：swap in / swap out长期不为 0 → 内存压力很大
🧠小案例：内存监控的真实意义
场景： 服务经常“莫名其妙挂掉”。
排查过程：
free -h dmesg | tail发现：
可用内存很低
日志中大量 Out of memory: Kill process
👉 结论：内存监控不到位，OOM 是必然结果。
四、磁盘监控：90% 才看？已经晚了
1️⃣ 磁盘监控要看哪几件事？
磁盘监控至少包括：
容量使用率
IO 性能
inode 使用情况
2️⃣ 常用磁盘监控命令
🔹df -h（看容量）
df -h经验值：
超过 70% → 开始关注
超过 85% → 必须处理
100% → 服务事故
🔹df -i（看 inode）
df -i很多小文件（日志、缓存） inode 用尽 = 磁盘“逻辑死亡”
🔹iostat（看 IO）
iostat -x 1重点字段：
%util：接近 100% → IO 瓶颈
await：IO 等待时间
🧠小案例：磁盘监控救命现场
场景： 业务突然无法登录，数据库报错。
排查发现：
df -h/var分区 100%。
👉 原因： 日志疯狂增长，磁盘写满。
👉 教训：磁盘监控 + 日志轮转 = 运维基本功。
五、主机监控的正确姿势
真正成熟的主机监控，应该做到：
✅ 持续采集（而不是出事才查）
✅ 有阈值告警（不是等人肉发现）
✅ 能回溯历史趋势
资源 | 必监指标 |
|---|---|
CPU | 使用率、负载、IO 等待 |
内存 | available、swap |
磁盘 | 使用率、IO、inode |
网络 | 流量、丢包、错误 |
六、写在最后：主机监控只是开始
主机监控解决的是一句话：
“机器还活着吗？还能撑得住吗？”
但下一步，你一定会遇到更现实的问题：
机器没问题，服务为什么 502？
CPU 正常，接口为什么慢？
主机在线，业务却不可用？
👉 这正是下一篇要讲的内容：
Linux 服务监控实战：端口、进程、接口怎么监控？
💬 互动话题
你第一次排查线上问题时， 最先敲下的监控命令是什么？
top
free
df -h
还是 uptime？
