journalctl 检索技巧：按时间、服务与优先级过滤

发布时间:2025-11-13 20:12

systemd 体系的日志统一收进 journald，journalctl 是它的正式入口。原始输出冗长，一次未过滤的查询动辄滚出几千行，真正的排查价值全在过滤条件的组合上。以下条目按日常使用频率排列，两三个条件叠起来，就能把检索范围缩小到可人工阅读的量级。 ## 高频过滤参数 - 按服务：journalctl -u nginx 只看该 unit 的日志，-u 可以重复出现，同时盯多个服务 - 按时间窗：--since "2025-01-01" --until "2025-01-02 03:00"，也接受 yesterday 与 "1 hour ago" 这类写法 - 按优先级：-p err 只看错误及以上，等级从 debug 到 emerg 共八档，应急时先扫 err 以上 - 倒排与截断：-r 让最新记录排在前，-n 100 只取一百行，两者常一起用 - 持续跟踪：-f 等价于 tail -f，配合 -u 可以盯单个服务的实时输出 - 输出控制：--no-pager 去掉分页器，方便重定向与脚本处理 ``` journalctl -u myapp --since "1 hour ago" -p err -n 50 --no-pager ``` 上面这条把服务、时间、优先级与条数组合在一起，是应急排查的常用形态：先缩小范围看错误，再退掉优先级过滤往回翻完整上下文，定位效率比整段翻页高一个量级。另有 -b 只看本次开机以来的日志，-b -1 则看上一次开机周期，重启前后的问题对比全靠它；-k 专看内核消息，配合使用能快速区分是服务问题还是系统层问题。检索到可疑记录后，用 --since 把时间窗收窄到分钟级再完整输出，上下文就足够判断因果了。 ## 持久化与导出 journald 默认把日志放在内存里，重启即丢，历史问题就没法回查。需要留存时打开持久化，把 /etc/systemd/journald.conf 里的 Storage 改为 persistent，重启服务后日志落到磁盘目录，也可以直接建目录后重启。 ``` mkdir -p /var/log/journal systemctl restart systemd-journald ``` 导出时加 -o json 可以把结构化字段一起带出去，交给脚本做统计与告警分析；长期留存的场景配合日志轮转控制磁盘占用，别让 journald 独占整块数据盘。在顺云上做长期问题排查时，建议提前开启持久化，并让控制台的监控告警曲线与日志时间窗互相印证，先定时段再查日志，比盲目翻页高效得多。