第一章：监控指标体系——这些指标到底在监控什么？
大家好，我是老张。做运维这么多年，我见过太多团队一上来就铺几百个监控项，结果告警风暴一来，谁都不知道该先看哪个。说白了，监控不是堆数量，而是抓重点。
今天咱们就聊聊最常见的六个指标：CPU、内存、磁盘IO、网络带宽、进程存活、日志关键字。每个指标我都会结合实战经验，告诉你它到底在反映什么问题。
1.1 CPU使用率：不只是看百分比
CPU使用率，大家都会看。但你真的看懂了吗？
我习惯把CPU使用率拆成三部分看：
- 用户态（user）：应用程序在跑，比如你的Java进程、Nginx
- 系统态（sys）：内核在干活，比如系统调用、中断处理
- 等待IO（iowait）：CPU在等磁盘或网络，说白了就是闲得慌
重点来了：如果iowait超过20%，别急着加CPU，先查磁盘。我曾经遇到一个案例，某数据库服务器CPU飙到90%，团队加了两倍核数都没用。后来发现是磁盘IO瓶颈，换SSD后CPU直接降到30%。
监控CPU时，我建议至少设置两个阈值：
| 级别 | 阈值 | 建议动作 |
|---|---|---|
| 警告 | 持续5分钟 > 80% | 检查是否有异常进程 |
| 严重 | 持续5分钟 > 95% | 立即介入，可能影响业务 |
小技巧：用top命令看CPU时，按1键可以看每个核心的负载。如果某个核心跑满，其他核心空闲，说明程序有单线程瓶颈。
1.2 内存使用率：别被“已用”骗了
内存监控有个常见的坑——Linux的内存管理机制。你执行free -h，看到“已用”90%，别慌。
Linux会把空闲内存拿来当缓存（cache）和缓冲区（buffer）。这部分内存其实可以被应用程序随时回收。所以真正要关注的是：
- 实际可用内存 = 空闲 + 缓存 + 缓冲区
- 交换分区使用量（swap）：如果swap开始涨，说明物理内存真的不够了
我曾经踩过的坑：某次线上告警说内存使用率98%，我一看swap用了2GB。结果发现是Java进程的堆内存设置过大，导致频繁GC。调小堆内存后，swap直接归零。记住：swap使用量比内存百分比更敏感。
内存监控的推荐规则：
# 实际内存使用率 = (总内存 - 可用内存) / 总内存 * 100%
# 可用内存 = free + buffers + cached
# 告警阈值建议：
# 警告：实际使用率 > 80% 或 swap使用 > 10%
# 严重：实际使用率 > 90% 或 swap使用 > 30%1.3 磁盘IO：最容易忽略的瓶颈
磁盘IO，说白了就是硬盘的读写速度。CPU和内存再快，磁盘跟不上也是白搭。
我主要看三个指标：
- IOPS：每秒读写次数。数据库、消息队列这类应用很敏感
- 吞吐量：每秒读写的数据量。视频、日志这类大文件传输更关注
- IO等待时间（await）：每次IO操作的平均耗时。超过10ms就要警惕了
实战经验：有一次MySQL主库突然变慢，CPU和内存都正常。我一看磁盘await飙到50ms，原来是同机柜的另一个业务在做全量数据导出，把磁盘带宽占满了。后来我们给核心数据库单独挂了块SSD，问题解决。
磁盘IO的监控命令：
# 用iostat看磁盘IO
iostat -x 1 5
# 重点关注：
# %util - 磁盘利用率，超过80%说明接近饱和
# await - 平均IO等待时间，超过20ms需要优化
# r/s, w/s - 每秒读写次数，对比磁盘规格1.4 网络带宽：流量异常比带宽不足更可怕
网络带宽监控，很多人只盯着“用了多少”。其实我更关心流量是否异常。
举个例子：某天凌晨3点，带宽突然从100Mbps飙到800Mbps。你猜是业务高峰？还是被攻击了？
我习惯这样看：
- 入流量 vs 出流量：如果入流量远大于出流量，可能是下载或攻击
- 连接数：特别是TIME_WAIT状态的连接数，过多说明连接池配置有问题
- 丢包率：超过0.1%就要查原因了
我的习惯：给网络带宽设置两个维度的告警。一是利用率超过80%告警，二是流量突增超过历史均值300%告警。后者往往能提前发现DDoS攻击或爬虫异常。
1.5 进程存活：最简单的指标，最容易被忽视
进程存活监控，说白了就是看进程在不在。但这里有个细节：进程在，不代表它在正常工作。
我遇到过的情况：Nginx进程还在，但已经无法响应请求了。为什么？因为进程死锁了，或者端口被占用了。
所以我的建议是：
- 不光监控进程是否存在，还要监控端口是否监听
- 最好加一个简单的健康检查，比如请求一个接口看返回码
# 进程存活监控脚本示例
#!/bin/bash
# 检查nginx进程和端口
if ! pgrep -x nginx &>/dev/null; then
echo "Nginx进程不存在"
exit 1
fi
if ! ss -tlnp | grep -q ':80'; then
echo "Nginx端口80未监听"
exit 1
fi
# 健康检查
if ! curl -s -o /dev/null -w "%{http_code}" http://localhost/health | grep -q 200; then
echo "Nginx健康检查失败"
exit 1
fi
echo "Nginx运行正常"1.6 日志关键字：从被动救火到主动发现
日志监控，是运维的终极武器。但很多人把它用成了“事后诸葛亮”。
我建议这样配置：
- ERROR级别日志：立即告警，但要注意过滤已知的、不影响业务的错误
- WARN级别日志：聚合统计，比如5分钟内出现100次以上才告警
- 特定关键字：比如“OOM”、“Connection refused”、“Timeout”
我曾经犯过的错：刚开始做日志监控时，我把所有ERROR都设成告警。结果一天收到2000条告警，全是业务正常报错。后来我加了过滤规则和聚合策略，告警量降到每天20条，每条都有价值。
日志监控的配置示例：
# 使用Promtail + Loki的日志告警规则
- name: error_log_alerts
rules:
- alert: HighErrorRate
expr: |
rate({app="myapp"} |= "ERROR" [5m]) > 10
for: 2m
annotations:
summary: "应用错误率过高，5分钟内超过10次"知识体系总览
下面这张图，是我自己总结的监控指标体系。你可以把它当成一个检查清单：
嗯，这六个指标，基本上覆盖了90%的日常监控场景。你想想看，服务器无非就是CPU算、内存存、磁盘读写、网络传输、进程跑、日志记。把这六个点盯住了，大部分问题都能提前发现。
我个人习惯是：先配CPU和内存的告警，再逐步加上磁盘IO和网络。进程存活和日志关键字，建议从第一天就配上，因为这两个指标能帮你发现很多“看不见”的问题。