Journald

有效的 journal 查询应该选出能够回答具体事故问题的记录。单元身份、运行实例、时间、优先级和应用字段提供了不同维度；正确组合它们，比在整台机器的历史里找到一个熟悉词语更重要。journald 可以附加进程元数据，但不会自动收集应用写出的每个文件，也不会自动理解每条消息的业务含义。查询条件和日志实际采集路径必须相互对应。 不同字段按 AND 组合，同字段多个取值按 OR 组合，独立 + 将条件组按 OR 连接。在原文首次运行示例中，-p err 选择 API 的二、三级，而 PRIORITY=3 只选三级。单元身份比一次运行实例更宽。空输出可能是成功查询，不证明事件未发生。本图不新增运行验证结论。 坏掉的样子 字段匹配有明确的布尔组合规则：不同字段之间是 AND，同一字段的多个取值之间是 OR，单独一个 + 则把两组条件按 OR 连接。因此，再添加一个字段值，有时会扩大结果集，而不是进一步缩小。应把查询看成一个明确的条件表达式，先用已知记录验证它，再放进事故脚本，避免因为“参数更多了”就误认为结果必然更精确。 -p err 选择错误及更严重的级别，并不是只选择数字三。如果真正需要精确的三级记录，应使用 PRIORITY=3 字段匹配。应用在文本中写了“error”，本身也不等于设置了错误优先级；标准输出的采集使用配置好的优先级规则，除非应用通过受支持的表示方式提供级别。消息文字、日志字段和筛选阈值不能互相混同。 命令成功但没有记录，不证明服务从未运行。所选启动周期、时间窗口、命名空间、读取权限、保留策略或输出路由，都可能解释空结果。反过来，查询一个单元的全部历史，又可能找到以前的成功启动，然后错误归因到当前进程。应区分服务长期身份与某一次具体运行，不能只因为单元名称相同就把证据拼接成一次执行。 快速验证 在 PID 1 为 systemd 的一次性 Linux 系统中，以管理员身份运行下面的 Python 脚本。恢复文本记载的环境为 Debian 12、systemd 252.39，但原始运行日志不可用。本轮没有执行此样例；以下结果说明其预期断言，不能视为本轮实测。脚本安装一个唯一命名的临时服务，并激活两次。每个工作进程向原生日志套接字发送四条较短的结构化消息，分别包含两个应用组件和几个明确的优先级： ...