查系统状态优先看 dmesg 和 journalctl -b：dmesg 获取内核级异常（硬件报错、驱动崩溃、OOM），需及时 dmesg -T 保存；journalctl -b 查用户空间服务日志，应配合 -b -1、-p err、-u、–since 等参数精准过滤。
查系统状态优先看 dmesg 和 journalctl -b
内核级异常（如硬件报错、驱动崩溃、OOM killer 触发）通常不会出现在普通日志里，dmesg 是第一手来源。但要注意，默认输出会滚动刷屏，且重启后缓冲区清空——所以故障刚发生时立刻执行 dmesg -T（带时间戳）并重定向保存，比如 dmesg -T > /tmp/dmesg.log。
journalctl -b 则覆盖用户空间服务启动和运行期日志，比 /var/log/messages 更全、更结构化。若系统启用了 systemd，它应是默认首选。常见误操作是只查 -b（本次启动），却忽略 -b -1（上一次启动），而很多“重启后变好”的问题，真正线索藏在前一次崩溃的 journal 里。
- 加
-p err只看错误级别：journalctl -b -p err - 按服务过滤：
journalctl -u sshd -n 50查最近 50 行 sshd 日志 - 时间范围用
--since "2024-06-10 14:00"，避免依赖系统时区混乱
磁盘 I/O 卡顿时别只盯 top，用 iostat -x 1 看真实瓶颈
top 显示的 %wa（I/O wait）只是 CPU 等待 I/O 的比例，它无法区分是磁盘慢、路径拥塞，还是应用本身频繁小写。真正定位得靠 iostat -x 1（需 sysstat 包）。
关键字段不是 %util（常被误读为“磁盘忙”，实际是队列非空时间占比），而是 await（单次 I/O 平均耗时）和 svctm（设备服务时间）。当 await >> svctm，说明 I/O 请求在队列里积压了，可能是磁盘过载、RAID 卡缓存失效，或虚拟机底层存储争抢。
-
avgqu-sz持续大于 1 表示请求排队，结合await升高可确认瓶颈在存储层 - SSD 场景下
await超过 10ms 就值得警惕；HDD 超过 50ms 通常已异常 - 注意
iostat默认不显示设备名全称（如nvme0n1p1），加-d参数才显示
strace 抓进程卡死时，慎用 -f 和 -e trace=network
当某个进程无响应但 CPU 占用低，strace -p 能看到它最后阻塞在哪个系统调用上——比如停在 recvfrom 就是等网络数据，卡在 futex 很可能是锁竞争。
