Linux日志排查故障的完整步骤，零基础也能上手
前置准备
在进行Linux日志排查故障之前，请先确认以下环境条件：
- 已通过SSH登录服务器，具有普通用户权限（部分命令需要
sudo）。 - 了解服务器操作系统版本（CentOS/RHEL使用
rsyslog，Ubuntu/Debian使用systemd-journald）。 - 常用日志目录：
/var/log/。 - 熟悉三个基本命令：
tail（查看文件末尾）、grep（搜索文本）、less（分页阅读）。
注意事项：
- 日志文件通常需要
root或adm组权限才能读取，建议使用sudo执行。 - 生产环境避免在高峰时段执行大量日志搜索，以免IO过高。
分步操作：从系统到服务排查故障
第一步：查看系统整体运行状态
首先检查系统日志中是否有明显错误。
不同发行版的系统日志文件名不同：
- CentOS/RHEL 7+：
/var/log/messages - Ubuntu/Debian：
/var/log/syslog - 现代系统也可使用
journalctl统一查看
示例命令：
# 查看最后100行系统日志（CentOS）
sudo tail -n 100 /var/log/messages
实时监控日志输出（按 Ctrl+C 停止）
sudo tail -f /var/log/syslog
关注关键词：error、failed、timeout、panic、out of memory 等。
第二步：按时间范围缩小排查区间
故障通常发生在某个时间段。
使用grep结合时间戳过滤：
# 查看今天早上8点到9点之间的日志（以messages为例）
sudo grep '2025-04-01T08:' /var/log/messages
使用journalctl按时间过滤（更推荐）
sudo journalctl --since '2025-04-01 08:00' --until '2025-04-01 09:00'
第三步：定位具体服务或进程日志
系统日志不够详细时，排查对应服务的独立日志。
常见服务日志路径：
- Nginx：
/var/log/nginx/error.log - MySQL：
/var/log/mysql/error.log - SSH：
/var/log/auth.log（Ubuntu）或/var/log/secure（CentOS） - 自定义应用：通常配置在应用目录下的
logs/或/var/log/app/
# 查看Nginx最近20条错误
sudo tail -20 /var/log/nginx/error.log
搜索SSH认证失败的IP
sudo grep 'Failed password' /var/log/auth.log
第四步：使用组合命令快速定位
对于复杂故障，将grep、awk、sort、uniq结合使用。
例如统计某个IP的访问错误次数：
sudo grep 'Failed password' /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr也可直接用less打开大日志文件，按/键搜索关键词（/error 回车），按 n 跳到下一个匹配。
避坑指南
- 日志被轮转覆盖：日志文件可能被
logrotate压缩为.gz，需用zcat或zgrep读取。示例：zgrep 'error' /var/log/messages-20250401.gz。 - 权限不足：遇到
Permission denied，记得加sudo。 - grep大小写：默认区分大小写，使用
grep -i忽略大小写。 - tail -f 占用终端：退出时按
Ctrl+C，不要直接关闭SSH，会导致后台进程残留。 - journalctl日志太多：加上
-n 50限制行数，或--no-pager避免分页卡住。
高频问题解答
问题1：日志里出现“Out of memory: Kill process”怎么办？
这表示系统内存不足触发了OOM Killer。解决方法：增加物理内存或优化应用内存使用；检查是否有进程内存泄漏，可用top或free -m实时监控。
问题2：为什么我用grep搜索不到关键字？
确认日志文件路径是否正确；检查日志是否被轮转；尝试使用zgrep搜索.gz文件；或者使用journalctl -u 服务名查看特定服务的日志。
问题3：日志文件太大，打开非常慢，有什么好办法？
不要用cat或直接vi打开大文件。推荐tail -n 1000或less分页查看；如果必须全量搜索，用grep只输出匹配行，必要时配合-m 50限制输出行数。
效果验证
完成排查后，通过以下方式确认故障已被解决：
- 再次执行
sudo tail -n 20 /var/log/messages或对应的服务日志，观察是否还有新的错误产生。 - 对于服务故障，尝试重启服务并访问功能，同时
tail -f实时日志，确认错误不再出现。 - 使用
echo $?检查上一个命令（如systemctl restart nginx）的返回值，0表示成功。
示例检查命令：
# 检查Nginx状态
sudo systemctl status nginx
检查系统总体日志是否有新错误（近5分钟）
sudo journalctl --since '5 min ago' | grep -i error | tail -10
如果以上步骤执行后，不再出现相关报错，业务访问正常，则说明日志排查及修复工作完成。
遇到新问题请按本文方法重新介入排查即可。
