Linux 日志分析定位线上问题

线上问题定位需快速聚焦日志：先用sed/awk锁定时间窗口，再用grep -a/-b提取上下文；识别堆栈末尾、线程id、5xx突增等高频异常模式；关联应用、系统、数据库、journalctl多源日志交叉验证；每日巡检错误增长、空行乱码及日志轮转。

线上问题定位，日志是第一手线索。linux 系统和应用产生的日志分散、格式不一、量大且实时滚动，直接翻看效率极低。关键不是“看全”，而是“快速聚焦”——通过组合命令精准筛选时间、关键词、上下文和异常模式。

快速定位时间窗口内的异常行

多数线上问题有明确发生时间（如用户反馈的14:23），优先锁定该时段日志：

• 用 sed 提取时间范围（适用于标准 syslog 格式，如 May 12 14:20:00）：
  sed -n '/May 12 14:20:/, /May 12 14:25:/p' /var/log/messages
• 用 awk 更灵活地匹配时间戳（支持自定义格式，如 2024-05-12T14:23:17）：
  awk '$0 ~ /^2024-05-12T14:2[3-4]:/ {print}' app.log
• 结合 grep -A/-B 查看异常行前后几行，还原上下文：
  grep -A 2 -B 2 'Error|timeout|500' app.log | grep '2024-05-12T14:23'

识别高频错误模式与堆栈特征

重复出现的错误往往暴露根本原因。注意三类典型信号：

• 堆栈末尾一致：多个 ERROR 日志最后几行相同（如都以 Caused by: java.net.ConnectException: Connection refused 结尾），说明是统一服务调用失败；
• 线程名或请求 ID 集中：用 grep -oE 'tid=[^[:space:]]+|X-Request-ID:[^[:space:]]+' app.log | sort | uniq -c | sort -nr 找出高频请求或线程，再反查完整日志；
• 状态码突增：nginx 或应用 access log 中，统计 5xx 出现频次：
  awk '$9 ~ /^5/ {count++} END {print count}' access.log，再配合 tail -n 1000 查最近记录。

关联多日志源交叉验证

单点日志常信息不足。例如接口超时，需同步检查：

• 应用日志：是否有 “TimeoutException” 或 “Read timed out”；
• 系统日志（/var/log/messages）：是否伴随 OOM killer 杀进程、磁盘满（No space left on device）或网络中断；
• 数据库慢查询日志：确认是否因某条 sql 执行过长拖垮整个请求链；
• 用 journalctl -u service-name –since “2024-05-12 14:20:00” 查 systemd 服务启停与资源限制事件，辅助判断是否被 cgroup kill。

建立轻量级日志巡检习惯

问题常在恶化前已有苗头。每天花 3 分钟执行以下检查：

• 查错误增长率：grep -c 'ERROR' /var/log/app/app.log.$(date -d 'yesterday' +%Y%m%d) 对比今日值；
• 扫空行/乱码/截断痕迹（可能预示写入失败或磁盘异常）：grep '^$' app.log | wc -l 或 file app.log 看编码是否异常；
• 确认日志轮转正常：ls -lt /var/log/app/*.log*，避免因 logrotate 失败导致单文件过大、grep 变慢甚至磁盘打满。