journalctl 日志排查实战：从“服务挂了”到定位根因

服务挂了、启动失败、或者只是感觉变慢，第一反应往往是去翻 /var/log 里一堆文件。用了 systemd 之后，更省事的入口其实是 journalctl：它按服务、按时间、按优先级把日志串在一起，排查时少走很多弯路。这篇文章把我日常用得最多的几组命令整理出来，方便直接抄。

一、先锁定是哪个服务

大多数时候你已经知道是哪个 unit，直接跟：

systemctl status nginx
journalctl -u nginx -n 100 --no-pager

-u 指定 unit，-n 100 只看最近 100 行，--no-pager 避免进 less。如果 unit 名不确定，可以先列：

systemctl list-units --type=service --state=failed

失败的服务会直接跳出来，比在一堆 Running 里找要快。

二、按时间切，别整库翻

日志量一大，不加时间过滤就会刷屏。常用写法：

# 今天从开机到现在
journalctl -u myapp --since today

# 最近一小时
journalctl -u myapp --since "1 hour ago"

# 指定区间
journalctl -u myapp --since "2026-11-06 08:00" --until "2026-11-06 09:00"

时间字符串用引号包起来，本地时区按系统走。现场排查时我习惯先 --since "10 min ago"，确认有无输出再放宽窗口。

三、只看错误，先滤噪音

默认输出里 Info、Debug 都有，真正要找的往往是 Error 和以上：

journalctl -u myapp -p err..alert --since "1 hour ago"

-p 后面可以是数字（0 emergency 到 7 debug），也可以写 err、warning 这种名字。err..alert 表示从 err 到 alert 这一段。先看错误，再决定要不要把级别放宽到 warning。

跟一次启动更方便：

journalctl -u myapp -b
# 或上一次启动
journalctl -u myapp -b -1

-b 把范围缩到当前（或指定）那次启动，重启后排查“是不是这次启动才坏的”特别有用。

四、持续跟踪，像 tail -f

改完配置、重启服务后，需要盯着有没有新报错：

journalctl -u myapp -f

和 tail -f 一样，Ctrl+C 退出。如果同时要看好几个相关服务，可以写多个 -u：

journalctl -u nginx -u php-fpm -f

五、磁盘和持久化别忽略

journal 默认可能写在内存里，重启就没了；很多发行版会持久化到 /var/log/journal。可以确认：

ls /var/log/journal
journalctl --disk-usage

占用过大时，按时间或体积回收：

journalctl --vacuum-time=14d
journalctl --vacuum-size=500M

生产机建议在 /etc/systemd/journald.conf 里设好 SystemMaxUse=，避免日志把盘吃满（这点和 logrotate 管文件日志是同一类问题）。

六、一个最小排查顺序

1. systemctl status <unit> 看 Active 和最近几行。
2. journalctl -u <unit> -p err --since "1 hour ago" 抓错误。
3. 对照你刚改过的配置或部署时间，用 --since 收窄。
4. 需要盯重启过程时用 -f，确认新实例起来后没有继续报错。

把这几步养成习惯后，很多“服务挂了但不知道为什么”的问题，十分钟内就能定位到具体报错行，而不是在 /var/log 里盲搜。