journalctl 入门：用一条命令查清 Linux 服务的日志

服务器上的服务出问题时，第一反应往往是到处找日志文件：/var/log 下面一堆文件，哪个才是要看的？如果服务是用 systemd 管理的，其实不用翻目录，一条 journalctl 就能把日志按服务、按时间翻出来。

先看一个服务最近的日志。假设要查 nginx，就用 journalctl -u nginx。这里的 -u 是 unit 的意思，也就是服务名。默认会从头显示到最新，按 q 退出。只想看最近 100 行，就加 -n 100：journalctl -u nginx -n 100。想实时跟着看新日志，和 tail -f 一个意思：journalctl -u nginx -f，服务一写新日志，屏幕上马上滚动出来，排障时很顺手。

只看某个时间段的日志也很常用。比如今天早上服务重启过一次，想看今天的记录：journalctl -u nginx --since today。想看昨天下午两点到四点的：journalctl -u nginx --since “2026-10-24 14:00” --until “2026-10-24 16:00”。时间范围一缩，故障窗口立刻清楚，不用在一大段日志里翻。

日志太多时还可以按级别过滤。-p err 只显示错误及以上级别，-p warning 则包含警告。组合起来就是：journalctl -u nginx -p err --since today，先看今天的错误，定位速度快很多。

还有一个容易被忽略的点：重启后日志还在吗？这取决于 journal 的存储方式。默认不少发行版把日志存在内存里，重启就丢了；如果 /var/log/journal 目录存在，就会落盘持久保存。查一下这个目录在不在，就知道重启后还能不能翻旧账。需要长期保留的话，建好这个目录并重启 journald 服务即可，具体命令可以查发行版文档确认。

最后提醒两点。第一，journalctl 看的是 systemd 收集的日志，如果某个程序自己往文件里写日志、没经过 systemd，那还是要去看它自己的日志文件。第二，生产环境查日志先看级别和时间范围，别一上来就全量翻，范围越小，定位越快。

掌握上面这几个参数，日常排障基本够用：按服务查、按时间查、按级别查、实时跟随，剩下的就是结合报错信息本身去判断原因了。