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 行数是否超阈值，邮件告警
基本上就这些。日志分析能力不靠背命令，而靠建立“服务行为—日志输出—系统状态”的映射习惯。多看几次真实故障现场，比读十篇教程管用。
