journalctl 入门：用 systemd 日志快速定位服务异常

服务启动失败时，先找到相关记录，比直接重启更有价值。journalctl 用来查询 systemd journal；它能展示写入 journal 的服务输出和系统事件，但并不保证收集应用自行写入普通文件的全部日志。下面按“单元、时间、级别、上下文”的顺序整理查询方法，不涉及修改服务配置。

一、确认服务名称与查询范围

先看服务状态，核对单元名、退出原因和最近记录，再取一段较完整的日志。myapp.service 只是占位名称，应换成机器上的实际单元。

systemctl status myapp.service --no-pager
journalctl -u myapp.service -b -n 100 --no-pager

-u 限定单元，-b 默认限定本次启动，-n 限制最近行数，--no-pager 直接输出而不进入分页器。状态查询显示的几行日志可能被截断，不能把它当作完整故障过程；服务正在运行，也不等于业务请求一定正常。

二、固定时间窗口，保留现场

先用 date 核对主机时区，再按故障发生时间取一个前后都有余量的窗口。下列时间按主机本地时区解释，不应未经核对就套用到另一台服务器。

date
journalctl -u myapp.service --since "2026-11-07 09:00:00" --until "2026-11-07 10:00:00" -o short-iso --no-pager

优先使用带日期的绝对时间，便于稍后重复查询。应用日志里的时间也可能使用另一时区，关联请求时要先统一口径。以下仅为虚构的日志形态示意，不是运行命令得到的真实结果。

2026-11-07T09:15:00+0800 host myapp[1234]: configuration file missing

这条示意信息提示应检查配置路径，但不能单凭一行就认定根因，还要查看之前的加载过程和之后的退出记录。

三、提高级别后仍要看上下文

journalctl -u myapp.service -b -p err -n 50 --no-pager
journalctl -u myapp.service -f -n 20

单独指定 err 会包含该级别及更严重的记录，包括 crit、alert 和 emerg。过滤后没有结果并不意味着没有故障：应用可能把异常写成普通级别，或根本没有把日志送进 journal。此时去掉级别过滤，回到时间窗口查看上下文。

-f 持续跟踪新增记录，适合在另一个终端观察问题复现过程；用 Ctrl+C 停止跟踪不会停止服务。不要为制造日志而对生产环境反复执行危险请求。

四、查不到旧日志时检查什么

journalctl --list-boots
journalctl -b -1 -u myapp.service --no-pager
journalctl --disk-usage

上一次启动的日志是否可查，取决于保留策略及是否存在持久化记录。Storage=volatile 使用易失存储；Storage=auto 等配置的行为还与目录条件有关，不宜仅凭目录存在与否下结论。普通用户也可能受权限限制，应按管理规范获取必要的读取权限。

磁盘占用查询只用于观察，不需要顺手清理。日志轮转、容量上限和保留时间都可能让历史记录消失，排障前先导出必要片段并脱敏。把查询范围写清楚，区分“没有记录”和“服务没有出错”，才能让日志成为可靠证据。

查询结果要连同单元名、主机时区、启动批次和筛选参数一起保存，否则别人很难复现同一范围。对外提供片段前，应遮盖访问令牌、用户标识及敏感请求内容，同时保留必要的时间顺序和错误上下文，避免脱敏后失去排障价值。