Linux日志分析核心是定位关键日志、按需筛选、结合上下文判断问题本质，聚焦“谁在什么时候、干了什么、结果如何”三要素。
Linux日志分析的核心逻辑很简单：先定位关键日志，再按需筛选内容，最后结合上下文判断问题本质。不靠死记命令，而靠理解“谁在什么时候、干了什么、结果如何”这三件事。
一、搞清日志从哪来、记了啥
系统日志不是杂乱无章的文本堆，而是有明确来源和分工的：
- /var/log/messages 或 /var/log/syslog：通用系统活动日志，内核消息、服务启停、硬件事件都往这里写
- /var/log/auth.log（Debian/Ubuntu）或 /var/log/secure（RHEL/CentOS）：所有登录、sudo、SSH、su等安全动作全在这里，查异常访问首选
- /var/log/kern.log 和 dmesg：专盯内核级问题，比如驱动加载失败、USB设备识别异常、内存报错
-
journalctl：systemd 系统的日志统一入口，不用翻文件，一条命令就能查服务、时间、优先级——比如
journalctl -u nginx --since "2 hours ago"
二、用对工具，而不是用全工具
日常排查不需要掌握全部50个命令，盯住几个高频组合就足够应对80%场景：
- tail -f /var/log/auth.log：实时盯着登录行为，看到新失败记录立刻反应
-
grep -i "failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -nr：一键统计暴力破解源IP，第11字段通常是IP（格式因日志而异，可先
head -n1看一眼） - grep -C 3 "segmentation fault" /var/log/messages：找到崩溃关键词，连带前后3行一起看，常能发现前置异常或后续连锁反应
- awk '$9 ~ /404|500/ {print $1, $4, $9}' /var/log/nginx/access.log：提取Web日志里的客户端IP、时间、状态码，快速定位异常请求模式
三、时间+上下文=真相
单看一行日志往往没意义，真正有用的线索藏在时间和关联行为里：
- 日志时间戳不是摆设。用
journalctl --since "2025-12-12 20:00:00"或grep "Dec 12 20:" /var/log/messages锁定故障窗口 - 一个服务启动失败，别只看它自己的错误行。往前翻几秒，可能发现依赖服务没起来；往后看几秒，可能发现它反复尝试重连
- 用户登录失败后紧接着出现
systemd-logind的 session 超时日志，说明不是密码错，而是PAM配置或账户锁定问题
四、别跳过日志轮转和权限细节
很多分析卡壳，其实败在基础环节：
- 查不到旧日志？可能是被
logrotate归档压缩了。试试zgrep "error" /var/log/messages.1.gz或zcat /var/log/syslog.2.gz | grep "OOM" - 提示 Permission denied？普通用户默认看不到
/var/log/secure。要么加sudo，要么用journalctl --no-pager（systemd 日志对普通用户更友好） - 日志突然变空？检查磁盘空间（
df -h /var/log）和 rsyslog/journald 是否还在运行（systemctl status rsyslog或systemctl status systemd-journald）
基本上就这些。日志分析不是拼命令熟练度，而是建立“行为—时间—结果”的对应关系。看懂三五行典型日志，比背一百条语法管用。
