journalctl 通过字段属性实现精准日志匹配，而非全文 grep；每条日志为结构化键值对，支持按 _SYSTEMD_UNIT、PRIORITY、_PID 等字段索引查询，并可组合布尔逻辑筛选。
journalctl 的字段属性是精准匹配日志的核心，不是靠“grep 全文搜”，而是像查数据库一样按字段索引筛选。每条日志本质是一个键值对集合，比如 _SYSTEMD_UNIT=nginx.service、PRIORITY=3、MESSAGE=connection refused——这些字段自带语义和结构，直接参与查询逻辑。
查看所有可用字段
系统实际记录了 50+ 个元数据字段，但常用约 15 个。快速列出当前日志中出现的所有字段名：
journalctl -o verbose | head -20 | grep -E '^__\w+=' | cut -d= -f1 | sort -u- 更简洁方式：
journalctl --fields（systemd v245+ 支持） - 权威参考：
man systemd.journal-fields，里面标注了每个字段是否可索引、是否支持通配、是否用户可控
关键字段及匹配逻辑
以下字段在排障中最常组合使用，注意它们的匹配行为差异：
-
_SYSTEMD_UNIT=：匹配服务单元名，支持精确匹配或通配符（如
_SYSTEMD_UNIT=nginx*），自动包含该 unit 的 coredump 和 systemd 内部事件 -
PRIORITY=：取值 0–7，支持范围写法（如
PRIORITY=3..5表示 err/warning/notice），不支持字符串如PRIORITY=err（那是-p err的语法） - _PID= 和 _UID=：整数精确匹配，适合定位某次请求、某个用户会话下的完整调用链
-
MESSAGE=：仅匹配原始日志内容，**不支持正则**；想用正则必须用
--grep（它只作用于 MESSAGE 字段，且是 PCRE2 引擎） -
_COMM= 和 _EXE=：分别对应进程命令名（如
sshd）和绝对路径（如/usr/sbin/sshd），比单纯看 SERVICE 更底层、更防伪装
多字段组合与布尔逻辑
journalctl 默认是 AND 关系，空格分隔即表示“同时满足”：
-
journalctl _SYSTEMD_UNIT=redis.service PRIORITY=2 _UID=1001→ 只看 redis 服务中由 UID 1001 触发的 crit 级别日志 - 用
+显式连接多个条件（等价于空格）：journalctl _PID=1234 + _COMM=python3 - OR 逻辑无法原生实现，需靠外部工具：
journalctl _SYSTEMD_UNIT=a.service _SYSTEMD_UNIT=b.service是 AND（即同时属于 a 和 b，不可能）；正确写法是journalctl -u a.service -u b.service，这是 systemd 特殊处理的 OR 语义
实战建议：从模糊到精准的三步走
- 先缩小时间范围：
--since "10 min ago"或-b（当前启动），避免扫描全量日志拖慢响应 - 再锁定主体：
-u myapp.service或_SYSTEMD_UNIT=myapp*，比grep myapp不易误匹配日志正文 - 最后加约束条件：
PRIORITY=3、_PID=、--grep "timeout|EOF"，把噪声压到最低
字段匹配不是技巧，而是 journalctl 区别于传统日志工具的根本能力。用对字段，一次查询就能替代多次 grep + awk + sed。
