服务一报警，第一反应就是翻日志，可很多人卡在「知道要查日志，不知道敲哪条」：日志文件几百兆，tail 刷得飞快，grep 出来的东西看不懂，容器里的日志又不在服务器上。这篇不堆命令手册，只讲日常排障真正用得上的几条命令，每条说清什么时候用、什么情况下不适用，最后给一个从「确认日志在哪」到「缩小时间窗」的排查顺序。
服务一报警，第一反应就是翻日志。但很多人卡在第一步：知道要查日志，不知道敲哪条命令。有人上来就 tail -f，结果屏幕滚得飞快什么都看不清；有人 grep 一个大词，出来几千行，越看越懵；还有人跑到服务器上翻了半天，才发现日志根本不在那台机器上。
这篇不堆命令手册，只讲日常排障真正用得上的几条命令。每条说清楚什么时候用、什么情况下不适用，最后给一个从「确认日志在哪」到「缩小时间窗」的排查顺序。命令本身很简单，难的是知道该用哪条。
先确认日志在哪，再谈命令
敲命令之前，先花十秒确认日志文件在哪。路径找错了，后面命令再熟也是白费。常见位置就三类：应用自己在项目里建的 logs 目录、操作系统统一的日志目录、以及容器或进程管理器接管的输出。先去项目文档、启动脚本或者环境变量里找路径。
- 前台运行
- 进程直接跑在终端里，日志可能只打印在屏幕上，没落到文件
- systemd 托管
- 日志被系统服务接管，要去取对应服务单元的日志流，而不是翻磁盘文件
- 容器运行
- 日志通常是标准输出，由容器运行时保存，本地目录里可能只有空文件
文件太多不知道看哪个，先按修改时间排序，找最近还在写入的那个。然后确认日志有没有按天或按大小切分：切分过的日志，跨零点的请求会断在两个文件里，只看当天那个就会漏掉前半段。这个问题在排查跨天故障时特别容易踩。
实时盯：日志还在刷的时候看什么
服务还在运行、你想知道「现在正在发生什么」，就用跟随输出的方式盯住文件尾部。这是值班时最高频的动作，也是新手最先学会的命令。它适合确认服务有没有活着、有没有持续报错、某次操作有没有立即触发异常。
用法上有两个细节。只想确认服务在动，看末尾几十行就够；想抓一次具体请求，得先准备好触发操作，再盯住输出，否则那几行刷过去就找不回来了。盯的时候可以配合过滤，只看关心的关键词，避免满屏噪音。
- 服务刚重启，盯启动过程有没有报错，看几十行就能判断
- 手动触发一次请求，盯住输出确认链路走通了
- 排查偶发问题，盯住过滤后的关键词，等它复现
- 交接班时快速确认服务当前有没有在持续刷错误
什么情况下不适用：日志量很大的服务，别挂着一直刷。屏幕滚得比眼睛快，关键行根本抓不住。这时候更好的做法是把输出重定向到临时文件，事后再慢慢翻。另外，只想看历史某一段的话，跟随输出毫无意义，直接去搜更快。
缩小范围：按关键词和时间把人捞出来
有了报错关键词或者请求 ID，用文本搜索在文件里过滤，这是从几百兆日志里定位一条记录最快的方式。搜索的关键是选对关键词：优先用请求 ID 这类全局唯一的串，其次用具体的报错码，最后才考虑用错误级别这种泛词。
| 搜索关键词 | 适合场景 | 不适用的情况 |
|---|---|---|
| 请求 ID | 追踪一次请求跨多个模块的完整链路 | 请求 ID 没打进日志，或者被截断了 |
| 报错码 | 定位某一类明确的异常 | 不同错误共用一个码，分不清来源 |
| 错误级别泛词 | 粗略看整体有没有报错 | 日志量大时会被大量无关行淹没 |
| 时间串前缀 | 先把范围缩到某个小时再细搜 | 日志格式里时间不在行首，匹配不到 |
时间范围大的时候，先把日志按时间段切出来再搜，比在整个文件里搜快得多，尤其是文件几百兆的时候。反过来，如果一次请求跨了多个服务，得挨个服务的日志都搜同一个 ID，只搜一个服务容易得出片面结论。
容器和托管环境：命令换一套
日志被进程管理器或容器接管时，文件可能根本不在磁盘上。这时候要去取对应运行单元的日志流，再配合文本过滤看。思路和前面一样：先确认运行单元，再拿到日志流，最后按关键词或时间筛。
- 确认运行单元先查清楚服务是哪个容器、哪个服务单元、哪个进程在跑，名字对不上就拿不到日志
- 取日志流从对应运行单元拉出日志，注意带上时间范围参数，否则拉出来的是全部历史
- 过滤和定位在拉出的日志流里按请求 ID 或报错码筛，筛不到就放宽时间范围再试
- 确认副本多副本部署时，先确认是哪台机器、哪个副本出的问题，逐个查而不是只看一个
什么情况下不适用：如果日志已经集中收进了日志平台，本地命令只能看到最近一段，历史查询要去平台里按条件筛。另外，容器重启后旧日志可能已经丢了，想留证据得提前配置持久化，而不是出事之后再想办法。
查不到日志时的排查顺序
命令敲了、路径也对了，就是查不到想要的内容，这时候别反复换命令，按固定顺序排查更省时间。下面这个顺序从最常见的原因开始，逐条排除。
- 第一步确认服务在写：日志级别是不是被调高了、输出是不是被关掉了、是不是根本没触发到那行代码
- 第二步确认路径和时间段：你打开的目录、文件名、时间范围，跟问题发生的时间对不对得上
- 第三步确认权限：能看到文件但读不出内容，多半是当前账号没有读权限，换个账号或提权再试
- 第四步确认保留策略：问题发生在一段时间之前、而日志保留天数很短，文件可能已经被轮转删掉了
- 第五步确认是否分散在别处：日志被集中收集或分片存储时，本地文件只是其中一部分
按这个顺序走，大部分「查不到日志」都能落到某一步上，比漫无目的地换命令有效得多。如果排查完发现是日志配置本身的问题，那要解决的是采集和保留策略，而不是查询命令。
另外，不同环境、不同服务的日志格式差异很大，具体怎么过滤、保留多久、平台里怎么筛，可以到站内相关页面核对当时的口径和配置说明，别拿别的项目的经验直接套。
下一步命令会敲只是第一步，知道在哪个环境用哪套、结果怎么核对，才是排障效率的差别。站内整理了常见环境的日志位置对照和查询口径，建议对照自己手上的服务过一遍。→常见问题
服务报错了，我应该先敲哪条命令？
先别敲命令，先确认日志文件在哪、服务是不是还在写。位置确定后，用跟随输出盯住文件尾部，同时手动复现一次问题，看新刷出来的那几行里有没有报错。如果刷得太快看不清，就把输出存到临时文件，再用文本搜索按请求 ID 过滤。
为什么我搜关键词什么都搜不到？
常见原因有三个：日志级别设置得比较高，你找的那类信息压根没被记下来；你看的是切分后的当前文件，而问题发生在切分之前的那个文件里；或者服务把日志输出到了别处，比如容器或日志平台，本地文件是空的。按这三个方向各查一遍。
日志文件太大，打开就卡死怎么办？
不要用全量编辑器打开几十上百兆的文件。养成几个习惯：只看文件尾部若干行、用文本搜索先过滤、按时间列先缩小范围再往下看。需要反复分析时，先把关键片段截出来存成小文件，后续操作都在小文件上做。
