渴饮易水流你是不是也遇到过这种场景：服务半夜挂了，爬起来想查原因，第一反应打开 /var/log/messages，结果里面空空如也，或者只有几行无关痛痒的记录。我踩过一次之后，就把 journalctl 列入了新机器的必查项——准确说它不用装，只要系统用 systemd，它就在那里。journalctl 是 systemd 时代统一的日志查询命令，负责读取 systemd-journald 收集的二进制日志，把内核、服务、用户会话的日志全部汇总到一个入口。这篇内容适合所有被日志折磨过的 Linux 使用者和运维工程师，无论你跑的是服务器、嵌入式设备还是 WSL 环境，把 journalctl 用熟，排查效率能提升一个量级。
1. journalctl 查的是什么：systemd 时代统一日志入口的前因后果
1.1 从分散日志到统一收集
以前排查问题，先得搞清楚日志散落在哪。syslog 体系下，/var/log/messages 是全局消息，/var/log/secure 管认证，/var/log/cron 管定时任务，应用自己还可能往安装目录写一份 log。程序一多，排障就得玩“日志文件连连看”，有时还要靠猜。
systemd-journald 把这个局面彻底改了。只要进程通过 libc 的 syslog 接口、标准输出、标准错误、内核 printk 等方式输出日志，journald 都能捕获，并且自动附带上 PID、UID、服务名、时间戳、优先级等元数据。这些日志被写进 journald 自己的二进制日志文件里，查看入口就是 journalctl。换句话说，journalctl 不是另一个日志工具，而是 systemd 体系下日志的“统一查询窗口”。
1.2 journalctl、dmesg、/var/log/messages 三者的关系
很多人会把这三个概念混在一起，其实它们并不互斥。dmesg 读的是内核环形缓冲区，主要看内核启动阶段和驱动报错；journalctl 配合 -k 也能看内核日志，但信息量更完整，还带时间戳和元数据。/var/log/messages 这类传统文件，在 systemd 发行版里通常由 rsyslog 从 journald 转发后落盘，属于“二次加工”的产物。
| 数据来源 | 查看方式 | 特点 |
|---|---|---|
| 内核环形缓冲区 | dmesg | 只保留最近一段内核日志，重启清空 |
| journald 二进制日志 | journalctl | 全量、结构化、带元数据，可持久化 |
| rsyslog 转发的文本文件 | tail /var/log/messages | 人类可读，但丢失元数据，可能截断 |
所以当有人问“dmesg 和 journalctl 该用哪个”，我的答案是：看内核用 dmesg 没问题，但做完整排障时 journalctl 是更稳的入口，它把内核、服务、用户态日志放到了一个查询空间里。
1.3 为什么用二进制而不是明文
早期我看到 journald 的二进制日志，第一反应是“这不折腾人吗”。后来实际用下来才明白，明文日志只是看起来友好，检索多条件、多时间范围、跨服务关联时效率非常低。journald 的日志文件自带索引，元数据结构化，journalctl 在解析时能把时间范围、优先级、unit、PID 这些条件下推到索引层面，查询速度比 grep 扫文件快得多。
一个比较贴切的类比：明文日志像一堆 CSV 文件，journalctl + journald 更像一个本地数据库。查询快、字段全、权限可控，代价是需要通过工具读取。平时用没什么感觉，一旦日志量每天几个 GB，差别就出来了。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 过滤才是 journalctl 的核心价值：unit、时间、级别、启动周期怎么组合
2.1 按服务文件过滤：-u 参数
-u 是最常用的过滤方式，用来指定查看某个 systemd unit 的日志。写 nginx 还是 nginx.service 都可以，systemd 会帮你补全。
bash复制journalctl -u nginx
journalctl -u nginx -u php-fpm --since today
多个 -u 之间是“或”关系，只要命中任意一个 unit 就输出。这在排查联动问题时非常有用，比如 Nginx 和 PHP-FPM 一起查，能直接看到两个服务的日志按时间交错排列，还原调用链。
实际调试时我常把 -u 和 -f 组合使用，实时盯某个服务：
bash复制journalctl -u nginx -f
改完 Nginx 配置 reload 之后，这个命令能立刻把错误刷出来，比看 access.log 直观得多。
2.2 按时间过滤：--since 和 --until
没有时间过滤的日志查询是没有灵魂的。--since 和 --until 支持的时间写法很灵活，既可以是绝对时间，也可以是相对时间。
bash复制journalctl --since "2024-06-01 10:00:00" --until "2024-06-01 12:00:00"
journalctl --since "30 min ago"
journalctl --since yesterday
journalctl -S "1 hour ago" -U now
注意写时间记得加引号，否则容易把空格拆成多个参数。-S 和 -U 是简写，脚本里用简写更干净。
有一点很容易忽略：如果不指定日期，journalctl 会按当前日期推断。跨年、跨月的日志，最好把完整的“年-月-日 时:分:秒”写全，不然容易查空。
2.3 按日志级别过滤：-p 参数
systemd 把日志级别分成 emerg 到 debug 共 8 级，-p 后面跟级别名，表示显示该级别及更高级别的日志。
bash复制journalctl -p err -b
这条命令的意思是查看本次启动中所有 err 及以上级别的日志，也就是 err、crit、alert、emerg。日常排障最常用的是 -p warning 和 -p err，前者能多看到一些可疑警告，后者直接看硬错误。
如果你只想看 err 这一级、不要 crit 和 emerg 混进来，可以配合 grep 做二次过滤，或者用 -o json 输出后按 PRIORITY 字段精确筛选。不过大多数时候 -p err 就够用了。
2.4 按启动周期过滤：-b 参数
这是 journalctl 最惊艳的特性之一。-b 后面跟数字，0 表示本次启动，-1 表示上一次启动，-2 表示上上次，以此类推。
bash复制journalctl -b 0
journalctl -b -1
journalctl --list-boots
典型的场景是：服务上次启动时崩溃过，但现在重启后系统已经正常了。你没法复现现场，直接 journalctl -b -1 -p err 看上上次启动的错误日志，问题往往一目了然。
bash复制sudo journalctl --list-boots
这个命令会列出所有启动记录的编号、时间和日志量，确认你要查哪一次启动。
注意：如果没开启日志持久化，
-b -1大概率查不到历史启动。后面第 4 节会重点讲持久化配置。
2.5 关键字与字段级过滤：grep、_PID、_COMM
日志量大时，关键字过滤是刚需。journalctl 自带的 -g 可以在 MESSAGE 字段里做正则匹配：
bash复制journalctl -u nginx -g "connection refused"
journalctl -g "OutOfMemory"
比 grep 更好用的是字段级过滤。journald 会给每条日志附上大量元数据字段，直接拿字段名过滤就行：
bash复制journalctl _PID=1234
journalctl _COMM=nginx
journalctl _SYSTEMD_UNIT=nginx.service
字段可以任意叠加：
bash复制journalctl _SYSTEMD_UNIT=nginx.service _PID=1234 -S "1 hour ago"
这条命令能精确把某个服务某个进程在最近一小时的日志全部捞出来。进程崩溃后 PID 被回收也没关系，反正日志已经按时间归档了。
3. 输出格式与字段筛选：几千行日志里只留下你要的信息
3.1 常见输出格式对比
journalctl 默认输出是短格式，包含时间、主机名、进程、消息。日志一多，这种格式看起来还行，但想提取字段、做脚本解析就不够用了。-o 参数可以切换输出格式。
| 格式 | 说明 | 适用场景 |
|---|---|---|
| short | 默认格式，简洁可读 | 日常查看 |
| cat | 只输出消息内容，不带元数据 | 快速读日志 |
| short-iso | 时间戳为 ISO 8601 格式，适合日志收集 | |
| verbose | 显示完整结构化字段 | 排查元数据问题 |
| json | 结构化输出，每行一个 JSON 对象 | 脚本处理、jq 提取 |
| json-pretty | 带缩进的 JSON | 人工查看字段结构 |
3.2 用 jq 从 JSON 里提取字段
json 输出是 journalctl 最被低估的用法。日志量大、字段杂的时候，人类可读格式反而是噪音，机器可读格式才能帮你精准提取。
bash复制journalctl -u nginx -n 50 -o json | jq -r '.MESSAGE'
想看某条日志的所有字段，用 verbose 或 json-pretty：
bash复制journalctl -u nginx -n 5 -o json-pretty
你会看到 _PID、_UID、_GID、_HOSTNAME、_SYSTEMD_UNIT、_BOOT_ID、PRIORITY、SYSLOG_IDENTIFIER 等一堆字段。这些字段就是做故障分析的基础。
进一层，直接按字段筛选并输出你关心的列：
bash复制journalctl -p err -o json | jq -r '[.MESSAGE, ._PID] | @tsv'
把错误消息和进程 PID 对齐，几秒钟就能统计出是哪几个进程在持续报错。
3.3 分页、倒序与实时跟踪
日志内容多的时候，默认分页会让人手忙脚乱。我习惯直接在管道里用 --no-pager 关掉分页，配合 grep、head、tail 来收缩范围。
bash复制journalctl -r -n 200 --no-pager
-r 表示倒序，最新日志在最前面；-n 200 限定条数。排障时先倒序看最近 200 行，快速了解当前状态，再根据线索做时间范围过滤。
实时跟踪用 -f，跟 tail -f 类似：
bash复制journalctl -u nginx -f
journalctl -p warning -f
复现问题时，开一个终端跑 journalctl -u 目标服务 -f，另一个终端复现操作，日志会实时滚动，问题现场基本不会漏。
3.4 几个实用组合
把上面这些过滤条件串起来，就能写出很干练的查询命令。
bash复制journalctl -u mysql -p warning --since "2 hour ago" --no-pager
journalctl -g "OutOfMemory" -b -p err
journalctl _COMM=java -r -n 100
这些命令我几乎每天都会用到，建议直接存成 shell 别名，省得每次敲一长串。
4. 日志持久化与磁盘占用：默认配置下重启之后可能什么都查不到
4.1 journald 的默认存储行为
journald 的日志存储位置由 /etc/systemd/journald.conf 里的 Storage 参数控制。默认值是 auto，意思是：如果 /var/log/journal 目录存在，就用持久化模式；否则日志只写到内存中的 /run/log/journal，重启直接清空。
很多精简环境、容器镜像、嵌入式系统默认没有 /var/log/journal，这会导致一个尴尬的现实：系统一重启，之前的日志全没了。你刚想怀念上一次启动到底发生了什么，结果数据已经被内核丢进了看不见的地方。
4.2 开启持久化
开启方式很简单，编辑 /etc/systemd/journald.conf，把 Storage 改成 persistent：
ini复制[Journal]
Storage=persistent
然后重启 systemd-journald：
bash复制sudo systemctl restart systemd-journald
重启后 journald 会自动创建 /var/log/journal 目录，并把持久化模式跑起来。这里有个细节：不要手动 mkdir 之后随手 chmod 一通，权限设置不对会导致 journald 拒绝写数据。直接改配置让进程自己处理是最稳的。
改完配置后，用 journalctl --disk-usage 看一眼占用，确认日志确实落到磁盘了。
4.3 限制日志体积
日志是好事，日志过多就是灾难。journald 提供了一组配置项来控制体积，最常用的是这几个：
ini复制SystemMaxUse=500M
SystemKeepFree=1G
MaxRetentionSec=14d
RuntimeMaxUse=100M
- SystemMaxUse：journald 能占用的磁盘总上限
- SystemKeepFree：为系统其他用途保留的磁盘空间
- MaxRetentionSec：单条日志文件最长保留时间
- RuntimeMaxUse：内存中日志的上限，对应 /run/log/journal
修改后重启 systemd-journald 生效。设置逻辑是“总量优先”，同时满足的话，先淘汰最老的日志。
4.4 手动清理
不想等自动轮转，可以直接手动清理。
bash复制journalctl --disk-usage
journalctl --vacuum-size=300M
journalctl --vacuum-time=14d
第一条看当前占用，后两条分别按体积、按时间清理旧日志。
还有一条命令值得记住：journalctl --rotate。它让 journald 立即滚动当前活动的日志文件，把正在写的文件变成旧文件，方便后续 vacuum 处理。实际操作时我会先 rotate 再 vacuum，确保清理的是完整文件。
重要提醒：不要直接
rm -rf /var/log/journal/*。journald 持有文件句柄，你删了它可能继续往已经删除的文件里写，或者出现各种奇怪状态。清理日志请走 vacuum 系列命令，这是正路。
5.1 普通用户为什么看不到服务日志
journald 的日志是按访问权限隔离的。普通用户只能看到自己用户会话的日志，想查看系统服务日志，需要加入 adm 或 systemd-journal 组。
bash复制sudo usermod -aG systemd-journal 你的用户名
重新登录后，普通用户就能执行 journalctl 看系统级日志了。root 虽然没有这个问题，但日常操作我建议尽量用低权限账号，需要时再临时提权，别把 root 当日常。
5.2 时间跳变导致日志窗口错乱
journalctl 的时间过滤依赖系统时钟。如果机器时间不准，尤其是后来手动改过时间，--since "2 hour ago" 可能查出来一堆对不上的日志，或者什么都查不到。
遇到这种情况先执行 date 看一眼当前时间，再决定时间窗口怎么设。用 short-iso 格式输出能直接看到时间戳，定位时区偏差和手动调时间造成的日志间隙。
bash复制journalctl -n 20 -o short-iso
时间长期不准的话，建议用 timedatectl 把时区和自动时间同步打开，省得日志时间轴本身就是歪的。
5.3 历史启动日志缺失
journalctl -b -1 提示找不到日志，一般有两个原因：一是没开启持久化，重启后历史 boot 数据被清掉了；二是日志被自动清理策略删掉了，比如 MaxRetentionSec 设置得太短。
先用 journalctl --list-boots 看看还剩哪些启动记录，如果是空的或者只有当前一条，那就是持久化或者清理策略的问题。持久化开启后，还需要跑一阵子才会有多条 boot 记录，别刚改完配置就急着查上一启动。
5.4 日志文件损坏与验证
journald 的二进制日志文件也可能损坏，尤其是非正常关机后。journalctl 提供了一条验证命令：
bash复制journalctl --verify
这条命令会逐个检查日志文件的完整性。如果报错，说明某些文件坏了。稳妥处理方式是先备份还能读的数据，然后清理损坏文件并重启 systemd-journald，让 journald 重建索引。不要在高负载生产环境裸奔着折腾，先保证当前日志能写进去最重要。
6. WSL 真实排障：systemd 用户会话报错时如何用 journalctl 切入
6.1 报错场景
有一次我在 WSL 里启动 Linux 环境，终端直接弹出来一段提示，大意是：
text复制wsl: failed to start the systemd user session for 'root'. see journalctl for details
系统直接告诉你去查 journalctl，这正好是练习日志排查的好场景。WSL 里跑 systemd 本身就是近些年的新玩法，对虚拟化环境的很多细节依赖较高，用户会话启动失败是很典型的问题。
6.2 从 journalctl 切入的完整排查链路
第一步，先看本次启动中错误级别的日志，排除明显问题：
bash复制journalctl -b -p err --no-pager
如果输出里没有直接暴露根因，就缩小范围，看 systemd 用户管理器本身。root 用户的 uid 是 0，对应的 unit 是 user@0.service：
bash复制journalctl -b -u user@0.service --no-pager
如果是普通用户，则是 user@1000.service 之类。
第二步，看 systemd-logind 的状态，因为用户会话由它管：
bash复制journalctl -b -u systemd-logind -p warning --no-pager
第三步，查 dbus。systemd 用户管理器依赖 dbus 做进程间通信，dbus 没起来，用户会话很容易失败：
bash复制journalctl -b -u dbus -p warning --no-pager
三条命令跑下来，问题一般就浮出水面了。我记得那次的问题是 dbus 启动时序偏晚，导致 user manager 首次连接失败，重试几次失败后就放弃了。用 journalctl -f 同时重新触发一次用户会话，能看到失败发生在哪一步，比盯着静态日志瞎猜要快得多。
6.3 从这次 WSL 排障沉淀出的通用思路
这次折腾给我的收获是：journalctl 不是靠一两个命令打天下，而是一套组合拳。先 --list-boots 确认看哪一次启动，再用 -b -p warning 快速扫错，然后用 -u 锁定具体 unit，最后用时间过滤和 -f 实时复现。
如果你在 WSL 里遇到 systemd 相关报错，除了用 journalctl 定位，也要留意 WSL 本身的版本，老版本对 systemd 的支持不完整，更新到较新版本往往能解决一部分兼容问题。遇到用户会话失败，先别急着重装环境，日志里基本都写着原因呢。
我个人现在养成的习惯是：任何 Linux 疑难杂症，第一反应先去查 journalctl，而不是翻各种配置文件。先看日志，再动手改东西，能省掉大量无效操作。journalctl 用熟练之后，排查问题的思路会从“到处乱翻碰运气”变成“按图索骥有理有据”，这是它最值得花时间学会的地方。