Linux 日志排查入门：从 journalctl 到 grep/awk 的定位思路

服务器出问题时，很多人第一反应是重启服务。其实更稳的做法是先看日志：日志会告诉你服务是在哪一步停下的、是谁先报错的、以及问题是从什么时候开始的。重启可能暂时掩盖问题，却也会丢掉现场。本文用一条最常用的排查链路，讲清楚 Linux 日志怎么看、怎么定位。

一、先问三个问题，再动手

动手之前，先把范围收窄，否则日志一多就容易看花眼。

1. 影响范围：是一台机器，还是多台机器？是某一个服务，还是整台机器都慢？
2. 出问题的是哪个服务：比如 Nginx、应用进程、数据库，还是定时任务。
3. 开始时间：故障大概从几点几分开始，有没有对应一次发布、一次配置修改、一次流量突增。

把这三个问题想清楚，后面查日志就只需要看对应时间段和对应服务，不用全文翻。

二、用 journalctl 看系统服务日志

使用 systemd 管理的服务，优先用 journalctl。它按服务归类，还能按时间和级别过滤，是排查服务起不来、反复重启的首选。

# 查看某个服务的最近日志
journalctl -u nginx --no-pager -n 100

# 实时跟踪服务日志，类似 tail -f
journalctl -u nginx -f

# 只看最近一小时内、错误级别以上的日志
journalctl -u nginx --since "1 hour ago" -p err --no-pager

# 查看本次开机以来的日志，并显示精确时间
journalctl -b -o short-precise --no-pager | tail -n 200

如果服务启动后马上退出，重点看最后几行：端口被占用、配置文件写错、权限不足、依赖的目录不存在，这类原因都会直接写在日志里。先读报错原文，再去改配置，不要凭感觉改。

三、再看 /var/log 下的文本日志

不是所有日志都进 journal。很多程序仍然写文本文件，常见位置在 /var/log 下面。

# 先看哪些日志刚刚被写过，优先看时间最新的文件
ls -lt /var/log | head -n 20

# 系统日志、认证日志、应用日志各看一行示例
tail -n 100 /var/log/messages
tail -n 100 /var/log/secure
tail -n 100 /var/log/nginx/error.log

一个实用习惯是先对时间：把应用报错时间、系统日志时间、部署时间放在同一条时间轴上。如果应用在 10:24 报错，而系统在 10:23 出现磁盘只读或者内存耗尽的提示，那么根因很可能在系统层，而不是应用代码本身。

四、用 grep 先缩小，再用 awk 做统计

日志量大时，不要从头读到尾。先用 grep 按关键字和时间过滤，再用 awk 统计规律。

# 在应用日志里找错误，并显示关键词前后各 3 行
 grep -in "error" /var/log/app.log | tail -n 50
grep -n -C 3 -i "connection refused" /var/log/app.log | head -n 100

# 只看某个时间段的日志，再过滤关键字
awk '$0 >= "2026-11-09T10:20:00" && $0 <= "2026-11-09T10:30:00"' /var/log/app.log | grep -i "timeout"

# 统计最常见的报错，排在前面的往往是主要矛盾
 grep -i "error" /var/log/app.log | awk -F ':' '{print $3}' | sort | uniq -c | sort -nr | head -n 20

# 找出请求量最大的前 10 个客户端地址
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -n 10

用 grep 时注意两个细节。第一，关键字要从小到大试：先试 error、timeout、refused、denied 这类词，再试具体接口名或者订单号。第二，记得加 -n 显示行号，方便回到原文确认上下文。只看统计结果不看原文，容易把相关性当成因果关系。

五、一个能照着走的排查顺序

1. 服务状态：先看服务是不是在运行，失败了几次。

systemctl status nginx --no-pager
journalctl -u nginx --since "30 minutes ago" -p warning --no-pager

2. 时间点：锁定故障开始时间，只看前后十分钟的日志。
3. 关键字：用 grep 找 error、failed、timeout，数量最多的先看。
4. 关联验证：把报错时间与发布记录、定时任务、磁盘和内存状态对照一次。
5. 复现确认：改完配置后重启服务，再用 journalctl -f 跟踪一分钟，确认报错不再出现，才算闭环。

例如服务报连接超时，先看目标服务是否存活，再看防火墙和端口是否可达，最后再怀疑代码里的超时时间设置。顺序反过来，很容易在错误的方向上花掉半天。

六、几个常见坑

第一，日志轮转。日志文件可能已经被 logrotate 压缩成 .gz 文件，当前文件里找不到旧记录时，记得用 zgrep 查历史文件。第二，时区和时间格式不一致。有的日志用本地时间，有的用 UTC，对时间之前先确认两者是否一致。第三，磁盘满了之后日志可能停更。查不到新日志，本身就是一条线索：先看 df -h 和磁盘写权限。第四，不要在没有备份的情况下直接清理生产日志，清理之前至少先确认问题已经定位完成。

小结

Linux 日志排查并不需要记住所有命令，记住顺序就够了：先定范围和时间，再用 journalctl 看服务，用 /var/log 看系统和应用，最后用 grep 缩小范围、用 awk 找规律。把每一次排查的时间点、关键报错和验证结果记下来，下一次遇到类似问题，定位速度会明显变快。