服务出错先看哪段日志：按时间窗口定位，而不是贴出全部记录

服务报错以后，最常见的求助方式是复制最后一行，或者上传几十兆日志。前者缺少上下文，后者容易淹没真正的原因，还可能泄露访问令牌和个人信息。更实用的方法是围绕一次明确失败，提取一段足够短、又能看到前因后果的记录。

本文只讨论自己有权管理的服务。示例命令读取日志，不会修复服务；它们也不代表作者在你的机器上执行过。

先记下故障发生的四件事

在重新启动服务之前，记录：失败时间及所在时区、当时做了什么、实际错误表现、刚刚发生过哪些变更。浏览器页面的时间、服务器时间和容器记录未必一致，不能把相同钟点直接当成同一个时刻。

例如，与其写“今天下午不能用了”，不如写“北京时间 16:20 左右上传一个小文件，网页返回错误；同一分钟普通页面仍可打开”。这不是结论，却能明显缩小检索范围。

使用 systemd 的 Linux 系统，可以把下面的服务名和时间替换为实际值：

journalctl -u example.service --since "2026-11-04 08:15:00 UTC" --until "2026-11-04 08:25:00 UTC" --utc --no-pager

这里输入使用 UTC，输出也明确使用 UTC，避免跨时区混淆。-u 针对指定服务；日志是否可见取决于用户权限和系统保留设置。如果需要查看本次启动，可另用 -b 缩小范围，但重启前的故障不能因此被排除。journalctl 官方手册

不要一开始只筛选最高严重等级。有些关键线索是普通信息，例如服务读取了哪个配置、连接到了哪个地址、何时重新加载。先看小范围的完整上下文，再进一步筛选。

docker logs --since "2026-11-04T08:15:00Z" --until "2026-11-04T08:25:00Z" --timestamps example-container

这些时间筛选选项见 Docker logs 命令参考。example-container 是占位名称。排查近期连续输出时，可以先用 --tail 200 控制数量；但截取末尾会漏掉更早的故障，不能代替覆盖完整事件窗口。

Docker 的日志通常来自容器主进程的标准输出和标准错误。如果应用把信息写入内部文件，或者日志驱动采用其他存储方式，docker logs 可能没有你需要的内容，应检查该应用和日志驱动的配置，而不是推断它没有出错。Docker 日志说明

一次连接失败可能引出超时、重试、请求取消等多行记录。最后一行不一定是起因。把相同请求标识附近的记录放在一起，比较一次成功与一次失败：输入是否相同，响应耗时是否变化，配置加载是否发生在前面。

不要仅凭一条包含 error 的行就下结论，也不要为了验证猜想同时修改五项设置。每次只改变一个有依据的条件，保留变更前后的日志片段，才能知道改动是否真的有效。

删除或替换密码、令牌、Cookie、授权头、带签名的下载地址，以及无关个人资料。保留时间顺序、错误码、软件版本和必要的路径结构。同一敏感值应替换成同一占位符，便于别人理解关联。

不要把日志直接上传到不熟悉的公开分析网站。截图也需要检查地址栏、终端历史和周围窗口。脱敏副本用于交流，原始记录在受控位置保留，便于后续自己核对。

它应包含失败动作、时间窗口、环境版本、预期与实际结果、经过脱敏的前后文，以及已经尝试的单项变更。修复后用原来触发失败的小操作复测，并检查同期日志没有重复异常。

这样的记录既方便他人协助，也会成为下次同类故障的参考。日志的价值在于回答一个具体问题，而不是收集得越多越好。