journalctl 是排查系统故障最直接有效的工具，通过时间、服务、级别三个维度精准切片日志：用 --since/-b 等过滤时间范围，-u 指定服务单元，-p 控制日志级别，支持多条件叠加与结构化导出。
排查系统故障时，journalctl 是最直接有效的工具——它不依赖分散的日志文件，而是从 systemd 日志总线中实时提取结构化记录。关键不在“看全”，而在“精准切片”：用对时间、服务、级别三个维度，几秒就能锁定问题源头。
按时间范围快速圈定故障窗口
多数故障有明确发生时段，盲目翻全量日志效率极低。journalctl 的时间过滤既支持相对表达，也兼容绝对时间戳：
- 查最近一小时动态（适合刚告警的场景）：journalctl --since "1 hour ago"
- 聚焦今天凌晨起的全部事件：journalctl --since today（注意：它等价于当日 00:00:00，若需更准，建议显式写完整时间）
- 精确定位某次重启后的行为：journalctl -b（当前启动），journalctl -b -1（上一次启动）
- 回溯指定分钟数，避免信息过载：journalctl --since "45 min ago"
按服务单元精准隔离日志源
一个服务器常运行数十个服务，混看日志等于大海捞针。-u 参数必须配合 .service 后缀才稳定生效：
Giga Coding Agent
下载
一款AI工具，主要用于通过后台进程运行 Codex CLI、Claude Code、OpenCode 或 Pi Coding Agent，实现程序化控制，适合需要提升相关任务效率的用户。
- 只查 nginx 启动与运行全过程：journalctl -u nginx.service
- 实时观察 sshd 是否在登录时异常退出：journalctl -u sshd.service -f
- 同时追踪 Web 层与数据库层：journalctl -u nginx.service -u mysql.service -f
- 确认某服务是否曾失败启动：journalctl -u docker.service --since "2 hours ago" | grep -i "failed\|start.*error"
按优先级和关键词聚焦关键线索
错误日志往往淹没在 info 级别输出中。用 -p 可快速收窄范围，再结合 grep 做语义强化：
- 只显示 error 及以上（err/crit/alert/emerg）：journalctl -p 3（数字 3 对应 err）
- 连 warning 一起纳入（如配置弃用、连接超时）：journalctl -p 4
- 组合使用更实用：journalctl -u php-fpm.service -p 3 --since "30 min ago"
- 高亮错误词并分页浏览：journalctl -u apache2.service -f --no-pager | grep --color -E '500|timeout|refused' | less -R
多条件叠加还原故障现场
单一维度常不够，真实问题需交叉验证。journalctl 支持字段级组合，例如：
- 查某个进程 PID 在崩溃前 10 分钟的所有行为：journalctl _PID=2947 --since "10 min ago"
- 定位特定程序名（非服务名）的日志，如 sudo 或 kernel：journalctl _COMM=sudo
- 同时满足服务 + 错误级别 + 时间段：journalctl -u kubelet.service -p 2 --since "15 min ago"（-p 2 表示 crit 及以上）
- 导出结构化日志供后续分析：journalctl -u nginx.service -o json --since "1 hour ago" > nginx_error.json
