Linux日志分析关键在理清目标、聚焦场景、快速定位，需先明确日志来源与路径，再用针对性命令组合（如grep、journalctl、awk）按现象筛选异常，辅以降噪、锚定和高效浏览习惯，形成问题闭环。
Linux日志分析不靠死记命令，关键在理清目标、聚焦场景、快速定位。先看日志在哪、谁在写、写了什么，再用合适工具筛出异常线索——不是所有日志都要通读，80%的问题靠几条命令+一点经验就能闭环。
一、搞清日志来源和常用位置
系统服务、内核、应用各自写各自的日志，路径和格式差异大，别一上来就 grep /var/log/*：
- /var/log/messages：通用系统日志（RHEL/CentOS），记录启动、服务状态、硬件警告等
- /var/log/syslog：Debian/Ubuntu 主系统日志，功能类似 messages
- /var/log/auth.log：登录认证相关（ssh 登录失败、sudo 使用、用户切换）
- /var/log/kern.log：内核消息，排查驱动、oom、硬件报错
- /var/log/journal/（systemd 系统）：二进制日志，需用 journalctl 查看，支持时间、服务、优先级过滤
- 应用日志常独立存放：如 Nginx 在 /var/log/nginx/access.log + error.log，MySQL 在 /var/log/mysql/error.log
二、高频问题怎么快速查？直接给命令组合
别从头翻，按现象反推关键词，配合时间范围缩小范围：
-
SSH 登录异常？ → 查 auth.log 中失败记录：
grep "Failed password" /var/log/auth.log | tail -20
加时间筛选：awk '/May 10/ && /Failed password/ {print}' /var/log/auth.log -
服务突然挂了？ → 先看 systemd 状态，再捞日志：
systemctl status nginx → 找到最近一次启动/失败时间
journalctl -u nginx --since "2024-05-10 14:00" --no-pager -
磁盘爆满，找大日志文件？
du -sh /var/log/* | sort -hr | head -5
发现 /var/log/journal 占用过大？可清理：journalctl --vacuum-size=500M -
Web 访问 502/504？ → 同时比对 Nginx error.log 和后端（如 PHP-FPM 或 upstream）日志：
tail -f /var/log/nginx/error.log（实时盯错误）
再查对应时间点的 upstream 日志，确认是超时、拒绝连接还是进程崩溃
三、日志太多看不过来？学会“降噪”和“锚定”
原始日志混着 INFO/WARN/DEBUG，直接扫容易漏重点：
- 用优先级过滤：journalctl 默认显示所有级别，加 -p err 只看错误，-p warning 看警告
-
排除干扰行：比如屏蔽健康检查日志（Nginx 的 /healthz）：
grep -v "/healthz" /var/log/nginx/access.log | awk '$9 ~ /^5/ {print}' -
按时间精准锚定：用户说“下午3点打不开”，别搜 “3:”，用 ISO 格式更稳：
journalctl --since "2024-05-10 15:00:00" --until "2024-05-10 15:05:00" - 用 less + 搜索高效浏览：打开大日志用 less +G /var/log/messages（+G 跳末尾），然后输入 /OutOfMemory 回车搜索
四、简单但实用的分析习惯
不靠工具堆砌，靠几个小动作提升效率：
- 每次查日志前，先 run date：确认服务器时间是否准确，避免时区或时间漂移导致时间筛选失效
- 把重复命令 alias 成短指令：比如 alias ssa='journalctl -u sshd -n 50 -f'，下次直接 ssa 实时盯 SSH
- 错误码比文字描述更可靠：看到 “Connection refused” 不如记下端口号和 errno（如 “errno=111”），查 man 2 connect 更准
- 日志里出现 PID，立刻跟进程确认状态：ps -p 1234 -o pid,ppid,comm,etime，看是否已僵死或被 kill
基本上就这些。日志分析不是拼命令数量，而是建立“问题→日志源→关键字段→验证动作”的闭环。练熟三五个核心场景，再逐步扩展，比背一百个参数管用得多。
