Linux日志分析是定向追踪与证据链还原，核心在于明确日志位置、理解日志含义、选用合适工具：/var/log/下各文件分工明确，journalctl统一管理systemd日志；日志条目含时间、主机、进程、事件四要素；常用命令组合覆盖登录失败、服务报错、IP统计、实时监控等场景；需注意日志轮转归档和inode耗尽两大陷阱。
Linux日志分析不是“翻文件”，而是“定向追踪+证据链还原”。核心逻辑就三点：知道日志在哪、明白日志在说什么、用对工具快速定位关键信息。
一、先搞清日志的“家”和“身份”
系统日志不是散装的，它有明确的归属地和职责分工：
- /var/log/messages：通用系统日志（RHEL/CentOS），内核消息、服务启停、警告错误都在这儿；
- /var/log/syslog：Debian/Ubuntu 的通用日志，作用类似 messages；
- /var/log/auth.log（或 /var/log/secure）：专管登录、sudo、SSH 认证成败，安全排查必看；
- /var/log/kern.log 和 /var/log/dmesg：聚焦内核层，硬件识别、驱动加载、OOM 杀进程都藏在这儿；
- journalctl：systemd 系统的日志中枢，所有服务日志默认由它统一收口，不依赖文件路径，更灵活。
二、读懂一行日志到底在讲什么
典型日志条目如：
Dec 12 08:45:22 server01 sshd[1987]: Failed password for root from 192.168.5.33 port 54321 ssh2
拆解四要素就能抓住重点：
- 时间戳（Dec 12 08:45:22）：事件发生时刻，是排查时序问题的第一锚点；
- 主机名（server01）：确认日志来源，多机环境避免查错机器；
- 进程名与PID（sshd[1987]）：锁定哪个服务出的问题，PID 可进一步查资源占用；
- 事件详情（Failed password for root...）：直接说明行为性质——这是暴力破解尝试的典型特征。
三、用最小命令组合解决最常见问题
别背命令，记场景。以下组合覆盖 90% 日常分析需求：
- 查“最近有没有登录失败”：
grep -i "failed password" /var/log/auth.log | tail -n 10； - 看“某服务刚启动时有没有报错”：
journalctl -u nginx --since "2 hours ago" | grep -i "error\|fail"； - 统计“谁在反复扫 SSH”：
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -nr | head -5； - 实时盯“新错误是否还在冒”：
tail -f /var/log/messages | grep -i "kernel\|oom\|panic"。
四、进阶提醒：别被表象骗，注意两个隐藏陷阱
实际排查中，容易卡住的地方往往不在日志内容本身：
-
日志轮转后找不到旧记录：/var/log/messages.1、messages.2.gz 这类归档文件也要查，可用
zgrep "error" /var/log/messages.2.gz直接搜压缩包； -
明明磁盘有空间却写不了日志：运行
df -i看 inode 是否耗尽——大量小日志文件（如调试日志碎片）会吃光 inode，导致新建日志失败。
基本上就这些。日志分析本质是“提问-筛选-验证”的循环，工具只是延伸你的眼睛和脑子。用熟几条命令，再配合日志结构理解，就能从海量文本里稳准快地揪出线索。
