journalctl 是可定位、可追溯、可联动的系统日志管理工具，需持久化配置、上下文过滤、例行监控及适配输出格式。
journalctl 不是“多一个命令”，而是把日志从散落的文本文件，变成可定位、可追溯、可联动的系统状态快照。用得好，故障响应时间能从小时级压缩到分钟级；用得随意，它和 tail -f 没本质区别。
日志必须持久化，否则等于没记
默认情况下，journald 只把日志存在内存（/run/log/journal），重启就清空。这在排查偶发性问题或夜间告警时毫无价值。
- 创建持久化目录并设权限：sudo mkdir -p /var/log/journal && sudo chown root:systemd-journal /var/log/journal && sudo chmod 755 /var/log/journal
- 修改 /etc/systemd/journald.conf，确保含这两行：
Storage=persistent
SystemMaxUse=500M（根据磁盘容量调整） - 重启服务生效：sudo systemctl restart systemd-journald
查日志要带上下文，不能只盯一行
单看一条 error 日志常无法定位根因。规范做法是：按服务 + 时间 + 级别三要素组合过滤。
- 例如查 SSH 登录失败，不只 grep “Failed”：journalctl -u sshd --since "2 hours ago" -p err
- 查某次服务异常，先定位时间点，再拉取前后 30 秒完整链路：journalctl -u nginx --since "2026-06-14 14:22:00" --until "2026-06-14 14:23:00"
- 关键服务建议加 -o verbose，显示 PID、UID、_SYSTEMD_UNIT 等字段，便于关联进程与配置单元
日常监控要有固定节奏，不是出事才打开
把 journalctl 当成“系统听诊器”，纳入例行巡检，比救火更有效。
- 每日早间运行：journalctl --since yesterday | grep -E "(failed|error|timeout)" | head -20，快速扫一遍异常苗头
- 关键服务（如数据库、API 网关）开启常驻监控：journalctl -u postgresql -f --since "5 minutes ago"，新日志一出立即可见
- 每周执行一次容量检查：journalctl --disk-usage，确认未超配额，避免静默丢日志
输出格式要适配用途，别全堆在终端里
人眼读、脚本解析、归档审计，对日志格式要求完全不同。
- 人工排查用 -o short-precise（精确到毫秒）或 -o verbose（字段全展开）
- 导出给开发分析或做统计：journalctl -u nginx -o json-pretty > /tmp/nginx_logs.json
- 对接 ELK 或 Loki 等平台，直接用 -o json 流式输出，不加美化
- 禁止长期用 --no-pager 输出海量日志到终端——容易卡死、丢失内容、无法回溯
