用 journalctl 高效排查 Linux 服务日志

服务起不来、接口偶发超时、重启之后现象消失，很多人会先去翻 /var/log 下的文本文件。在使用 systemd 的 Linux 上，journalctl 通常更快：它按单元、启动序号和优先级建了索引，不必先猜日志落在哪个文件。

先把范围收成一个单元。例如 Nginx 异常时，不要把整机日志倒出来：

journalctl -u nginx.service --no-pager

-u 可以写多次，同时看应用本身和它依赖的数据库。单元名尽量写全，带上 .service，避免同名前缀被一起匹配进来。如果不确定单元名，先用 systemctl list-units --type=service 找到准确名称，再交给 journalctl。

本次启动和上次启动要分开。-b 不加参数表示当前这次启动；-b -1 是上一次。遇到“重启就好了”或“重启之后才挂”时，分别看两次启动末尾的几十行，比在一份混在一起的日志里对时间戳更省事。若机器一天重启了好几次，可以用 journalctl --list-boots 先列出每次启动的序号和时间，再决定看哪一次。内核在启动早期打出的报错，也只会出现在对应那一次 -b 里。

优先级用来去噪。-p err 只保留 error 以及更严重的 crit、alert、emerg；-p warning 会再带上 warning。线上先看 err，确认没有致命错误，再放宽到 warning。不要一上来就用 info，否则真正的错误会被正常访问日志淹没。优先级是“小于等于”的过滤，指定 err 时更严重的级别不会被丢掉。

时间窗口用 --since 和 --until。故障若发生在今早九点前后，可以写成：

journalctl -u myapp.service --since “2026-10-27 08:40” --until “2026-10-27 09:20”

也支持相对时间，例如 --since “30 min ago” 或 --since today。和 -u 一起用，输出会短很多，方便复制到工单里。时间请写机器本地时区，和 date 命令看到的一致，否则窗口会对不齐。

需要盯着现场时再加 -f，效果类似 tail -f，但仍然受 -u 和 -p 的约束。建议先不加 -f，把已经发生的历史看清楚，再打开跟随，否则新日志会把关键栈信息刷出屏幕。跟随时若要退出，直接 Ctrl-C 即可，不会改动 journal。若只想看最新的若干行再进入跟随，可以写成 -n 50 -f。

什么时候改用 -o json？给人阅读时用默认的短格式就够了。只有要把结果交给脚本、jq 或日志平台时，才使用 -o json 或 -o json-pretty。JSON 里带有 _SYSTEMD_UNIT、_PID、PRIORITY 和 __REALTIME_TIMESTAMP，适合按字段过滤和统计。它比短格式大很多，和 -f 一起用会更吵，所以交互排查优先短格式，导出分析时再切到 json。注意 json 输出里的时间戳是微秒数字，给人看并不直观。

如果日志已经被 vacuum 清掉，journalctl 只能看到仍保留的部分。先用 journalctl --disk-usage 看占用，确认磁盘压力后再清理；排查进行中不要先删日志。容器里的进程若没有接入宿主 journal，-u 会是空的，这时要回到该环境自己的日志，而不是一味加大时间窗口。

日常可以记一个组合：journalctl -u myapp.service -b -p warning --since “1 hour ago” --no-pager。先定单元和本次启动，再用优先级与时间收窄，最后才考虑 -f 或 -o json。这样大部分服务故障都能在一两分钟内把可疑日志圈出来。