Linux journalctl 看服务日志的三个实用技巧

服务跑在 systemd 上之后，日志不再散落在 /var/log 下面的各个文本文件里。journalctl 把内核、服务和用户会话收到同一套日志中。排障时如果只会执行 journalctl -u nginx 然后一直往下翻，信息很多，真正有用的几行却不好找。下面三个用法，是我在虚拟机和云主机上反复用到的，不涉及改配置，只把“看日志”这件事做窄、做准。

一、按服务和时间窗口一起收窄

只看某一个 unit，再把时间限制在故障发生前后，比全量滚动省事得多。例如只看今天上午九点到九点半的 nginx：

journalctl -u nginx.service --since “2026-10-27 09:00” --until “2026-10-27 09:30”

–since 也接受相对时间，例如 -1h、yesterday、today。排查“刚才发布之后错误变多”时，我通常先取最近十五分钟：

journalctl -u nginx.service --since “-15min” --no-pager

–no-pager 让输出直接打到终端，方便再接到 grep，或重定向成文件留给同事。如果服务名不确定，先用 systemctl list-units --type=service --state=running 看正在跑的单元，不要凭记忆拼错名字。单元名建议写全 .service，避免和同名的 timer、socket 混在一起。时间窗口尽量和告警时间对齐，窗口太宽，错误行还是会被正常访问日志淹没。

二、用优先级把噪音压下去

journal 的优先级和 syslog 一致，从 emerg 一直到 debug。线上默认日志里 info 占比很高，真正要处理的往往是 warning 及以上。-p err 只保留 error、crit、alert、emerg：

journalctl -u sshd.service -p err --since today

如果想看“警告以及更严重”的记录，可以用范围写法 -p warning…alert，避免把 debug 也卷进来。排障时我习惯开两个终端：一个看 -p err，确认有没有硬错误；另一个不加优先级，看同一时间窗的上下文。只看错误会漏掉前面那条“配置重载失败，但仍在跑旧配置”的 warning，而那条往往才是根因。

-o short-iso 会给每行带上带时区的时间戳，和监控告警里的时间对齐时更不容易算错。需要把原始字段交给脚本时，可以用 -o json，但日常阅读还是 short-iso 更紧凑。把优先级、时间窗口和输出格式叠在同一条命令里，复制给同事时对方也不用再猜你筛过什么。

三、跟随输出，并确认日志有没有被截断

故障还在发生时，-f 的作用类似 tail -f，新日志会持续刷出来：

journalctl -u myapp.service -f -o short-iso

跟着看之前，先确认 journal 没有因为磁盘占用把旧记录清掉。journalctl --disk-usage 能看到当前占用。如果机器已经在报磁盘告警，而关键时刻的日志却接不上，多半是 SystemMaxUse 到了上限，更早的记录被回收了。可以先只读查看现有配置，不要急着改：

systemd-analyze cat-config systemd/journald.conf

关注 SystemMaxUse、SystemKeepFree 和 MaxRetentionSec 这几项现在的取值。这是查看，不建议在生产上未经评估就改小保留时间，否则排障和审计需要的历史会一起被清掉。容器宿主机上还要注意：业务进程的日志可能先进入容器运行时，对应的 unit 往往是 docker.service 或某个容器引擎服务，而不是业务自己的进程名。先用 journalctl -u docker.service -n 50 确认入口，再决定要不要进容器看应用自己的日志文件。

这三个习惯可以叠在一起用：先锁住服务和时间，再用优先级滤掉大量 info，最后在需要时用 -f 看新日志是否还在增长。比一次把几天的日志拷到本地再搜索要快，也更不容易看错时间线。下次服务异常时，可以先从这三条命令开始，而不是打开整个 /var/log。