Linux日志排查实战

线上出了Bug找不到原因？测试必学的Linux日志排查方法

为什么测试必须会Linux日志排查？

面试官问"Linux水平怎么样"，真正想问的是："线上出了Bug，你能不能登录服务器，从海量日志里快速定位到问题原因？"

这篇文章不讲枯燥的命令大全，只教你日志排查的实战方法。零基础也能看懂，全程有解释。

前置知识：日志在哪？怎么看？

日志文件通常在哪？

• • 系统日志：/var/log/
• • 应用日志：项目自己的 logs/ 目录下
• • 具体路径开发或运维会告诉你

怎么查看日志内容？

cat app.log      # 查看完整文件（适合小文件）less app.log     # 分页查看（适合大文件，空格翻页，q退出）tail -n 50 app.log   # 只看最后50行

日志长什么样？

2026-05-11 14:23:15.321 [http-nio-8080-exec-3] INFO  OrderController - 请求接口:/api/order/create 用户ID:10001 响应时间:235ms2026-05-11 14:23:18.654 [http-nio-8080-exec-5] ERROR PaymentService - 调用支付异常: connection timeout traceId=abc123xyz

一条日志一般包含：时间戳 + 日志级别 + 类名 + 具体内容。

第一板斧：精准定位——从海量日志中找到你需要的部分

线上日志文件动辄几百MB甚至几GB，全量打开等于自杀。先学会缩小范围。

技巧1：按时间定位

# 查找14:20到14:25之间的日志grep "2026-05-11 14:2[0-5]" app.log# sed截取精确时间段sed -n '/2026-05-11 14:20/,/2026-05-11 14:25/p' app.log

技巧2：按关键字定位

# 搜索ERROR，并显示前后各5行（看上下文）grep -A 5 -B 5 "ERROR" app.log# -A 5：匹配行之后5行  -B 5：匹配行之前5行# 同时搜索多个关键字（"或"的关系）grep -E "ERROR|Exception|Timeout" app.log# 排除干扰信息grep "ERROR" app.log | grep -v "BusinessException"# grep -v 是排除匹配的行，这里只保留非业务异常的ERROR

技巧3：按请求链路追踪（关键技能）

现代系统一个请求可能经过好几个微服务。靠**traceId（追踪ID）**可以把整个链路串起来。

# 从一个报错中提取traceIdgrep "ERROR" app.log | grep -oE "traceId=[^ ]*"# 假设找到traceId是abc123，追踪全链路grep "traceId=abc123" app.log | sort

兼容性说明： 上述 grep -oE 是通用写法。如果你的系统支持Perl正则（Linux原生GNU grep），也可以用 grep -oP，但macOS等BSD系统不支持 -P 参数。-E 在所有系统均可使用。

第二板斧：实时监控——盯着日志复现Bug

有些Bug是偶发的，等你发现时日志已经滚过去了。需要实时监控。

tail -f app.log                    # 实时刷新最新日志tail -f app.log | grep "ERROR"# 实时只看ERRORtail -f app.log error.log          # 同时监控多个文件

实战操作流程：

1. 1. 打开终端，输入 tail -f app.log，终端会持续刷新
2. 2. 用浏览器去操作那个有Bug的功能
3. 3. 观察终端里实时刷出的日志
4. 4. 看到异常信息后，按 Ctrl+C 停止

第三板斧：统计分析——从海量日志中找规律

不是所有问题都能靠一两行日志解决，有时需要做宏观统计。

统计HTTP状态码分布：

# 返回内容类似：4523个200，156个404，23个500grep -oE 'HTTP/1\.[01]" [0-9]+' access.log | awk '{print $2}' | sort | uniq -c | sort -nr

找出报错最多的接口：

grep "ERROR" app.log | awk -F '接口[: ]''{print $2}' | sort | uniq -c | sort -nr | head -10

注意： 以上 awk -F '接口[: ]' 的分隔符（冒号或空格）需要根据你实际的日志格式调整。每套系统的日志格式不同，请先看几行日志确认分隔符再写命令。

按分钟统计请求量（发现流量突增时间点）：

awk '{print substr($1,1,16)}' access.log | uniq -c

实战案例：三分钟定位一个线上故障

场景：运营反馈，首页刷不出来，转圈十几秒后报错。

Step 1：确认事发时间问清楚："什么时候开始的？" 答：大概14:20左右。

Step 2：锁定时间段内的异常日志

sed -n '/2026-05-11 14:20/,/2026-05-11 14:25/p' app.log | grep "ERROR"

返回十几条 connection timeout 错误。

Step 3：看错误详情

grep "connection timeout" app.log | tail -20

超时都发生在调用"商品详情服务"和"推荐服务"时，超时时间统一5秒。

Step 4：统计影响范围

grep "connection timeout" app.log | awk -F '调用''{print $2}' | sort | uniq -c

输出：商品详情服务35次，推荐服务28次，用户服务仅2次。

Step 5：推断根因商品详情和推荐服务同时超时，说明它们共享的公共依赖（同一个数据库或Redis缓存）出了问题。用户服务正常，说明不是整体瘫痪。

拿着这些信息找后端："14:20左右，商品详情和推荐服务同时大量超时，看起来公共依赖的数据库或缓存出现瓶颈，请检查连接池配置和慢查询。"——五分钟完成故障定位。

提升排查效率的四个思维习惯

1. 1. 先缩时间范围，再找异常内容：确定了Bug发生的精确时间，搜索才有意义
2. 2. 关联而不是孤立：看到error时，同时看CPU、内存、网络是否有异常，多信号交叉验证
3. 3. 积累自己的命令库：把常用grep/awk/sed组合存成文档，出问题时复制粘贴稍作修改
4. 4. 看不懂就问开发：日志里有不认识的错误信息，截图问一次学一次，几个月后你就是团队定位问题最快的人