Linux日志分析是理解结构、定位线索、结合上下文快速判断根源的过程，核心在于知道看什么、在哪看、怎么看、怎么关联，并通过分类日志路径、三板斧筛选、解读信号及跨服务串联实现高效排障。
Linux日志分析不是“翻文件”，而是通过理解日志结构、定位关键线索、结合上下文快速判断问题根源的过程。核心在于：知道看什么、在哪看、怎么看、怎么关联。
一、搞清日志在哪、分哪几类
Linux日志分散在多个位置，不同服务写入不同路径，不能只盯/var/log/messages：
- 系统级日志：/var/log/syslog（Debian/Ubuntu）、/var/log/messages（RHEL/CentOS），记录内核、systemd、基础服务启动/错误
- 服务专属日志：/var/log/nginx/access.log、/var/log/mysql/error.log、/var/log/secure（认证相关），必须查对应服务的配置确认实际路径
- journald日志：systemd系统默认启用，用journalctl查，比文本日志更结构化（含PRIORITY、UNIT、SYSLOG_IDENTIFIER等字段）
- 应用自定义日志：比如Java应用常写到/opt/app/logs/app.log，得看部署文档或ps -ef | grep java找参数
二、快速定位问题的三板斧
别从头滚日志。先用时间、级别、关键词锚定异常段落：
- 按时间筛选：journalctl --since "2024-04-10 14:30:00" --until "2024-04-10 14:45:00"
- 按服务/单元过滤：journalctl -u nginx.service -p err（只看nginx的error及以上级别）
- 文本日志中精准搜：grep -i "connection refused\|timeout\|segfault\|oom" /var/log/messages | tail -20；用awk '{print $1,$2,$3,$NF}'快速看时间+末尾状态
三、读懂日志里的“人话”信号
日志不是乱码，每行都有模式。重点关注这几类信息：
- 时间戳格式：syslog是“Apr 10 14:22:01”，journald是“2024-04-10 14:22:01”，时区不一致会导致误判，先用date和timedatectl check
- 严重级别缩写：debug/info/notice/warn/err/crit/alert/emerg（数字7~0），但很多程序不规范——比如MySQL把慢查询记为Warning，实际要关注
- 进程标识：[1234] 或 [nginx: worker process]，可配合ps aux | grep 1234查进程状态
- 典型错误模式：Permission denied（SELinux或权限）、No route to host（网络不通）、Connection refused（端口没监听）、Out of memory（OOM killer已杀进程，查dmesg）
四、进阶：串联+聚合+自动化
单点日志只能看表象。真问题往往跨服务、跨时间、跨主机：
- 时间对齐查因果：比如Web返回502，先查nginx error.log里upstream timed out时间，再查同一秒前后backend服务日志是否有GC停顿或DB锁等待
- 用awk/sed做轻量聚合：统计HTTP状态码分布：awk '{print $9}' /var/log/nginx/access.log | sort | uniq -c | sort -nr
- 用rsyslog+ELK或Loki做集中分析：小团队可用rsyslog转发到一台中心日志机；中大型建议用Loki+Grafana，成本低、查起来快，支持正则提取标签
- 写简单巡检脚本：每天凌晨用shell检查/var/log下各日志大小增长是否异常（突增可能意味着循环报错）、最近1小时ERROR行数是否超阈值，邮件告警
基本上就这些。日志分析能力不靠背命令，而靠建立“服务行为—日志输出—系统状态”的映射习惯。多看几次真实故障现场，比读十篇教程管用。
