这是《Linux 零基础实战指南》的独立章节版。本章从概念、实操和生产排查三个视角展开,代码块保留了原书可直接运行的版本。 监控的目标是发现异常、定位问题、评估容量和验证变更。告警的目标是让人行动,而不是制造噪音。Linux 监控通常结合指标、日志、事件、trace 和配置审计。
25.1 监控分层
| 层 | 指标 |
|---|---|
| 主机 | CPU、内存、磁盘、网络、进程 |
| 系统 | systemd、日志、内核事件、时间 |
| 应用 | QPS、延迟、错误率、连接池 |
| 中间件 | 队列、复制、缓存命中率 |
| 业务 | 订单量、支付成功率 |
| 体验 | 客户端成功率、首屏时间 |
黄金信号:
| 信号 | 说明 |
|---|---|
| Latency | 延迟 |
| Traffic | 流量 |
| Errors | 错误 |
| Saturation | 饱和度 |
25.2 主机指标
CPU:
uptime
vmstat 1
mpstat -P ALL 1
内存:
free -h
cat /proc/meminfo
vmstat 1
磁盘:
df -hT
df -ih
iostat -xz 1
网络:
ip -s link
ss -s
nstat -az
ethtool -S eth0
进程和服务:
systemctl --failed
pidstat 1
journalctl -p err --since '1 hour ago'
25.3 常用采集器
| 采集器 | 特点 |
|---|---|
| node_exporter | Prometheus 主机指标 |
| cAdvisor | 容器指标 |
| Telegraf | 插件丰富 |
| Datadog Agent | 商业 SaaS |
| CloudWatch Agent | AWS 生态 |
| Vector / Fluent Bit | 日志采集 |
Prometheus 示例:
node_cpu_seconds_total
node_memory_MemAvailable_bytes
node_filesystem_avail_bytes
node_disk_io_time_seconds_total
node_network_receive_bytes_total
典型 PromQL:
100 * (1 - avg by (instance)
(rate(node_cpu_seconds_total{mode="idle"}[5m])))
25.4 容器监控
docker stats
kubectl top nodes
kubectl top pods
核心指标:
| 指标 | 说明 |
|---|---|
| CPU usage | 实际使用 |
| CPU throttled | 限流 |
| Memory working set | 常用口径 |
| Memory limit | 上限 |
| Restart count | 重启 |
| Pod phase | 状态 |
| Network IO | 收发流量 |
容器内存指标有多个口径,working set 更接近 OOM 风险,但要结合 cgroup memory.stat 分析。
25.5 日志监控
采集:
journald / file / container stdout
-> Fluent Bit / Vector
-> Loki / Elasticsearch / OpenSearch
告警:
| 类型 | 示例 |
|---|---|
| 关键字 | OOM、panic、certificate expired |
| 错误率 | 5 分钟 ERROR 比例 |
| 缺失 | 心跳日志 |
| 数量突变 | 5xx 突增 |
| 审计 | sudo fail、SSH 登录 |
日志告警要结构化,否则很容易被多行、日志级别滥用和采样干扰。
25.6 告警设计
告警必须包含:
名称
严重级别
影响
可能原因
排查入口
处理手册
值班组
升级路径
分级:
| 级别 | 含义 |
|---|---|
| P0 | 核心业务不可用,立即响应 |
| P1 | 重要功能受损 |
| P2 | 存在风险但可等待 |
| P3 | 观察项 |
避免:
- 一个指标配十几个无差异告警;
- 告警无处理手册;
- 长期未知告警;
- 基于临时现象配置过严;
- 只告警主机 CPU,不告警业务错误率。
25.7 常用主机告警
CPU 使用率 > 90% 持续 10 分钟
内存 available < 10%
swap out 持续增长
磁盘使用率 > 85%
inode 使用率 > 80%
磁盘 await > 50ms 持续 5 分钟
网络错误包持续增长
TCP重传率异常
systemd failed units > 0
NTP 偏差 > 100ms
备份超过 25 小时未成功
阈值要结合业务节奏。批处理机器和在线服务不能用同一套阈值。
25.8 仪表盘
主机总览:
可用性
CPU / 内存 / 磁盘 / 网络
Top 进程
最近变更
最近告警
服务总览:
QPS
成功率
P50 / P95 / P99
实例分布
上下游依赖
资源水位
发布事件
排障视图:
时间线
指标关联
日志
trace
变更
网络路径
25.9 事件与变更
监控必须关联事件:
| 事件 | 来源 |
|---|---|
| 发布 | CI/CD |
| 配置变更 | 配置中心 |
| 扩缩容 | 编排系统 |
| 数据库变更 | 工单 |
| 网络变更 | 云平台审计 |
| 值班操作 | 工单 |
排障第一问通常是“什么变了”。没有变更事件,定位会慢很多。
25.10 故障验证
止血后验证:
1. 错误率回落
2. 延迟恢复基线
3. 队列积压下降
4. 实例健康
5. 日志无新异常
6. 客户端指标恢复
7. 24 小时内复盘
复盘产物:
- 时间线;
- 根因;
- 为什么监控没更早发现;
- 为什么告警没有触发;
- 新监控;
- 自动化检查;
- 容量计划;
- 责任人和截止时间。
本章小结
监控要覆盖主机、容器、应用、依赖和业务指标,并把告警与变更、日志和 trace 关联。好的告警能行动、能定位、能升级。监控体系的价值通过故障发现时间和排障效率验证。
思考题
- 黄金信号包括什么?
- CPU 使用率高是否一定需要告警?
- 容器内存监控应关注哪些口径?
- 如何减少无效告警?
- 为一个 Web 服务设计主机和应用监控清单。