Linux 日志排查三板斧

遇到 Bug 先别慌，日志里藏着答案。

作为测试工程师，你不会天天写 shell 脚本，但你一定会有需要自己翻日志的时候。

开发甩一句"看下日志"，环境出了问题没人管，线上 Bug 复现了要你查根因。这时候 Linux 日志排查就是你的救命技能。

这篇不讲废话，三个命令覆盖 90% 的排查场景。

第1斧：tail -f — 实时盯梢，抓现行

你在测某个功能，操作完以后日志瞬间刷过去了，来不及看。

别慌，提前开一个终端窗口跑：

tail -f /var/log/app/application.log

这时候你再去操作，日志会实时滚动出来，一行都跑不掉。

加点料：

# 只看最近 200 行，然后持续盯tail -200f /var/log/app/application.log# 多个日志一起盯（适合排查关联问题）tail -f /var/log/app/error.log /var/log/nginx/access.log

贴士：开两个终端窗口，一个跑 tail -f，一个跑测试操作。两边对照着看，效率翻倍。

第2斧：grep — 大海捞针，精准定位

日志已经刷过去了，或者文件非常大（几百 MB），你要找到跟某个请求相关的所有记录。

# 基本搜索：找包含 ERROR 的行grep "ERROR" /var/log/app/application.log# 忽略大小写grep -i "timeout" /var/log/app/application.log# 显示匹配行前后各 5 行（查上下文的关键）grep -C 5 "订单ID: 123456" /var/log/app/application.log# 递归搜索整个目录（不知道日志在哪个文件时）grep -r "NullPointerException" /var/log/app/

测试专用组合拳：

# 查某个请求的全链路日志grep "trace_id=abc-123-def" /var/log/app/application.log# 统计某个错误出现次数grep -c "Connection refused" /var/log/app/application.log# 输出：23# 只显示文件名和匹配行数grep -rc "ERROR" /var/log/app/

贴士：测试环境查 Bug 时，先让开发加上 trace_id，你测的时候记下 ID，后面 grep 一把梭，全链路日志秒出。

第3斧：journalctl — systemd 日志专用

服务是 systemd 管理的，或者你看不到应用日志文件在哪，只能查系统日志。

# 查看某个服务的日志journalctl -u myapp.service# 只看最近 50 行journalctl -u myapp.service -n 50# 实时跟踪（相当于 systemd 版的 tail -f）journalctl -u myapp.service -f# 只看某个时间段的日志journalctl -u myapp.service --since "2025-01-01 10:00:00" --until "2025-01-01 12:00:00"# 只看 ERROR 级别journalctl -u myapp.service -p err

贴士：journalctl 默认日志量很大，一定要加 -u 指定服务名，否则你会被淹没。

实战组合技

光会单个命令不够，上组合拳。

场景1：查"下单失败"的原因

# 1. 先搜到相关时间点grep "下单失败" /var/log/app/biz.log# 2. 看那段时间上下游发生了什么grep -C 10 "下单失败" /var/log/app/biz.log | grep -E "ERROR|WARN|下单"# 3. 实时复现一遍tail -f /var/log/app/biz.log | grep --line-buffered "下单"

场景2：服务挂了，查原因

# 1. 看 systemd 日志journalctl -u myapp.service -n 100 -p err# 2. 再看应用自己的日志最后 200 行tail -200 /var/log/app/application.log# 3. 有没有 OOMgrep -i "out of memory|killed" /var/log/messages

场景3：接口响应慢，查调用链

# 找到慢请求的 trace_idgrep "接口耗时" /var/log/app/api.log | awk -F '|' '$4 > 3000 {print}'# 拿着 trace_id 去全链路搜索grep "trace_id=xxx" /var/log/app/*.log

速查表

写在最后

这三板斧看着简单，但真的够用。

遇到问题不要急着找开发，先自己翻一遍日志：

1. tail -f 实时盯，看得到发生时是什么样子
2. grep 精准搜，从历史中找到证据
3. journalctl 兜底，systemd 的日志也不怕

会看日志的测试，Bug 单里自带根因分析，开发看了都不敢喷。

觉得有用？点个「在看」分享给身边的测试小伙伴吧 👇