Linux日志分析需建立“目标→路径→验证”闭环：先明确问题现象，再精准定位日志源与工具链，最后通过时间过滤、上下文提取、统计分析组合操作快速聚焦线索。
Linux日志分析不是堆命令，而是建立“目标→路径→验证”的闭环。核心在于：先明确问题现象，再选对日志源和工具链，最后用组合操作快速聚焦关键线索。
找准日志源头，别在错的文件里翻半天
系统出问题，先问自己：是服务起不来？登录失败？网页打不开？还是内存爆了？不同问题对应不同日志：
- 服务启动失败 → 查 /var/log/messages（RHEL/CentOS）或 /var/log/syslog（Debian/Ubuntu），再加 journalctl -u 服务名.service
- SSH 登录异常、暴力破解 → 直接看 /var/log/secure（RHEL）或 /var/log/auth.log（Ubuntu）
- 内核报错、硬件识别失败 → 用 dmesg | less 或 journalctl -k
- Web 访问慢或 502 → 进入 /var/log/nginx/error.log 或 /var/log/httpd/error_log，配合 access 日志交叉比对
- Java 应用崩溃 → 看 $CATALINA_HOME/logs/catalina.out，搜 OutOfMemoryError、Exception、SEVERE
用对命令组合，三步筛出有效信息
单靠 grep 只能找关键词，真正高效要靠“时间 + 上下文 + 统计”三层过滤：
- 限定时间范围：比如查 2 小时内的错误，用 journalctl --since "2 hours ago" -p err；查某天某时段，写成 journalctl --since "2025-12-11 14:00:00" --until "2025-12-11 15:30:00"
- 保留上下文：发现一行报错，别只看那行 —— 用 grep -A 3 -B 2 "Connection refused" /var/log/syslog 把前两行、后三行一起捞出来，常能看见连接发起方或配置加载失败的前置动作
- 统计高频线索：比如 SSH 失败多，就跑 grep "Failed password" /var/log/secure | awk '{print $11}' | sort | uniq -c | sort -nr | head -5，直接列出攻击最猛的 5 个 IP
大日志不硬扛，分页、压缩、轮转全跟上
几百 MB 的 catalina.out 或 syslog.1.gz 别用 cat 硬刷，容易卡死终端：
- 查压缩日志不用解压：zgrep "timeout" /var/log/syslog.2.gz
- 超大文件首选 less：打开后按 /error 搜索，n 跳下一个，Shift+G 到末尾，g 回开头
- 实时监控加过滤：tail -f /var/log/messages | grep --line-buffered -i "oom\|kill\|segfault"（--line-buffered 防止输出延迟）
- 老日志定期清理：确认已配置 logrotate，检查 /etc/logrotate.d/ 下对应服务的规则，避免磁盘被撑爆
进阶技巧：从日志里挖出隐藏线索
很多问题藏在“正常日志”背后，需要一点模式敏感度：
- 看时间戳是否突变：同一服务日志里出现明显跳时（如从 15:22:01 突然到 15:28:44），可能是系统时间被修改或 NTP 同步异常
- 关注重复但不报错的条目：比如每分钟一条 "connection reset by peer"，大概率是客户端主动断连，而非服务端故障
- 对比多个日志的时间线：Nginx access.log 中某 IP 大量 504，同时 journalctl -u php-fpm 出现大量 “process exited with code 1”，就能锁定是 PHP 进程崩了
- 用 awk 提取结构化字段：例如 awk '$9 ~ /^5/ {print $1, $4, $9}' /var/log/nginx/access.log 快速导出所有 5xx 请求的 IP 和时间
基本上就这些。不复杂，但容易忽略——关键是动手前想清楚“我要证什么”，而不是“我能跑什么命令”。
