为啥有的日志用 cat 能看，有的必须用 journalctl？

重启服务器后，为啥有的日志没了，有的还在？

排查问题时，到底该用哪个工具？

---

一、先搞懂：两个服务到底谁在干活？

很多人以为它们是「二选一」，其实是分工协作的搭档：

服务	核心定位	存储形式	擅长场景
systemd-journald	「全能采集器」	二进制数据库（带索引）	收集几乎所有系统事件（内核、启动、服务 stdout/stderr），支持高速检索
rsyslog	「分类保管员」	纯文本文件	从 journal 读取日志，按规则分类存到 /var/log 下，兼容传统日志工具

• journald 是「小区监控系统」：24 小时录下所有画面（内核、服务、启动等所有事件），存在带索引的硬盘里，想查「昨天 8 点到 9 点谁进了 3 单元」，瞬间就能调出来。
• rsyslog 是「物业档案管理员」：把监控录像按「门禁记录」「电梯故障」「消防警报」分类，整理成纸质档案（纯文本日志），方便你用 grep/less 这种传统工具翻阅。

---

二、坑：日志为啥重启就没了？

1. 默认存储位置的坑

journald 默认把日志存在内存里：

/run/log/journal

 重点：内存里的数据，服务器一重启就全没了！这也是很多人排查问题时发现「之前的日志找不到了」的根本原因 —— 默认没开持久化。

2. 怎么让日志「重启不消失」？

只需要 3 步配置持久化：

1. 编辑配置文件：

   vim /etc/systemd/journald.conf
   

2. 找到 Storage 字段，改成 persistent：

   [Journal]
   Storage=persistent
   

3. 重启服务 + 服务器（必须重启服务器才会创建目录）：

   systemctl restart systemd-journald
   reboot
   

 配置后日志会存到磁盘：/var/log/journal，重启后依然能查到历史日志。

---

三、排查问题时，到底该用哪个工具？

场景 1：查「最近 10 分钟 SSH 登录失败」

用 journalctl 更高效：

journalctl -u sshd.service --since "10 minutes ago" -p err

• -u sshd.service：只看 SSH 服务的日志
• --since "10 minutes ago"：只看最近 10 分钟
• -p err：只看错误级别日志

优势：带索引的二进制存储，过滤速度极快，不用像 grep 那样翻遍整个文本文件。

场景 2：查「半年前的系统报错」

用 /var/log/messages 更合适：

less /var/log/messages-20250327.gz

优势：rsyslog 会自动做日志轮转（logrotate），旧日志会被压缩归档，长期存储更稳定，适合回溯历史问题。

---

四、容易混淆的概念：syslog 消息 vs 非 syslog 消息

syslog 消息

• 遵循标准协议，有固定格式：时间戳 主机名 程序名[PID]: 消息内容
• 有优先级分级（emerg/alert/err/warning/info/debug）
• 会被 rsyslog 收集，存到 /var/log 下的文本文件

非 syslog 消息

• 不遵循 syslog 协议，比如：
  • 系统启动早期的内核输出（rsyslog 还没启动）
  • 服务直接打印到 stdout/stderr 的内容
  • 自定义应用的非标准日志
• 只会被 journald 收集，存在二进制数据库里，必须用 journalctl 查看

---

五、总结：

1. journald 管「全量采集 + 高速检索」，rsyslog 管「分类归档 + 文本存储」
2. 默认 journal 日志存在内存，重启就丢，必须配置 Storage=persistent 才会持久化到磁盘
3. 排查实时问题用 journalctl，回溯历史问题看 /var/log 下的文本日志