journalctl 实时监控 systemd 单元日志的核心是按服务单元查询而非文件路径，直接从 journald 二进制库中结构化拉取带元数据的日志，支持 -u、-p、--since、_PID 等参数精准过滤与定位。
journalctl 实时监控 systemd 单元日志，核心在于把“服务”当作查询维度，而不是去找文件路径。它不依赖 /var/log 下的文本日志，而是直接从 journald 的二进制日志库中按单元名、时间、优先级等结构化字段实时拉取数据——这意味着你看到的每一条日志都自带 _SYSTEMD_UNIT、_PID、PRIORITY、_HOSTNAME 等元数据，天然支持精准定位。
按服务单元实时追踪
用 -u 参数指定服务名，是最常用也最可靠的起点：
- 实时盯住 nginx：`journalctl -f -u nginx`（.service 后缀可省略）
- 同时监控 Web 层与数据库：`journalctl -f -u nginx -u postgresql -u app.service`
- 查看某服务本次启动后的全部日志（排除历史干扰）：`journalctl -b -u sshd`
聚焦关键信息：优先级过滤
生产环境日志量大，只看 error 及以上能大幅减少噪音：
System Monitor
下载
跨平台系统监控工具，支持 Linux 和 Windows，监控硬盘、内存、CPU 使用情况，记录历史数据，支持变化对比和预警。**适合定时任务**。触发场景：(1) 定时系统健康检查（推荐每6小时），(2) 用户询问系统状态、资源使用情况，(3) 资源异常预警，(4) 查看历史监控数据对比。
- 只显示错误和警告：`journalctl -f -u docker -p err..warning`
- 锁定严重问题（emerg 到 crit）：`journalctl -f -u kubelet -p 0..2`
- 排除 info 和 debug，保留问题线索：`journalctl -f -u redis -p 0..3`
限定时间范围，避免滚动疲劳
已知故障发生时段？直接切片，不用翻屏找：
- 最近 10 分钟的 MySQL 错误：`journalctl -u mysql --since "10 minutes ago" -p err`
- 精确到秒的时间段：`journalctl -u httpd --since "2026-07-06 20:15:00" --until "2026-07-06 20:22:30"`
- 配合重启时间快速回溯：`journalctl -b -1 -u nginx`（上一次启动的日志）
结合结构化字段做上下文排查
单靠 MESSAGE 不够，出错时往往需要进程、用户或主机维度交叉验证：
- 查某个 PID 的全部日志（比如从 systemctl status 中拿到的主进程 ID）：`journalctl _PID=2847`
- 查特定用户启动的服务：`journalctl _UID=1001 -u myapp`
- 查某台主机上的服务行为（适合多节点集群）：`journalctl _HOSTNAME=web-prod-03 -u nginx`
- 组合条件精确定位：`journalctl _SYSTEMD_UNIT=app.service PRIORITY=3 _PID=3210`
默认输出带分页，按 / 可搜索关键词；加 --no-pager 便于管道处理，比如 `journalctl -f -u nginx | grep "502"`；导出 JSON 格式用于脚本解析：`journalctl -u nginx -n 100 -o json`。真正高效，是每次执行都带着明确目标，而不是盲目滚动。
