journalctl -f 是可组合、可聚焦的动态追踪机制，需过滤前置、目标明确、响应及时：锁定单元、按优先级筛选、限定本次启动、支持带上下文回溯。
精准服务级实时追踪
服务异常时，全量日志噪音太大。直接锁定目标单元，避免信息淹没：
- 监控单个服务：
journalctl -f -u nginx（自动匹配nginx.service） - 同时观察上下游：
journalctl -f -u app.service -u postgresql.service -u redis.service - 确认服务名是否正确：先运行
systemctl list-units --type=service | grep your_service
错误优先的实时流
多数故障初期表现为 ERR 或 WARNING 级别日志。加 -p 过滤能大幅减少干扰：
- 只看错误和严重警告：
journalctl -f -u app.service -p err..warning - 聚焦崩溃级事件：
journalctl -f -p 3（3 = err，含 emerg/alert/crit/err） - 配合时间戳增强可读性：
journalctl -f -u app.service -p err -o short-precise
本次启动内实时捕获崩溃线索
系统或服务突然退出、内核 oops、coredump 等，往往发生在当前会话中。用 --this-boot 锁定上下文：
- 通用崩溃关键词流：
journalctl --this-boot -f -p 3 | grep -i -E "(panic|oops|segfault|aborted|coredump|killed process)" - 纯内核视角（更安静）：
journalctl --this-boot -f -k | grep -i "panic\|oops\|BUG:" - 注意：
--boot=0和--this-boot等价，但后者语义更清晰、兼容性更好
带上下文的实时回溯
发现异常后，常需往前翻几条日志看前因。follow 模式支持预加载行数：
- 实时滚动，同时显示最近 100 行：
journalctl -f -u app.service -n 100 - 结合时间范围启动：
journalctl -f -u app.service --since "5 min ago" - 退出后可立即查历史：
Ctrl+C后直接接journalctl -u app.service -n 20快速复盘
