📚 课程目录第3章日志分析入门

日志分析入门：如何读取构建日志，关键信息定位

日志这东西，说实话很多刚入行的同学都不太在意。觉得构建失败了，看最后几行报错就行。我早年也这么干过，结果有一次排查了整整三个小时，最后发现错误信息其实在日志中间——被一大段警告信息给淹没了。从那以后，我才真正开始认真对待日志分析这件“小事”。

先搞清楚日志都藏在哪

不同CI工具日志存放位置不太一样。我习惯先检查几个常见位置：

控制台输出：CI平台网页上直接能看到，但刷新后可能丢失。
工作目录下的日志文件：比如 build.log、test-output.log，一般在项目根目录或 logs/ 下。
代理节点日志：如果你用 Jenkins 或 GitLab Runner，代理端也会生成详细日志，有时比Web界面更精确。
Docker容器日志：很多构建在容器里跑，可以用 docker logs <container_id> 捞出来。

小技巧：直接在 CI 管道配置里加一行 cat /path/to/build.log 把日志打印到输出，省去翻工件的麻烦。

快速定位错误，我常用的三板斧

拿到日志先别急着全文阅读。我一般这么干：

grep 关键字：

grep -n -i "error" build.log
grep -n -i "failed" build.log
grep -n -i "fatal" build.log

带上 -n 显示行号，方便回头查上下文。

查看最后 50 行：很多工具的错误摘要会出现在尾部。
```
tail -n 50 build.log
```

用 vim 或 less 上下翻：

less build.log
# 按 Shift+G 跳到末尾，按 ?error 向上搜索

注意：有些构建工具会把错误信息拆成多行，单纯 grep "error" 可能漏掉。我建议同时搜 "Exception"、"trace"、"stack" 等关键词。

常见错误模式与关键字速查表

整理了一份我常用的对照表，碰到对应关键字能快速定位问题类型：

错误关键字	常见原因	优先排查方向
ERROR: Job failed (exit code 1)	脚本命令非零退出	查看上一条命令的详细输出
FATAL: unable to access ‘...’	网络/认证/仓库不存在	检查.git-credentials或网络代理
No such file or directory	路径写错或文件未生成	确认工作目录、缓存策略
OutOfMemoryError / Disk quota exceeded	资源不足	提高构建机配置或清理缓存
Segmentation fault (core dumped)	程序崩溃，常与内存泄漏有关	查看前后代码变更，回滚测试

上下文分析：别只看报错那一行

找到 "error" 行之后，我通常会往上看至少 20~30 行。为什么呢？因为很多工具会在真正报错之前打印警告或状态信息。有一次我在 Jenkins 日志里看到 "ERROR: Connection refused"，以为数据库挂了，折腾半天才发现前面有个警告说 "Max connections reached"，其实是连接池满了。如果只看报错行，永远找不到根因。

我个人习惯用 sed -n '100,150p' build.log 或 awk 'NR>=100 && NR<=150' build.log 来截取报错行附近的区域，然后逐行浏览。你想想看，有时候错误信息里会附带着文件路径和行号，比如：/src/main.js:25: Uncaught TypeError，这时候你就能直接定位到源码位置了。

几个实战案例，帮你理解

案例1：Node.js 构建失败

日志末尾一堆 "Module not found: Error: Can't resolve...". 我一开始以为是 npm 没装好，后来发现错误行前面有 "Treating warnings as errors because of --fail-on-warnings"，其实原因是在 webpack.config.js 里配了 failOnErrors: true。解决：去掉这个配置或修好警告就好了。

案例2：Docker镜像构建超时

Jenkins 日志里出现 "Timeout after 10 minutes"，但所有步骤看起来正常。我往上翻了几百行，发现有一条 "RUN pip install -r requirements.txt" 卡在下载某个大包上。最终方案：更换国内镜像源，并把基础镜像换成轻量版。

避坑指南

我踩过不少坑，分享两个最常见的：

忽略行号偏移：当你用 grep -n 找到行号后，再用 tail -n +100 时，行号可能因为日志里有空行而错位。我建议每次用 vim 或 less 直接定位，不要机械地加减行号。
小心并发日志混淆：并行任务会把日志交错打印，看起来像乱码。解决办法是给每行加时间戳或任务ID，或者用 ts '[%Y-%m-%d %H:%M:%S]' 格式化输出。

提效工具：我常用 lnav 命令（Log File Navigator），能自动识别不同格式的日志并着色，还支持 SQL 查询。不过记得先安装一下。

好了，日志分析其实没那么玄乎。核心就是：先定位，再看上下文，最后关联源码或配置。你不妨下次构建失败时，按这个流程走一遍，会比瞎猜快很多。