journalctl 日志排查：按服务、启动记录和时间定位故障
服务刚刚重启过，错误却发生在上一次系统启动中；搜索 error 没结果，也不代表程序没有失败。Ubuntu 24.04 的 journalctl 可以按服务、启动记录和时间筛选 systemd 日志。下面从一个已知故障时间出发，建立可重复的排查过程，不涉及直接删除或清空日志。
先确定系统、服务和时间口径
记录服务器名称、应用服务名、故障发生的时间与时区。客服反馈的北京时间、服务器显示的 UTC 和浏览器本地时间可能指向同一时刻，应先换算后查询。排错时不急着修改服务器时钟，否则新的记录会更难对齐。
在服务器执行 timedatectl status 和 journalctl --list-boots。后一条列出当前可见的启动记录，帮助判断事件属于本次还是上次启动。没有列出旧启动，不应马上认定系统从未重启，也可能是旧日志没有持久保存。
从窄时间窗读取完整上下文
假设已确认故障发生在 UTC 某段时间，可执行：
# Ubuntu 服务器；日期和服务名均需替换
sudo journalctl -u demo.service --since '2026-09-05 01:00:00 UTC' --until '2026-09-05 01:15:00 UTC' --utc -o short-iso --no-pager
先看完整时间窗，确认程序启动、依赖连接、错误和退出的顺序，再缩小到具体事件。只过滤某个错误词容易漏掉前面的配置加载和后面的重试结果。--utc 统一输出显示，short-iso 让跨系统对照更清楚。journalctl 手册提供筛选与输出选项的定义。
如果服务没有把输出交给 journal，而是自行写文件，还需要读取对应应用日志。系统日志和业务请求日志各有信息，不能期待一个工具覆盖全部链路。
分别看当前启动、上次启动和内核
常见的只读查询包括：
sudo journalctl -b -u demo.service -n 100 --no-pager
sudo journalctl -b -1 -k --no-pager
sudo journalctl -u demo.service -f
第一条看本次启动中该服务的最近记录；第二条看可用的上次启动内核日志；第三条持续观察新日志，按 Ctrl+C 退出查看，不会停止服务本身。-b -1 只有旧启动日志确实保存时才有意义。
内存终止、磁盘错误等可能出现在内核记录，而数据库查询异常更可能在应用日志中。把两个来源按时间对齐，比先猜某一种原因更容易发现关联。分享日志前遮盖令牌、密码、完整请求参数和不宜公开的内部地址。
优先级筛选是辅助，不是完整结论
可以使用 -p warning 查看警告及更严重级别，但应用如何标记优先级取决于日志接入方式。某些程序把报错作为普通文本写到标准输出，级别筛选可能不会把它选出来。因此先读取故障窗口的全部内容，再用级别或文本缩小范围。
输出中若出现限流、消息被抑制或丢弃提示，要意识到日志并不完整。没有某条记录，可能是没有发生，也可能是没有保留或没有采集；两者需要额外证据区分。不要把“搜不到”直接写进复盘作为根因已经排除的证明。
为下次复盘安排保留与导出
journalctl --disk-usage 可以了解 journal 占用，但本文不建议为排障先做清理。需要交接时，将已经确认的时间窗导出到受控目录，保留命令、时区与主机信息。只导出截图通常不利于搜索和关联，文本或结构化导出更易复核。
重启后是否保留日志，与 journald 的存储设置、实际目录以及清理策略有关。Storage=auto 并不保证每台服务器都持久保存，需结合现场配置判断。journald 配置手册说明了存储模式、空间限制和速率限制。
如果需要改变保留策略，先评估磁盘预算和敏感信息范围，在维护流程中备份配置再实施。本次故障排查应先保护证据；把日志收集与容量计划落实后，下一次才不会只能依赖一次重启后的猜测。