服务器报警了？别慌，这篇文章手把手教你该看什么
凌晨三点，手机突然狂震，监控系统弹出一条红色警报：“CPU使用率持续99%”，你从被窝里爬出来，坐到电脑前，手指有点抖，脑子里闪过一万种可能性——被挖矿了？程序bug？还是流量突增？深呼吸，先别慌，超过70%的服务器报警都是虚惊一场，或者是可以通过简单检查快速定位的常见问题，关键是你得知道“看什么”以及“怎么看”。
作为一名混迹运维圈多年的老兵，我踩过的坑比你吃过的盐还多，今天就把这套“报警三板斧”掰开揉碎了讲给你听，面对报警，第一步不是修，而是看——看对地方，你就成功了一半。
一、硬件层面：先确认机器还活着
1. CPU：是满负荷还是被某个进程占满？
报警最常见的指标就是CPU，但“CPU高”和“CPU有问题”是两回事。
先看整体利用率：用top 或htop 看一眼，如果CPU整体在80%以上，再用Shift + P 按CPU占用排序，看看是哪个进程在吃资源。
注意iowait：如果top 里wa 那一项很高（比如超过20%），说明CPU在等磁盘I/O，这时候CPU本身没问题，是磁盘拖了后腿，常见原因：磁盘读写慢、数据库查询卡顿、swap交换频繁。
检查软中断和上下文切换：cat /proc/softirqs 看看网络中断有没有爆表，或者用vmstat 1 观察cs (context switch) 是否异常高，我曾经遇到过一个网卡驱动bug，导致每秒上千次软中断，CPU直接飙到100%。
一个小技巧：如果CPU忽高忽低像过山车，先看是不是定时任务（crontab）扎堆执行了，很多团队喜欢把任务放在整点，结果每个整点服务器就像被踢了一脚。
很多人一看到内存使用率90%就慌，但Linux的内存管理机制很聪明——它会把空闲内存拿来做缓存（cache），真正的报警要看：
free -h：关注available 这一列，这才是真正可用的内存，如果available快见底，且swap 使用量持续增长，那才叫危险。
dmesg | tail -20：查看是否有OOM killer的记录，如果系统杀掉了重要进程（比如mysqld），那立刻就能在日志里看到“Out of memory: killed process xxx”。
- 还要注意内存泄漏：用ps aux --sort=-%mem | head 看哪个进程不断在涨，Java程序特别容易这样，用jstat 检查GC情况。
磁盘报警最常见的两类：空间不足和IO负载过高。
空间：df -h 一看便知，但要警惕的是inode耗尽——明明空间还有，但文件写不进去了，用df -i 检查。
IO负载：iostat -x 1 看%util 和await，如果%util 接近100%，说明磁盘一直在忙；await 超过几十毫秒说明响应慢，这时候要找出是哪个进程在疯狂读写：iotop 是最直接的，或者用lsof 加进程ID看打开的文件。
一个经典案例：某次报警说磁盘IO高，查了半天发现是日志轮转没做好，一个应用每秒打印几万行日志，硬生生把SSD写成了瓶颈。
网络报警通常来自ping或者SNMP，但真正排查时：
ping 丢包不一定是网络问题，也可能是对方服务器防火墙限流了，建议用mtr 来分段看路径上的丢包点。
- 带宽打满：iftop 或者nload 看实时流量，哪个IP在狂传数据，注意内外网方向——如果是内网流暴增，可能是备份任务或者P2P同步；如果是外网带宽占满，先检查是不是被DDoS了（比如用netstat -an | grep SYN 看半连接数）。
- 端口和连接：ss -tan 看看有多少TIME_WAIT连接，太多会导致端口耗尽。netstat -s 可以看到重传率，高于1%就要警惕。
二、系统层面：日志里藏着真相
硬件没毛病？别急，接下来要看系统日志，这是运维的“福尔摩斯放大镜”。
1. 系统日志（Syslog/Journal）
- 第一时间敲journalctl -xe（CentOS 7+ 或 Ubuntu 16+），它会显示最近的系统错误，或者去/var/log/messages（RHEL系）、/var/log/syslog（Debian系）看。
- 重点关注日志里的error、fail、timeout 等关键词，比如systemd 服务重启、磁盘坏道、网卡down等都会在这里留下痕迹。
很多报警是应用层抛出来的，但监控系统只看到了表象（比如CPU高），这时候要杀进应用日志目录：
- Java应用：看catalina.out、error.log，配合grep -i exception 快速过滤。
- Nginx：看access.log 是否有大量4xx/5xx，error.log 里有没有连接超时、worker进程崩溃。
- 数据库：MySQL的slow_query_log 能帮你找到拖慢全库的慢查询；PostgreSQL的pg_stat_activity 检查是否有长时间运行的锁。
dmesg 这个命令是宝藏，它显示的是内核环形缓冲区，很多硬件级别的报错会写在这里。
- 磁盘报错：Buffer I/O error on device sda
- 内存ECC错误：EDAC MC0: CE error on DIMM
- 网卡掉线：ixgbe: NIC Link is Down
如果你看到类似“blocked for more than 120 seconds”的字样，意味着某个进程被I/O阻塞了超过2分钟，这是很严重的信号。
三、应用层面：你的服务真的挂了吗？
有时候服务器指标一切正常，但监控报警说“HTTP返回500”或者“服务不可用”，这时候要检查的是服务本身。
systemctl status xxx 是最简单的，但注意：进程活着不代表服务正常，比如Java进程假死（线程死锁），端口还在监听，但请求完全不响应，可以用curl -I 模拟请求，看实际返回状态码。
ss -tlnp 或netstat -tnlp 确认端口在监听，如果端口没了，检查服务是否被OOM杀掉、是否因为配置错误崩溃了，查看systemctl 的启动日志可以知道最近一次退出原因。
Web应用常见的报警原因是数据库连接耗尽，登录数据库用show processlist;（MySQL）查看有多少连接在等待、是否有很多Sleep 连接，如果连接数超过max_connections，新请求就会报错，这种情况要么是应用没释放连接，要么是业务流量突增。
这是个容易被忽略的坑，服务器本身没问题，但SSL证书过期了，用户访问时报错，监控系统检测到“无法建立TLS连接”就会报警，用openssl s_client -connect yourdomain.com:443 -tlsextdebug 检查证书有效期。
四、安全层面：排除入侵或攻击
如果排除了以上所有可能，且服务器CPU/内存/网络异常飙升又找不到进程原因，那就要警惕安全事件了。
先看有没有陌生进程在跑，用ps aux | grep -v '^_' 过滤，或者直接用htop 按CPU排序，常见挖矿进程起名很迷惑，比如systemd-login、kworker 的变种，注意看PID：正常的系统进程PID通常小于1000，如果有一个高PID的进程叫kworker，很可能是假的。
lsof -i 能看到所有打开的网络连接，如果有大量连接指向未知的国外IP，或者建立了非标准端口（比如6666、4444等），大概率是被植入了后门，用netstat -ant | grep ESTABLISHED | awk '{print $4}' | sort | uniq -c 统计连接数，异常明显。
很多恶意脚本会通过crontab持久化，执行crontab -l 和cat /var/spool/cron/ 看有没有定时任务，再检查/etc/init.d/、~/.bashrc、/etc/rc.local 等地方有没有可疑的自启项。
last 命令查看最近登录记录，有没有来自奇怪IP的登录？检查/var/log/secure（CentOS）或/var/log/auth.log（Ubuntu）看失败登录尝试，如果大量暴力破解失败，报警可能是“SSH登录失败次数过多”——这时候改端口、禁用密码登录、用fail2ban才是治本。
五、报警平台本身：别忘了检查“监控的监控”
最讽刺的是：报警系统自己挂了，然后你还傻乎乎地排查了一个小时。
- 检查监控agent是否还在运行？比如Zabbix agent、Prometheus exporter是否正常上报数据？
- 检查报警阈值是否合理？有些报警是因为阈值设得太低，比如磁盘使用率设定85%报警，而实际上那个分区就是用来存临时文件，90%都很正常。
- 检查网络连通性：监控服务器和被监控服务器之间是否有防火墙拦截？有时候是监控中心刚重启，导致数据抖动。
六、一个实用的排障思维框架
当你面对一张红通通的报警页面时，建议按这个顺序思考：
1、严重性判断：这是核心业务还是边缘服务？会影响用户吗？如果是非关键节点，可以白天再处理。
2、时间关联：报警是什么时候开始的？有没有和最近的发版、配置变更、流量高峰重合？去看看Git提交记录或变更工单。
3、查看监控趋势图：很多监控工具（如Grafana）会显示14天、7天、1天的曲线，如果今天的数据和昨天同一时段一模一样，说明是周期性任务导致的，不用太紧张。
4、先看全局再看局部：先确认是单台服务器还是整个集群？是单个指标异常还是多指标联动？比如CPU和内存同时飙升，很可能是应用bug；如果只有CPU飙升但网络正常，可能是计算密集任务。
5、记录完整的上下文：别急着重启或kill进程，先保存现场：top、ps、netstat等结果截图或输出到文件，万一需要复盘或升级问题，这些就是第一手证据。
写在最后
服务器报警就像一个信号灯，黄灯是提醒，红灯才需要紧急停车，很多新手运维看到报警就手忙脚乱，直接重启大法甚至重装系统——这是最糟糕的做法。大多数报警的根源藏在日志里，而不是在重启后消失，重启只是把症状掩盖了，第二天它还会回来找你。
真正的高手，面对凌晨三点那条报警，会一边喝着咖啡一边慢悠悠地敲几行命令，三分钟后得出结论：“哦，是隔壁部门跑数据造成的，明天让他们改时间。”然后安心回去睡觉。
希望今天这篇“查看指南”能帮你从手忙脚乱进阶到从容淡定，纸上得来终觉浅，最好的学习方式还是——多踩坑，多复盘，下次报警来了，别怕，你已经知道该看什么了。
文章摘自：https://idc.huochengrm.cn/js/25113.html
评论