Linux：监控命令
目录
1、需要监控的核心要点
1.1 资源监控
1.2 服务与应用监控
1.3 日志监控
1.4 安全性与合规监控
2、容易出现的问题
2.1 系统突然变慢，响应卡顿
2.2 “No space left on device” 错误
2.3 服务无法启动或端口无法访问
2.4 网络连接失败、丢包或延迟高
2.5 内存泄漏导致系统崩溃
2.6 安全入侵事件
3、常见监控与排查命令
3.1 系统整体状态监控
3.2 CPU相关
3.3 磁盘I/O相关
3.4 网络相关
3.5 进程与日志相关
4、排查问题的经典思路
第1步：明确问题现象 & 收集信息
第2步：检查系统整体状态（全局视野）
第3步：深入资源瓶颈维度
第4步：定位到具体进程 & 分析上下文
第5步：提出假设 & 验证解决
1、需要监控的核心要点
1.1 资源监控
这是最基础也是最重要的部分，直接反映了系统的健康度。
-
CPU：
-
使用率： 用户态、系统态、I/O等待、软硬中断、空闲时间。重点关注
%us（用户进程）和%sy（系统进程）是否长期过高，以及%wa（I/O等待）是否过高。 -
负载： 系统平均负载。对于单核CPU，1.0是临界点；对于N核CPU，N是临界点。负载高于CPU核数就意味着有进程在等待CPU。
-
上下文切换和中断次数： 频繁的上下文切换会消耗CPU资源。
-
-
内存：
-
使用率： 总内存、已用内存、空闲内存、缓冲和缓存。
-
Swap使用率： 一旦开始使用Swap，性能就会急剧下降。Swap频繁读写是内存不足的明确信号。
-
内存泄漏： 观察可用内存是否在持续下降，即使重启了相关应用。
-
-
磁盘 I/O：
-
使用率： 每个分区的使用百分比。根分区
/填满是致命问题。 -
Inode使用率： 即使磁盘空间充足，inode耗尽也无法创建新文件。
-
I/O 读写速率、IOPS、响应时间： 反映磁盘的繁忙程度和性能。响应时间过长通常意味着磁盘瓶颈。
-
-
网络：
-
带宽使用率： 流入和流出的流量。
-
连接数： TCP/UDP连接状态（如
ESTABLISHED,TIME_WAIT,CLOSE_WAIT）。CLOSE_WAIT过多可能意味着应用程序未正确关闭连接。 -
错误包和丢包率： 网卡、驱动或网络拥堵问题。
-
1.2 服务与应用监控
光有资源正常还不够，上面跑的服务也必须正常。
-
进程状态： 关键进程（如 Nginx, MySQL, Redis, 你的业务进程）是否在运行。
-
端口状态： 关键服务监听的端口是否能正常连接。
-
应用性能指标：
-
Web服务： 请求量、响应时间、错误率（5xx）。
-
数据库： 查询速度、连接数、慢查询、锁等待。
-
中间件： 队列长度、缓存命中率。
-
1.3 日志监控
日志是发现问题和追溯根源的宝库。
-
错误日志： 实时扫描
/var/log/以及应用日志中的ERROR,FATAL,Exception等关键字。 -
访问日志： 分析流量模式、异常访问（如某个IP短时间内大量请求）。
-
系统日志：
/var/log/messages或/var/log/syslog中的内核和系统级报错。
1.4 安全性与合规监控
-
登录情况： 成功/失败的登录记录（
/var/log/secure或/var/log/auth.log）。重点关注暴力破解。 -
文件完整性： 关键系统文件（如
/etc/passwd,/etc/shadow, 二进制程序）是否被篡改。 -
root权限变更： 任何使用
sudo或su切换到root的操作。
2、容易出现的问题
2.1 系统突然变慢，响应卡顿
-
问题根源：
-
CPU瓶颈：
%us或%sy持续100%，或平均负载远高于CPU核数。 -
内存瓶颈： 可用内存耗尽，开始大量使用Swap，导致I/O等待（
%wa）飙升。 -
I/O瓶颈： 磁盘利用率100%，I/O响应时间过长（例如超过几十毫秒）。
-
-
排查命令：
top,htop,vmstat 1,iostat -x 1
2.2 “No space left on device” 错误
-
问题根源：
-
磁盘空间耗尽。
-
更隐蔽的情况： inode 耗尽。即使
df -h显示有空间，但df -i会显示 inode 已满，通常是由于大量小文件造成。
-
-
排查命令：
df -h,df -i,du -sh /*逐级定位大目录。
2.3 服务无法启动或端口无法访问
-
问题根源：
-
进程崩溃或被误杀。
-
配置文件语法错误。
-
依赖的服务（如数据库）不可用。
-
防火墙规则阻止了访问。
-
-
排查命令：
systemctl status <service_name>,journalctl -u <service_name>,netstat -tunlp | grep <port>,iptables -L
2.4 网络连接失败、丢包或延迟高
-
问题根源：
-
网络带宽打满。
-
防火墙/安全组策略。
-
物理网络问题或网卡故障。
-
本地连接数达到上限（
ulimit或内核参数限制）。
-
-
排查命令：
ping,traceroute,netstat -s,ss -s,ethtool <interface>
2.5 内存泄漏导致系统崩溃
-
问题根源： 某个应用程序（如Java/Python应用）持续申请内存却不释放，最终耗尽所有内存和Swap，触发OOM Killer杀死进程，可能导致服务雪崩。
-
排查命令： 观察
free -h中可用内存的长期趋势，使用ps aux --sort=-%mem查看内存消耗最大的进程。
2.6 安全入侵事件
-
问题根源：
-
弱密码被暴力破解。
-
系统或软件存在未修复的漏洞。
-
部署了带有后门的恶意软件。
-
-
排查迹象： 未知的登录IP和用户、未知的进程、异常的网络连接（如向外网IP发送数据）、系统文件被修改。
3、常见监控与排查命令
3.1 系统整体状态监控
| 命令 | 主要用途 | 常用参数/示例 | 关键信息 |
|---|---|---|---|
top / htop | 实时动态查看系统整体性能状态，包括负载、进程、CPU、内存等。 | top htop (更友好) | 负载平均值(load average), CPU使用率(%Cpu(s)), 内存使用(MiB Mem), 运行中的进程。 |
uptime | 快速查看系统运行时间、用户数和平均负载。 | uptime | load average: 1min, 5min, 15min 是核心指标。 |
vmstat | 报告关于进程、内存、分页、块IO、陷阱和CPU活动的信息。 | vmstat 1 (每秒刷新一次) | procs.r (就绪队列长度), si/so (Swap In/Out, 不为0需警惕), us/sy/id (用户/系统/空闲CPU时间)。 |
dstat | 全能系统信息统计工具，可以替代 vmstat, iostat, netstat 等。 | dstat -cdlmnpsy 1 | 同时查看CPU、磁盘、负载、网络、内存、分页、系统统计。 |
3.2 CPU相关
| 命令 | 主要用途 | 常用参数/示例 | 关键信息 |
|---|---|---|---|
top / htop | 查看每个进程的CPU使用率。 | 在 top 界面按 P (按CPU排序) | %CPU 列。 |
pidstat | 用于监控每个进程的CPU使用情况，可动态输出。 | pidstat -u 1 | %usr, %system, %CPU。 |
perf | 强大的性能分析工具，可以分析CPU周期、缓存命中、系统调用等。 | perf top perf record -g -p <PID> | 函数级别的性能热点。 |
mpstat | 查看每个CPU核心的详细状态。 | mpstat -P ALL 1 | 查看是否有单个核心被跑满。 |
3.3 磁盘I/O相关
| 命令 | 主要用途 | 常用参数/示例 | 关键信息 |
|---|---|---|---|
iostat | 查看磁盘的读写速率、IOPS、吞吐量和平均等待时间。 | iostat -xz 1 | %util (设备带宽利用率)，await (平均I/O等待时间)，r/s, w/s (读写速率)。 |
iotop | 类似 top，实时显示磁盘I/O的进程。 | iotop | 哪个进程在进行大量I/O操作。 |
pidstat | 监控每个进程的I/O。 | pidstat -d 1 | kB_rd/s, kB_wr/s (每秒读写KB数)。 |
df | 查看磁盘空间使用情况。 | df -h | 检查是否因磁盘满导致问题。 |
du | 查看目录/文件占用的磁盘空间。 | du -sh /path/to/dir | 定位大文件。 |
3.4 网络相关
| 命令 | 主要用途 | 常用参数/示例 | 关键信息 |
|---|---|---|---|
netstat / ss | 查看网络连接、路由表、接口统计等。ss 更现代、更快。 | ss -tlnp (查看监听端口) ss -tunp (查看所有连接) | 连接状态(ESTAB, TIME_WAIT)，本地/远程地址。 |
sar | 系统活动报告，可以查看历史网络流量。 | sar -n DEV 1 | rxkB/s, txkB/s (网络进出口流量)。 |
ethtool | 查看和配置网卡参数。 | ethtool eth0 | 查看网卡速率、双工模式。 |
tcpdump | 强大的网络抓包工具。 | tcpdump -i any -n host 1.2.3.4 | 进行深度网络问题排查。 |
ping / traceroute | 测试网络连通性和路由。 | ping example.com traceroute example.com | 基础连通性检查。 |
nslookup / dig | 诊断DNS问题。 | dig @8.8.8.8 example.com | 检查域名解析是否正确。 |
3.5 进程与日志相关
| 命令 | 主要用途 | 常用参数/示例 | 关键信息 |
|---|---|---|---|
ps | 显示当前进程的快照。 | ps aux ps -ef ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | 进程状态、资源占用、父进程ID。 |
lsof | 列出被进程打开的文件。 | lsof -p <PID> lsof -i :8080 (查看谁在监听8080端口) | 进程打开了哪些文件、网络连接。 |
strace / ltrace | 跟踪进程的系统调用或库函数调用。 | strace -ff -p <PID> | 查看进程在底层做了什么，用于调试程序异常。 |
journalctl | 查看 systemd 管理的服务日志。 | journalctl -u nginx -f (追踪nginx日志) journalctl --since "1 hour ago" | 集中式的系统和服务日志。 |
tail / grep | 查看和搜索日志文件。 | tail -f /var/log/nginx/access.log grep "error" /var/log/messages | 实时监控和关键字过滤。 |
4、排查问题的经典思路
第1步：明确问题现象 & 收集信息
-
现象是什么？ 是服务响应慢？还是直接报错“502 Bad Gateway”？或者是服务器卡死？
-
影响范围？ 是单个用户还是所有用户？是单个服务还是整个系统？
-
发生时间？ 是特定时间点还是持续发生？最近是否有过代码发布、配置变更？
第2步：检查系统整体状态（全局视野）
使用 top 或 htop 快速获取全局状态。
-
看负载 (
load average)-
如果1分钟负载远高于CPU核心数，说明系统繁忙。
-
对比1分钟、5分钟、15分钟负载，看趋势是上升、下降还是平稳。
-
-
看CPU (
%Cpu(s))-
%us高：用户态进程占用CPU高，可能是应用代码问题。 -
%sy高：内核态占用CPU高，可能是系统调用频繁或上下文切换过多。 -
%wa高：I/O等待高，说明CPU在等待磁盘或网络I/O，瓶颈在I/O。 -
%id高：CPU空闲，问题可能不在CPU。
-
-
看内存 (
MiB Mem)-
free内存是否几乎为0？ -
available有多少？如果很小，系统可能在使用Swap。
-
-
看Swap (
MiB Swap)-
used是否大于0？如果Swap被频繁使用(si/so在vmstat中很高)，会极大影响性能。
-
此时，已经能初步判断瓶颈大致在哪个资源上（CPU、内存、I/O）。
第3步：深入资源瓶颈维度
根据上一步的初步判断，使用更精细的命令深入排查。
-
如果怀疑CPU问题：
-
在
top中按P，找到占用CPU最高的进程。 -
使用
pidstat -u 1持续观察该进程的CPU使用情况。 -
使用
perf top -p <PID>分析该进程内部哪个函数最耗CPU。
-
-
如果怀疑内存问题：
-
使用
free -h确认内存和Swap使用情况。 -
在
top中按M，找到占用内存最高的进程。 -
使用
pidstat -r 1观察可疑进程的内存变化。 -
检查
/proc/meminfo，关注Slab,SUnreclaim等，看是否是内核对象占用过多。
-
-
如果怀疑磁盘I/O问题：
-
使用
iostat -xz 1查看所有磁盘的%util和await。 -
使用
iotop找到进行大量I/O读写的进程。 -
使用
df -h检查是否是磁盘空间已满。
-
-
如果怀疑网络问题：
-
使用
ss -tunp查看网络连接数和状态。大量TIME_WAIT或CLOSE_WAIT可能意味着连接管理有问题。 -
使用
sar -n DEV 1查看网卡带宽是否被打满。 -
使用
ping/traceroute检查到目标地址的网络质量。 -
使用
tcpdump进行抓包分析（最后手段）。
-
第4步：定位到具体进程 & 分析上下文
通过以上步骤，你已经能定位到有问题的进程(PID)。
-
查看进程详情：
ps -fp <PID>(查看启动命令、用户等)。 -
查看进程打开的文件和连接：
lsof -p <PID>。 -
跟踪进程执行： 如果进程行为异常（如卡住、崩溃），使用
strace -p <PID>跟踪其系统调用，看它卡在哪个调用上。 -
分析应用日志： 找到该进程对应的应用日志文件，使用
tail -f,grep等工具搜索错误(Error)、异常(Exception)等关键字。
第5步：提出假设 & 验证解决
根据收集到的所有信息，提出一个合理的根本原因假设。
-
假设： “Nginx服务变慢是因为磁盘I/O等待过高，原因是某个PHP进程在执行一个巨大的SQL查询，导致MySQL写入了大量临时文件。”
-
验证：
-
用
iotop确认是mysqld进程在大量写盘。 -
连接MySQL，使用
SHOW PROCESSLIST;查看当前执行的慢查询。 -
找到并优化那个慢查询。
-