📚 课程目录第4章日志管理与分析

日志管理与分析：日志级别、关键信息抽取、ELK 初步

日志，说白了就是 CI 运行时的「黑匣子」。任务跑没跑过、挂在哪里、为什么挂，全藏在里边。我刚开始做 CI 运维时，经常对着几万行日志眼冒金星——后来才明白，不是日志太多，是我不懂怎么管。

这一章咱们就聊聊日志管理的三个核心问题：该记什么（级别）、怎么捞干货（抽取）、往哪存怎么查（聚合）。

日志级别：CI 里的信号灯

日志级别这东西，平时没人关心，出事的时候它就是救命稻草。我个人习惯在 CI 脚本里至少分三级：INFO 记正常流程，WARN 记异常但不阻断，ERROR 记导致失败的根因。DEBUG 级别嘛，只在调试 CI 自身问题时才打开，不然日志量能把你吓到。

你想想看，如果所有输出都混在一起，找一个真正的失败原因就像大海捞针。所以第一步就是定规矩——不同级别用不同前缀，日志框架自带的标准级别直接用就行。

级别	CI 中的含义	建议操作
`DEBUG`	调试跟踪，细节过多	默认关闭，按需开启
`INFO`	任务步骤、版本、耗时	保留全部，用于追溯
`WARN`	资源不足、重试、降级	标记并聚合统计
`ERROR`	断言失败、编译错误、超时	立即告警，触发通知

经验之谈：我在一个大型项目中见过团队把 DEBUG 日志全量输出到 CI 控制台，结果一次构建产生 80 万行日志，浏览器直接卡死。后来强制规定：INFO 以上才输出到终端，DEBUG 写文件归档。流畅多了。

关键信息抽取：从海量日志里捞针

日志有了级别，但光靠眼睛看还是不行。尤其是在回归测试中，几百个用例的 ERROR 混在一起，你得知道哪个是环境问题、哪个是代码问题、哪个是偶发超时。

我的做法是——用正则表达式或 Grok 模式把关键字段「抠」出来。比如测试结果中的 PASSED / FAILED、执行耗时、失败断言行号，这些都是核心指标。

举个例子，一条典型的测试日志：

2025-03-20 14:23:11 ERROR [test_login] assertion failed: expected 200, got 403 | duration=2.3s

我想从里面抽四个字段：时间、级别、用例名、失败原因。用正则写起来很简单：

^(?P<timestamp>\S+\s\S+)\s+(?P<level>\S+)\s+\[(?P<case>\w+)\]\s+(?P<message>.*?)\s*\|\s*duration=(?P<duration>\S+)

要是用 ELK 里的 Grok，写法更接近自然语言：

%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} \[%{WORD:test_case}\] %{GREEDYDATA:message} \| duration=%{NUMBER:duration:float}s

小技巧：Grok 模式在 Kibana 的「Grok Debugger」里可以实时测试。我曾经花了一下午手写正则，最后发现 Grok 一行搞定——嗯，工具用对，事半功倍。

日志聚合工具：ELK 栈初步

单机看日志还行，一旦 CI 任务分散在多台机器、多个流水线里，你就需要一个统一的「日志中心」。ELK 栈（Elasticsearch + Logstash + Kibana）是目前最主流的方案。

Elasticsearch：存得住，查得快

它负责把日志变成索引。说白了就是建一个「日志仓库」，按照时间、级别、用例名等字段建好索引，查询时毫秒级返回。我个人习惯把索引按天切分，比如 ci-logs-2025.03.20，方便过期清理。

Logstash：管道工

Logstash 负责从各种源头（文件、TCP、Kafka）收日志，做过滤、转换，再发给 ES。你可以在这里用 Grok 做关键信息抽取，也可以把 IP 地址转换成地理位置，或者把时间戳统一格式化。

一个极简的 Logstash 配置长这样：

input {
  beats {
    port => 5044
  }
}

filter {
  grok {
    match => { "message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:level} \[%{WORD:test_case}\] %{GREEDYDATA:message}" }
  }
  date {
    match => [ "timestamp", "ISO8601" ]
  }
}

output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
    index => "ci-logs-%{+YYYY.MM.dd}"
  }
}

Kibana：可视化面板

数据进了 ES，Kibana 就是你的「仪表盘」。我习惯在 Kibana 里建三个视图：

实时流视图：展示最近一小时的 ERROR 日志，自动刷新
趋势视图：按天统计失败用例数量，观察回归稳定性
Top N 视图：找出出现次数最多的错误信息，优先解决

实战效果：我曾帮团队搭建了一套 ELK，把 8 条流水线的日志统一索引。原来排查一个失败要翻 3 个页面、耗时 15 分钟；现在直接在 Kibana 搜索 ERROR + 用例名，5 秒定位到根因。效率提升就是这么直观。

避坑指南

说几个我踩过的坑，你遇到了可以直接绕过：

日志乱序：多任务并发写同一个文件时，时间戳可能错乱。解决方案是每行日志前面带精确到毫秒的时间戳，ES 按时间戳排序，别信文件写入顺序。
索引膨胀：CI 日志量通常很大，不控制索引数量会把 ES 撑爆。我设置了保留 30 天的策略，超期自动删除。
Grok 性能：复杂的 Grok 模式在 Logstash 里会拖慢吞吐量。我的做法是——在 Logstash 里只做必要字段抽取，全文搜索留到 Kibana 里做。

特别注意：千万不要把 CI 日志直接输出到 Elasticsearch 而不做任何过滤。我曾经见过有人把 DEBUG 日志全部索引，一天产生 200GB 数据——查询速度从秒级变成分钟级。记住：先过滤，后存储。

日志管理这件事，说白了就是「定级别、抽关键、聚一处」。做到这三点，CI 回归结果再也不是一团乱麻，而是清晰可查的「证据链」。下一回你的流水线挂了，打开 Kibana 搜一下就知道了——嗯，那感觉挺爽的。