journalctl 可可靠追踪 systemd 服务状态变化，提供启动、停止、失败等完整上下文，支持按 MESSAGE、_COMM 等字段精准过滤，并需启用持久化存储以满足合规审计要求。

journalctl 本身不提供“审计”意义上的行为追踪（比如谁执行了哪条命令），但它能可靠追踪系统服务的状态变化——这是合规审计中“服务可用性”和“变更管理”的核心证据来源。

服务启停与状态变更的精准捕捉
journalctl 记录每次 systemd 单元状态切换的完整上下文，包括启动、重启、失败、停止等事件。它不是简单打个时间戳，而是记录：

• 服务单元加载时的依赖检查结果
• ExecStart 执行前的环境准备（如用户权限、工作目录）
• 进程实际 fork 和 exit 的 PID 及退出码
• 失败时附带的错误原因（例如 Failed to start nginx.service: Unit nginx.service not found 或 Process exited, code=exited, status=1/FAILURE）

这类日志可直接用于验证：

• 关键服务（如 sshd、auditd、nginx）是否按计划运行或被人为干预停止
• 定时任务（.timer 单元）是否准时触发，及其后续 .service 是否成功执行
• 服务重启是否由配置变更触发（配合 --since 查看变更后首次启动日志）

用关键字段快速定位状态变更
不用翻全文，靠结构化字段过滤即可聚焦：

• 查所有服务启动尝试：journalctl MESSAGE="Starting *" -p info
• 查所有服务失败记录：journalctl MESSAGE="Failed to start *" -p err
• 查某服务最近三次状态变更：journalctl -u postfix.service --since "3 days ago" | grep -E "(Starting|Started|Stopping|Stopped|Failed)"
• 查服务被手动 stop 的操作来源：journalctl _COMM=systemctl | grep -i "stop.*postfix"

结合时间线还原变更过程
单次服务异常往往不是孤立事件。例如数据库服务启动失败，可能源于网络未就绪或磁盘空间不足。这时需横向比对：

• 先锁定失败时间点：journalctl -u mariadb.service --no-pager | head -n 20
• 再查该时刻前后其他关键服务状态：journalctl --since "2026-07-08 14:22:00" --until "2026-07-08 14:25:00" -p err
• 特别关注 network.target、local-fs.target 等基础目标单元是否 ready

持久化是审计可用的前提
若日志仅存于 /run/log/journal，重启即丢，所有状态变更记录归零。生产环境必须：

• 创建落盘目录：sudo mkdir -p /var/log/journal
• 启用持久存储：在 /etc/systemd/journald.conf 中设 Storage=persistent
• 设定保留策略：SystemMaxUse=500M + MaxRetentionSec=90d，避免磁盘满或证据过期

journalctl 对服务状态的追踪不依赖应用层日志，也不受服务自身是否写 log 文件影响——只要它由 systemd 管理，其生命周期就自动留下不可篡改的时间证据链。