日志别再翻整个文件：journalctl 的五个常用查法

服务起不来、定时任务没跑、机器半夜重启过，第一反应往往是去翻 /var/log 里的文件，一个个 grep 过去又慢又容易漏。systemd 的机器上，journalctl 已经把系统日志、服务日志集中到了一处，查法得当的话，几条命令就能定位到关键时间点。

第一个查法是按服务查。journalctl -u 服务名 只看这一个服务的日志，比如 journalctl -u nginx、journalctl -u sshd。加上 -n 100 只看最近 100 行，-f 实时跟进，相当于给单个服务开了专用的 tail。服务名不用猜，systemctl list-units --type=service 能列出现有的。

第二个查法是按时间查。出问题的时间点往往是已知的：journalctl --since "2026-11-05 06:00" --until "2026-11-05 06:30" 只看这半小时；--since "1 hour ago"、--since yesterday 这种相对写法更顺手。先把时间范围收窄，再去看内容，比全量翻找省事得多。

第三个查法是看本次启动。机器重启后，旧日志和新日志混在一起容易看错行：journalctl -b 只看本次启动以来的日志，-b -1 看上一次启动的。排查“重启后服务没起来”这类问题时，先用 -b 确认看到的是这一次的记录，再往下找报错。

第四个查法是只看错误级别。journalctl -p err 只显示错误及以上级别，-p warning 再放宽一档。日志量大的机器上，先用级别过滤出错误，再用服务名或时间二次收窄，比逐行扫要快。注意级别过滤是“只看严重的”，排除了干扰，但也可能漏掉导致错误的前置警告，定位到时间点后还是要把前后几行展开看全。

第五个查法是看内核与启动过程。journalctl -k 只看内核消息，磁盘、内存、驱动层面的异常常出现在这里；journalctl -b 配合服务名，能还原一次启动的完整顺序。查完别忘了，journalctl 默认只显示当前可读的日志，普通用户可能看不到全部系统日志，需要时用 sudo。

一句话总结：先定服务（-u）、再定时间（–since）、重启问题先定启动（-b）、量大先按级别（-p）过滤、硬件异常看内核（-k）。五个查法组合起来用，大多数“服务为什么挂了”的问题，都能在几分钟内找到第一条关键报错，而不是在日志文件里大海捞针。