LinuxNotes

第 25 章:监控告警

zjc 于 2026-01-25 发布

这是《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 观察项

避免:

  1. 一个指标配十几个无差异告警;
  2. 告警无处理手册;
  3. 长期未知告警;
  4. 基于临时现象配置过严;
  5. 只告警主机 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 小时内复盘

复盘产物:

  1. 时间线;
  2. 根因;
  3. 为什么监控没更早发现;
  4. 为什么告警没有触发;
  5. 新监控;
  6. 自动化检查;
  7. 容量计划;
  8. 责任人和截止时间。

本章小结

监控要覆盖主机、容器、应用、依赖和业务指标,并把告警与变更、日志和 trace 关联。好的告警能行动、能定位、能升级。监控体系的价值通过故障发现时间和排障效率验证。

思考题

  1. 黄金信号包括什么?
  2. CPU 使用率高是否一定需要告警?
  3. 容器内存监控应关注哪些口径?
  4. 如何减少无效告警?
  5. 为一个 Web 服务设计主机和应用监控清单。