服务器出问题先别慌：三条命令看懂 Linux 日志

服务器上的服务突然连不上了，新手最常见的反应是反复重启——重启完好了，过两天又挂，周而复始。其实绝大多数问题，日志里都写着答案。学会看日志，排查效率至少翻三倍。今天只讲三条命令，够你应付八成场景。

第一条：journalctl，系统服务的"黑匣子"
用 systemd 管理的服务（Nginx、Docker、SSH 都是），日志都进了 journal。看某个服务的最近 50 行日志：
journalctl -u nginx --no-pager -n 50
服务起不来时，直接看它的启动日志，十有八九写着原因，比如端口被占用、配置文件写错了行号。加上 -f 就变成实时跟踪，和 tail -f 一个效果：
journalctl -u docker -f
新手常犯的错是只看"服务状态"，不看"服务为什么是这个状态"。systemctl status nginx 下面其实就附了最近几行日志，养成顺手扫一眼的习惯。

第二条：tail -f + grep，应用日志的黄金组合
应用自己的日志一般在 /var/log/ 或项目目录下。出问题时先看"尾部"——最新发生的错误一定在文件最后：
tail -n 100 /var/log/nginx/error.log
想实时盯着错误冒出来，就用：
tail -f /var/log/nginx/error.log | grep -i error
grep -i 是忽略大小写过滤，日志刷得再快，只看含 error 的行。这里有个实用技巧：加 --line-buffered 避免输出延迟，不然实时跟踪时日志会"攒一波再吐"。

第三条：按时间缩小范围，别在大海里捞针
日志文件动辄几万行，全文翻等于没看。用时间过滤，只看故障发生前后那几分钟：
journalctl -u nginx --since “2026-10-24 06:00” --until “2026-10-24 06:30”
普通文本日志就用 grep 配时间戳：
grep “2026-10-24 06:1” /var/log/app.log
这个写法会匹配 06:10 到 06:19 的所有行。先知道"什么时候出的事"，再去看"那个时间点发生了什么"，排查立刻有了方向。

一套固定的排查顺序
建议新手把这个顺序背下来，形成肌肉记忆：

1. 先看时间：服务什么时候开始异常的？systemctl status 或监控告警里都有。
2. 看服务日志：journalctl -u 服务名 --since 故障时间前后 10 分钟。
3. 看应用日志：tail -n 看尾部，或 grep 搜 error/exception/fail 关键词。
4. 搜关键词：拿到报错信息里最独特的一句，去搜——八成有人踩过同样的坑。

三个新手坑
第一，别只看最后一行。致命错误上面往往还有一串 warning，那才是真正的起因。报错是"结果"，warning 是"病因"。
第二，日志级别别乱调。有人为了排查把日志级别开到 debug，磁盘两天就被写满。排查完记得调回去，生产环境 info 级别通常够用。
第三，记得日志轮转。/var/log 下的 .gz 文件是轮转后的旧日志，“昨天这个时候出过问题"要去旧文件里找，zgrep 可以直接搜压缩包，不用先解压。
日志不会骗人，它只会等你去看。下次服务再出问题，先别急着重启，花五分钟按这个顺序看一遍——你会发现，所谓的"玄学故障”，大多在日志里写得明明白白。