Linux 日志排障：按时间、服务与启动记录定位线索
用日志调查 Linux 故障，应先确定受影响的服务和时刻，再收集同一启动与时区下的相关记录，与复现结果对照。单独一行 ERROR 或最后一条消息，不能证明根因；还要检查前后文和独立证据。
服务状态的基本含义可参考systemd 服务入门。这里把时间、状态与日志联系起来，再在故障复现与恢复练习（英语）中应用到受控环境。
参考环境为常规 Ubuntu 26.04 LTS 或 Rocky Linux 9 系列虚拟机；容器、WSL 和其他版本的服务与日志收集方式可能不同。先按虚拟机环境准备（英语）核对版本并准备控制台恢复。
先记录症状、时间和近期变更
把“服务器坏了”改成可检查的观察，例如“客户端 A 从 14:03 起访问 HTTPS 返回 502”。对照客户端与服务器的时钟、时区，记下最后正常时间、近期部署、配置修改和重启。将已观察到的事实与待验证的假设分开，避免根据第一条错误消息立即改配置。
date --iso-8601=seconds
timedatectl
systemctl --failed
journalctl --list-bootsdate 显示带时区偏移的当前时间，timedatectl 提供时间与同步状态，systemctl 列出失败单元，journalctl 列出可见启动记录。不同日志中的时间若采用 UTC 或本地时间，应先统一解释；否则看似先后发生的事件可能被排错顺序。
启动列表没有上一次启动，并不证明上次没有故障，可能是记录未保留、已经轮转清理，或当前权限看不到。检查本机 journald 的 Storage 和保留设置及配置覆盖：volatile 使用运行时存储，persistent 倾向持久保存，auto 还受目录等条件影响。不要仅根据默认值推断实际保留情况。
按服务、启动和时间缩小范围
把 NAME.service 换成实际故障单元。先看 status 摘要，再读本次启动的相关记录，然后缩到需要的时间窗口。有限范围的记录更便于保存和比较，避免大量无关内容淹没线索。
systemctl status NAME.service --no-pager
journalctl -b -u NAME.service --since "30 minutes ago" --no-pager
journalctl -b -p warning --since "30 minutes ago" --no-pager
journalctl -k -b --since "30 minutes ago" --no-pager-u 选择单元，-b 选择启动，-k 选择内核消息。-p warning 包含 warning 及更严重等级，即优先级数值 0 至 4，不只包含文字里写着 warning 的行。日志等级由记录方给出，应用可能标错等级，也可能把重要内容作为普通 stdout 输出。
因此，先用等级缩小范围后，还要对照同一时间窗口未加等级过滤的日志。status 摘要中的失败状态与退出码是线索，不能直接代替应用日志，也不能仅凭“最后一条”认定根因。
用 logger 查找自己生成的实验事件
下面不修改服务配置，而是发送两条带标签的练习消息。需要安装 logger，且 syslog 到 journal 的收集链路可用。受限容器或缺少日志套接字的环境可能收不到记录，先确认链路，再解释空结果。消息只包含示例文本，不要把密码或真实业务数据写入实验。
tag="linux-course-log-$(id -u)"
logger -t "$tag" "stage=start case=practice"
logger -p user.warning -t "$tag" "stage=check result=sample-warning"
journalctl -t "$tag" --since "5 minutes ago" --no-pager找到两条消息及时间，再在最后的 journalctl 命令中加入 -p warning 比较：logger 默认采用 user.notice，通常应被排除；显式的 user.warning 应保留。sample-warning 是故意生成的记录，不是真实故障。
标签包含用户 ID，便于区分账号，但同一账号重复运行会使用相同标签，五分钟窗口内可能出现多轮记录；请结合时间和消息内容辨别。即使命令正常返回，也要核对 journal 中的实际条目，不能把发送成功当作持久保存的证明。
权限不足时使用已获授权的日志读取权限。不要为了让练习出现结果而删除生产日志、放宽日志访问控制或随意重启收集服务。练习结束后也无需为删除这两条示例消息而清空整个 journal。
将消息与其他证据交叉核对
| 线索 | 进一步核对 |
|---|---|
| Permission denied | 路径所有权、各级权限与 SELinux 标签 |
| No space left on device | 目标挂载的 df -h 与 df -i |
| Address already in use | 实际端口的监听进程与重复进程 |
| Connection refused／timeout | 监听地址、路由、过滤规则与依赖服务 |
| 反复重启或失败 | 单元配置、退出状态与最近部署 |
“磁盘空间不足”可能指应用要写入的目标路径，而不是日志文件所在的磁盘；“权限拒绝”也可能源于父目录的遍历权限或安全策略，而不只是文件自身的权限。应沿消息指向的准确资源检查，不能用 root 运行或 chmod 777 掩盖症状。
一次验证只改变一个相关条件，记录变化前后的结果，再用相同请求复测。若现象恢复却没有足够证据解释原因，应保留不确定性，不能把相关性写成已证明的因果关系。
检查文件日志与保留策略
应用还可能写入 /var/log 下的文件或中央收集器。先从实际配置确认路径，再用 tail -n 100 和 grep 读取所需部分；根据需要检查轮转文件和压缩的旧记录，并统一时间格式、时区。journalctl --disk-usage 查询 journal 占用，不会替你判断该删哪些证据。
调查过程中先清理或 vacuum 日志，可能永久丢失线索。将必要区间保存在访问受限的位置，分享前遮盖令牌、Cookie、个人信息和内部地址。记录根因判断、针对性修改、相同条件复测和剩余不确定性，再按保留策略管理材料。
