Linux：监控命令

1、需要监控的核心要点

[1.1 资源监控](#1.1 资源监控)

[1.2 服务与应用监控](#1.2 服务与应用监控)

[1.3 日志监控](#1.3 日志监控)

[1.4 安全性与合规监控](#1.4 安全性与合规监控)

2、容易出现的问题

[2.1 系统突然变慢，响应卡顿](#2.1 系统突然变慢，响应卡顿)

[2.2 "No space left on device" 错误](#2.2 “No space left on device” 错误)

[2.3 服务无法启动或端口无法访问](#2.3 服务无法启动或端口无法访问)

[2.4 网络连接失败、丢包或延迟高](#2.4 网络连接失败、丢包或延迟高)

[2.5 内存泄漏导致系统崩溃](#2.5 内存泄漏导致系统崩溃)

[2.6 安全入侵事件](#2.6 安全入侵事件)

3、常见监控与排查命令

[3.1 系统整体状态监控](#3.1 系统整体状态监控)

[3.2 CPU相关](#3.2 CPU相关)

[3.3 磁盘I/O相关](#3.3 磁盘I/O相关)

[3.4 网络相关](#3.4 网络相关)

[3.5 进程与日志相关](#3.5 进程与日志相关)

4、排查问题的经典思路

[第1步：明确问题现象 & 收集信息](#第1步：明确问题现象 & 收集信息)

第2步：检查系统整体状态（全局视野）

第3步：深入资源瓶颈维度

[第4步：定位到具体进程 & 分析上下文](#第4步：定位到具体进程 & 分析上下文)

[第5步：提出假设 & 验证解决](#第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问题：
1. 在 top 中按 P，找到占用CPU最高的进程。
2. 使用 pidstat -u 1 持续观察该进程的CPU使用情况。
3. 使用 perf top -p <PID> 分析该进程内部哪个函数最耗CPU。
如果怀疑内存问题：
1. 使用 free -h 确认内存和Swap使用情况。
2. 在 top 中按 M，找到占用内存最高的进程。
3. 使用 pidstat -r 1 观察可疑进程的内存变化。
4. 检查 /proc/meminfo，关注 Slab, SUnreclaim 等，看是否是内核对象占用过多。
如果怀疑磁盘I/O问题：
1. 使用 iostat -xz 1 查看所有磁盘的 %util 和 await。
2. 使用 iotop 找到进行大量I/O读写的进程。
3. 使用 df -h 检查是否是磁盘空间已满。
如果怀疑网络问题：
1. 使用 ss -tunp 查看网络连接数和状态。大量 TIME_WAIT 或 CLOSE_WAIT 可能意味着连接管理有问题。
2. 使用 sar -n DEV 1 查看网卡带宽是否被打满。
3. 使用 ping/traceroute 检查到目标地址的网络质量。
4. 使用 tcpdump 进行抓包分析（最后手段）。

第4步：定位到具体进程 & 分析上下文

通过以上步骤，你已经能定位到有问题的进程(PID)。

查看进程详情： ps -fp <PID> (查看启动命令、用户等)。
查看进程打开的文件和连接： lsof -p <PID>。
跟踪进程执行： 如果进程行为异常（如卡住、崩溃），使用 strace -p <PID> 跟踪其系统调用，看它卡在哪个调用上。
分析应用日志： 找到该进程对应的应用日志文件，使用 tail -f, grep 等工具搜索错误(Error)、异常(Exception)等关键字。

第5步：提出假设 & 验证解决

根据收集到的所有信息，提出一个合理的根本原因假设。

假设： "Nginx服务变慢是因为磁盘I/O等待过高，原因是某个PHP进程在执行一个巨大的SQL查询，导致MySQL写入了大量临时文件。"
验证：
1. 用 iotop 确认是 mysqld 进程在大量写盘。
2. 连接MySQL，使用 SHOW PROCESSLIST; 查看当前执行的慢查询。
3. 找到并优化那个慢查询。