journalctl 是结构化日志查询引擎，需组合服务（带.service后缀）、时间（推荐ago或精确时间戳）、优先级（-p）等过滤器精准定位根因，配合JSON输出、高亮、导出等功能提升排查效率。
journalctl 不是日志“查看器”，而是结构化日志的“查询引擎”。它能从海量系统事件中，按服务、时间、级别、进程等维度精准抓取异常线索，关键在于用对过滤器组合——单靠 -f 或 -u 只能看见表象，叠加条件才能锁定根因。
按服务单元精准聚焦日志流
服务名必须带 .service 后缀，否则在 CentOS 8+ 或较新 systemd 版本中可能匹配失败或返回空。不加后缀（如 journalctl -u nginx）容易误判服务无日志。
- 查看某服务全部历史记录：
journalctl -u nginx.service - 只看最近一次启动期间的日志（排除旧会话干扰）：
journalctl -u mysql.service -b - 同时监控多个关联服务（如 Web 层 + 数据库）：
journalctl -f -u nginx.service -u php-fpm.service -u postgresql.service
用时间范围框定故障发生窗口
“今天”“昨天”这类相对时间虽方便，但依赖系统时钟精度；若 NTP 同步延迟或手动调过时间，--since today 实际从当日 00:00:00 开始，可能漏掉凌晨前的关键日志。建议优先使用显式时间戳或“ago”表达式。
- 查最近 45 分钟内所有异常：
journalctl --since "45 min ago" -p warning..emerg - 定位已知时间段（如用户反馈的“下午两点到三点”）：
journalctl --since "14:00" --until "15:00" - 精确到秒的时间区间（适合复盘生产事故）：
journalctl --since "2026-06-19 15:22:10" --until "2026-06-19 15:23:45"
按优先级和字段缩小排查范围
错误日志常混在大量 info 级别输出中。仅用 -p err 查全局日志，可能刷出数千行内核或驱动报错，反而掩盖业务层问题。务必与服务、时间联合使用。
- 只看 nginx 的 error 及以上日志（含 crit/alert/emerg）：
journalctl -u nginx.service -p 3 - 筛选特定进程 ID 的完整生命周期日志（如崩溃前后的上下文）：
journalctl _PID=2847 - 按程序名而非服务名过滤（适用于非 systemd 托管的二进制）：
journalctl _COMM=mysqld - 组合多条件：查 API 服务在最近一小时内发生的警告及以上错误：
journalctl -u api.service -p warning --since "1 hour ago"
实时追踪中加入高亮与结构化输出
纯文本滚动难以快速识别错误关键词。配合管道和格式选项，可让关键信息“跳出来”，也便于后续脚本解析。
- 实时跟踪并高亮 ERROR/WARN/CRITICAL 字样：
journalctl -fu nginx.service | grep --color=always -E 'ERROR|WARN|CRITICAL' - 以 JSON 格式输出（保留所有元数据，适合导出分析）：
journalctl -u docker.service -n 100 -o json-pretty - 去掉冗余字段，只显示时间+消息体（适合快速扫读）：
journalctl -u sshd.service -n 30 -o short-iso-precise - 导出为普通文本备份（避免 pager 截断）：
journalctl -u nginx.service --since "2026-06-18" --no-pager > nginx-20260618.log
