1、日志分析概述：日志的定义、作用与分类

说起日志，我觉得每个做技术的人都不陌生。说白了，日志就是系统运行过程中留下的“脚印”。代码跑了什么逻辑、报了什么错、调用了什么接口……这些信息都会被记录下来。我刚开始接手CI流程的时候，看到一堆乱糟糟的日志也头疼，后来慢慢摸出了门道。

日志的定义

日志（Log）是一种按时间顺序记录的、反映系统运行状态的消息集合。每条日志通常包含时间戳、来源组件、事件级别、具体描述等字段。一个典型的日志行长这样：

2024-09-15 14:32:10.123  WARN  [build-pipeline]  [job:compile]  Compilation time exceeded threshold: 45s > 30s

你可以把它理解成黑匣子里的飞行记录。没有日志，出问题了全靠猜。我记得有一次线上环境半夜挂了，靠的就是翻应用日志才定位到是数据库连接池耗尽——要是没日志，那晚基本别想睡了。

日志的作用

日志到底有什么用？我总结下来核心就三点：

• 故障定位：出了异常，第一时间查日志。错误栈、上下文信息都在里面。
• 性能分析：比如CI构建变慢了，查日志看每个阶段的耗时，就知道瓶颈在哪。
• 安全审计：谁在什么时间做了什么操作，日志会留下痕迹。

日志的分类

日志类型很多，但从CI失败归因的角度，我习惯把它们分成三大类。你想想看，一个构建任务从上到下会经过多个层次：操作系统、应用框架、构建工具本身。每个层面都有各自的日志。

系统日志

系统日志记录的是操作系统级别的事件。包括内核消息、硬件错误、服务启停、磁盘空间告警等。在CI节点上，常见的系统日志有：

• /var/log/messages 或 /var/log/syslog：通用系统消息
• /var/log/kern.log：内核日志
• journalctl -u docker：Docker守护进程日志

我遇到过好几次构建突然卡死，最后查系统日志发现是磁盘写满了。嗯，这种问题不看系统日志根本想不到。

应用日志

应用日志是指你自己写的程序、框架、中间件输出的日志。比如Web服务日志、数据库慢查询日志、消息队列日志等。在CI上下文里，应用日志还可能包括：

• 单元测试框架的输出（如pytest、JUnit）
• 代码检查工具的警告与错误
• 编译器的报错信息

举个真实案例：有一次CI构建一直报莫名其妙的内存溢出，看应用日志发现是某个测试用例申请了一个超大数组。这种问题从构建工具日志里根本看不出来，必须翻应用日志。

CI日志

CI日志是持续集成平台自身输出的日志。包括流水线各阶段的执行情况、命令返回码、环境变量、缓存命中状态等。比如Jenkins的控制台输出、GitLab CI的job日志、GitHub Actions的run log。典型的CI日志内容：

[Pipeline] stage: Build
[Pipeline] { (Build)
[Pipeline] sh: npm run build
[Pipeline] } (Build)
[Pipeline] stage: Test
[Pipeline] { (Test)
npm ERR! code ELIFECYCLE
npm ERR! errno 137
npm ERR! test@1.0.0 test: `jest --coverage`
npm ERR! Exit status 137
npm ERR! 
npm ERR! Failed at the test@1.0.0 test script.
[Pipeline] } (Test)
[Pipeline] stage: Deploy
[Pipeline] } (Deploy)

可以看出来，CI日志把各个阶段串起来了，哪个阶段失败一目了然。但要注意，CI日志里的错误信息往往比较简略，真正根因可能需要再去看应用日志或系统日志。

三类日志对比

日志类型	主要来源	典型内容	CI失败分析中的作用
系统日志	OS、内核、守护进程	磁盘满、OOM、网络断开	排除基础设施问题
应用日志	业务程序、测试框架、工具链	编译错误、测试失败、超时	定位具体代码级错误
CI日志	CI平台（Jenkins/GitLab CI等）	阶段状态、退出码、缓存日志	确定失败阶段，引导排查方向

日志分类结构图

下面这张图清晰地展示了日志的分类体系以及它们在CI失败分析中的位置关系：

总结一下，日志分析的第一步就是搞清楚你在看哪种日志。系统日志、应用日志、CI日志各有侧重，配合起来才能准确找到CI失败的根因。后面几章我会具体演示怎么读、怎么搜、怎么用工具加速排查过程。记住，日志不是摆设，它是你最靠谱的侦探。