云服务器上排查 Linux 服务故障的 journalctl 实用方法

云服务器上跑着的 Linux 服务突然没响应时，很多人第一反应是重启。重启有时能恢复，但也会把现场清掉，下次还是不知道原因。更稳妥的做法是先用 journalctl 把日志看清楚。

先确认服务还在不在

如果服务是 systemd 管理的，先看状态：

systemctl status 服务名

重点看 Active 一行是 active、inactive 还是 failed，以及最后几行日志。如果是 failed，通常已经有退出码或错误原因。

看最近一段时间的日志

journalctl -u 服务名 -n 100 --no-pager

• -u 指定服务
• -n 100 只看最近 100 行，避免一次翻出太多
• --no-pager 直接打到终端，方便复制

如果只想看今天或最近一小时：

journalctl -u 服务名 --since "1 hour ago" --no-pager
journalctl -u 服务名 --since today --no-pager

也可以按时间范围查：

journalctl -u 服务名 --since "2026-11-11 09:00:00" --until "2026-11-11 10:00:00"

先过滤错误，再回头看上下文

日志很多时，先看错误和告警：

journalctl -u 服务名 -p err..alert --since today --no-pager

-p 是优先级。找到可疑时间点后，再把该时间前后的全部日志调出来，往往比一直盯着 error 更能发现真正触发点，比如配置重载失败、磁盘只读、依赖的端口没起来。

需要观察现场时再跟踪

如果问题还在发生，可以跟踪实时日志：

journalctl -u 服务名 -f

复现一次操作，看同一时刻出现了什么。查完用 Ctrl+C 结束，不要长时间占着会话不管。

几个常见坑

• 日志为空：有的服务没把日志交给 journald，还在写自己的文件，比如 /var/log/ 下的应用日志，两边都要看。
• 时间不对：云服务器时区或 NTP 没校准，会对齐错时间窗口。先确认 timedatectl。
• 权限不够：普通用户可能看不到全部系统日志，必要时用有权限的账号查询。
• 磁盘满了：journald 或应用写不进日志时，服务表现会很奇怪。先看 df -h 和 journalctl --disk-usage。

把一次故障的时间、命令和关键日志片段留下，比单纯重启更有价值。下次再出现同类问题，也可以先从同一类错误关键字查起。