dmesg和journalctl -p err是定位90%系统级错误的首选工具；dmesg专查内核环缓冲区中的硬件驱动及oom事件，需加-t带时间戳并及时保存；journalctl -p err用于筛选服务级错误，应结合-u和服务名、--since等参数精准过滤，避免依赖数字优先级。
直接看 dmesg 或 journalctl -p err，90% 的系统级错误（如硬件识别失败、驱动崩溃、OOM killer 触发）会第一时间出现在这两个地方，而不是 /var/log/messages 或 auth.log。
查内核级错误：用 dmesg 看硬件和驱动问题
内核错误（比如 USB 设备失联、磁盘 I/O timeout、内存不足被 kill）只写进内核环缓冲区，dmesg 是唯一能直接读它的命令。默认输出不带时间戳，容易误判发生顺序。
- 加
-T显示人类可读时间：dmesg -T | grep -i "error\|fail\|warn" - 只看最近 50 条错误/警告：
dmesg -l err,warn -n 50 - 过滤特定设备：
dmesg | grep -i "nvme\|usb\|eth0"，注意大小写不敏感更可靠 -
dmesg输出是易失的——重启后清空，所以发现异常要立刻保存：dmesg -T > /tmp/kern_err_$(date +%s).log
查 systemd 服务级错误：用 journalctl -p err
服务启动失败、配置加载出错、子进程异常退出等，都会被 journald 记录并标为 err 或更高优先级。但默认 journalctl 不显示优先级标签，得手动筛。
- 只看错误及以上（
err、crit、alert、emerg）：journalctl -p err - 结合服务名缩小范围：
journalctl -u nginx.service -p err - 查最近 1 小时的错误：
journalctl --since "1 hour ago" -p err - 别用
journalctl -p 3这种数字写法——不同发行版数字映射可能不一致，坚持用err字符串
查传统文本日志里的错误：grep 要带上下文
/var/log/messages 或 /var/log/syslog 里确实有部分错误，但纯靠 grep "error" 极易漏掉关键线索——错误行本身往往没“error”字样，而是 “Connection refused”、“No space left on device” 这类描述。
- 用多个关键词组合：
grep -i -E "(fail|refused|timeout|denied|full|oom)" /var/log/messages - 必须加
-C 3看上下文：grep -i -C 3 "out of memory" /var/log/messages，否则看不到被 kill 的进程名和 PID - 权限常被忽略：这些文件多数需 root 才能读全，
sudo grep ...不是可选项，是必选项 -
auth.log和secure里“error”极少出现，重点搜"Failed password"、"Invalid user"、"session opened/closed"
真正难的不是找到错误行，而是判断哪条错误是根因——比如 dmesg 里先出现 NVMe 超时，几分钟后 journalctl 才报 PostgreSQL 启动失败，这时不能只盯着后者修。日志之间的时间差和依赖链，比单条错误内容更重要。
