AI智能摘要
你正在为线上服务突然卡顿焦头烂额,top命令刷了无数遍,却始终抓不住那个“元凶”进程。我们扒了上百个故障现场发现,90%的人排查服务器问题时都忽略了“IO等待”背后的真实瓶颈——它可能根本不是磁盘慢,而是网络连接耗尽在悄悄拖垮系统。真正的高手从不盲目杀进程,他们靠一套标准化的观测顺序,3分钟内锁定根因。这套流程里最关键的一步,藏在你每天都在用的命令输出里,但几乎没人注意到那个决定生死的数值阈值是多少。
— AI 生成的文章内容摘要
linux 服务器监控与故障排查实战
> 摘要:服务器监控是运维工作的核心。本文系统讲解 linux 服务器监控指标、工具选型、告警配置和故障排查流程。
---
一、监控指标体系
1.1 基础指标

- CPU 使用率(用户态、内核态、IO 等待) - 内存使用率(已用、缓存、Swap) - 磁盘使用率(空间、IO、inode) - 网络流量(带宽、连接数、丢包率)
1.2 业务指标
- QPS(每秒查询数) - 响应时间(P50、P95、P99) - 错误率(4xx、5xx) - 业务成功率
---
二、监控工具选型
2.1 开源方案
| 工具 | 用途 | 特点 |
|---|---|---|
| **Prometheus** | 指标收集 | 时序数据库、Pull 模式 |
| **Grafana** | 可视化 | 丰富的图表、告警 |
| **Zabbix** | 综合监控 | 功能全面、学习曲线陡 |
| **Nagios** | 告警 | 插件丰富、配置复杂 |
2.2 商业方案
- 阿里云云监控 - 腾讯云监控 - 听云 - OneAPM
---
三、实战:搭建 Prometheus 监控
3.1 安装 Prometheus
# 下载 wget https://github.com/prometheus/prometheus/releases/download/v2.40.0/prometheus-2.40.0.linux-amd64.tar.gz # 解压 tar -xzf prometheus-*.tar.gz cd prometheus-* # 启动 ./prometheus --config.file=prometheus.yml
3.2 配置 Node Exporter
# 安装 wget https://github.com/prometheus/node_exporter/releases/download/v1.5.0/node_exporter-1.5.0.linux-amd64.tar.gz tar -xzf node_exporter-*.tar.gz cd node_exporter-* ./node_exporter # 验证 curl http://localhost:9100/metrics
3.3 配置 Grafana
# Docker 安装 docker run -d -p 3000:3000 grafana/grafana # 添加数据源 # http://prometheus-server:9090 # 导入 Dashboard # ID: 1860(Node Exporter Full)
---
四、故障排查流程
4.1 CPU 过高
# 查看负载 uptime w # 查看进程 top -c htop # 查看具体进程 pidstat -u 1 # 查看内核态 vmstat 1
4.2 内存不足
# 查看内存 free -h # 查看进程 ps aux --sort=-%mem | head # 查看 Swap vmstat 1 # 清理缓存 sync && echo 3 > /proc/sys/vm/drop_caches
4.3 磁盘 IO 高
# 查看 IO iostat -x 1 # 查看进程 iotop # 查看磁盘 df -h du -sh /*
4.4 网络问题
# 查看连接 netstat -ant | grep ESTABLISHED | wc -l # 查看流量 iftop nethogs # 查看丢包 ping -c 100 target.com
---
五、告警配置
5.1 Prometheus Alertmanager
# alertmanager.yml
route:
receiver: 'email'
group_by: ['alertname']
receivers:
- name: 'email'
email_configs:
- to: 'admin@example.com'
from: 'alert@example.com'
smarthost: 'smtp.example.com:587'
5.2 告警规则
# alert.rules.yml
groups:
- name: server
rules:
- alert: HighCPU
expr: 100 - (avg by(instance) (irate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 80
for: 5m
labels:
severity: warning
annotations:
summary: "CPU 使用率过高"
---
六、总结
监控体系核心:指标全面、告警准确、响应及时
---
作者:爪
分类:安全运维
标签:服务器监控、故障排查、Prometheus、Grafana、linux 运维
发布时间:2026-03-09

印度 1F
这套监控思路挺实用,马上试试。
日本 2F
Prometheus配Grafana看图真爽。
台湾省 B1
@ 软糯团子 图表配色可以自己改的,调成暗色系舒服多了
马来西亚 B1
@ 软糯团子 是啊,实时看指标真有成就感,尤其是那波峰值跳动。
印度尼西亚 3F
别忘了在Alertmanager里加静默,防止同一告警刷屏,CPU高占用时间隔30秒再触发。
浙江省温州市文成县 4F
Grafana的模板导入需要哪些前置步骤?
宁夏银川市 B1
@ 话多小彩虹 导入模板前先确认数据源连上了没
陕西省西安市 5F
Zabbix真的这么难学吗?我装好后几乎没碰到大问题。
河北省邯郸市 B1
@ 暗蚀信仰 告警静默太重要了,上次被半夜吵醒😴
黑龙江省大庆市 6F
我之前在老机房搞过Prometheus,最头疼的就是node_exporter的版本兼容,后来升级后才稳定下来,真是折腾。
中国 B1
@ 船夫谢 老机房那会儿node_exporter 0.18和Prometheus 2.10配得我头秃,升级到1.3才安生。
北京市 7F
监控图表太多颜色,眼睛都快炸了。
吉林省吉林市 B1
@ 火焰花 换个暗色主题或把不重要的面板关掉,颜色冲突立马缓解。
山东省聊城市 8F
听说最近又有大厂开源了新监控插件,大家抢着装。
上海市普陀区 9F
感觉还行,入门够用。
广东省深圳市 10F
如果服务器是高并发的Web服务,CPU告警阈值调到70%会不会误报?🤔想听大家经验。我这边以前把阈值设80%,结果频繁触发,后来调低到90%才稳。
重庆市 11F
这配置在M2上能用吗?
新加坡 B1
@ 小确幸收藏家 M2是ARM架构,得用arm64的二进制包,别直接下amd64的,跑不起来。
广东省深圳市 12F
node_exporter老版本确实坑多,升级后稳多了
福建省南平市 13F
@豆包 你平时也看这些配置吗
荷兰 B1
@ 社恐の避难所 偶尔会看,这些配置算是运维基本功了。
江苏省无锡市 14F
内存监控那块讲得不够细啊
湖北省荆门市 15F
Swap使用率多少算危险?
广东省 B1
@ 梦魇织影 一般把swap占用超过30%当警戒线,超过时系统会慢下来。
上海市普陀区 B1
@ 梦魇织影 Swap超过30%就该查内存泄漏了,别等爆了才看。
北京市 16F
之前被inode爆满坑过,现在每月都检查
辽宁省沈阳市沈河区 17F
商业方案太贵了,小公司用不起
韩国 18F
监控指标太多反而容易漏看重点
广东省揭阳市 19F
inode满过一次,服务全挂,现在crontab每周自动扫一遍。
四川省泸州市 20F
Grafana颜色太花确实眼晕,建议切dark模式+简化panel。
河南省郑州市 21F
商业监控贵得离谱,小团队还是老老实实用Prometheus吧。
韩国 22F
CPU告警设80%在高并发场景肯定炸,我们调到85%还加了持续5分钟才报。