journalctl 的检索能力
systemd-journald 以结构化字段保存日志，journalctl 可以按单元、时间窗、优先级和任意字段过滤。相比纯文本日志，它的优势在于每条记录都带 _COMM、_EXE、_PID、_UID、_SYSTEMD_UNIT、_AUDIT_SESSION 等元数据，可以用 -o json 输出后按字段精确筛选，不必依赖正则表达式去猜格式。日志是否长期保存取决于 Storage 配置：默认可能只存在内存（/run/log/journal），重启后即丢失。
基本信息
| 适用平台 | 使用 systemd 的 Linux 发行版（RHEL 7+、Ubuntu 16.04+、Debian 9+ 等） |
|---|---|
| 常用过滤 | -u 单元、--since/--until 时间窗、-p 优先级、-b 指定启动、-k 内核消息 |
| 字段过滤 | 直接写 FIELD=值，如 _COMM=sudo、_PID=1234、_SYSTEMD_UNIT=sshd.service |
| 输出格式 | -o short / short-precise / json / json-pretty / cat / verbose |
| 查看字段值 | journalctl -F <字段名> 列出该字段出现过的取值 |
| 持久化 | 由 /etc/systemd/journald.conf 的 Storage 决定，persistent 才写入 /var/log/journal |
典型使用场景
- 按单元查服务日志：某个服务在特定时间窗内的启动、报错与重启
- 按字段查操作来源：某账号、某进程执行了什么
- 用 --since/--until 精确定位时间窗，避免翻大量输出
- 用 -o short-precise 获得微秒级时间，便于与文件时间对齐
- 导出 json 供脚本处理，提取字段做统计
- 确认日志是否持久化：如果只在内存中，重启后证据将消失
检索示例
检索示例
# 指定单元与时间窗（时间按本地时区解释）
journalctl -u ssh --since '2026-01-01' --until '2026-01-02' | tail -50
# 按进程名过滤，带微秒时间戳便于与文件时间对齐
journalctl _COMM=sudo -o short-precise -n 20
# 结构化输出，字段齐全，适合交给脚本处理
journalctl _COMM=sudo -o json-pretty -n 5
# 列出某字段出现过的所有取值，先摸清字段再写条件
journalctl -F _COMM | head -30
# 指定某次启动（0 为本次，-1 为上一次），用于排查重启前后
journalctl -b -1 -p err --no-pager | tail -30
# 确认日志占用与持久化位置
du -sh /var/log/journal 2>/dev/null; journalctl --disk-usage常用字段读法
| 字段 | 含义 | 判读要点 |
|---|---|---|
| _COMM | 进程名（comm） | 易被伪装，关键判断要结合 _EXE |
| _EXE | 可执行文件路径 | 比 _COMM 可靠，可直接核对是否被替换 |
| _PID/_UID | 进程号与用户 ID | 把同一进程的多条记录串起来看 |
| _SYSTEMD_UNIT | 产生日志的单元 | 定位服务级问题最直接 |
| _AUDIT_SESSION | 审计会话号 | 与 auditd 记录关联时可复用 |
| MESSAGE/PRIORITY | 消息正文与优先级 | 用 -p 过滤可先看错误级别 |
时间窗参数使用本地时区。跨主机对比或与流量日志比对前，先确认各主机的时区设置，必要时统一换算到 UTC 再比较。
默认配置下日志可能只保存在内存目录，重启即丢。处理安全事件时先确认 Storage 设置与 /var/log/journal 是否存在，再决定是否立刻导出（journalctl --output=export 或直接打包日志目录）。
磁盘占用受限时旧日志会被自动清理（SystemMaxUse 等参数）。需要保留证据时把相关条目导出为文件，而不是依赖日志本身长期存在。