线上问题定位需快速聚焦日志：先用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'
识别高频错误模式与堆栈特征
重复出现的错误往往暴露根本原因。注意三类典型信号：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
- 堆栈末尾一致：多个 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 变慢甚至磁盘打满。
