3. 日志采集工具：tail、grep、awk、sed 在日志分析中的基础用法

日志分析这件事，说白了就是跟文本打交道。你想想看，升级失败时，系统吐出来的信息全在日志文件里。这时候，tail、grep、awk、sed 这四个工具就是你的贴身武器。

我个人习惯，不管多复杂的排查场景，先用这四个工具把日志“切”成可读的小块。别急着上什么大数据平台，很多时候一条 grep 命令就能定位问题。

核心思路： 先缩小范围（grep），再提取关键字段（awk），然后格式化输出（sed），最后实时跟踪（tail）。四步走，基本覆盖 90% 的排查场景。

3.1 tail：实时跟踪与快速查看

tail 是我用得最频繁的命令，没有之一。升级过程中，服务重启、配置加载、连接建立……这些关键事件都会实时写入日志。用 tail -f 就能像看直播一样盯着日志输出。

# 实时跟踪最新日志
tail -f /var/log/upgrade.log

# 查看最后 200 行，适合看最近的状态
tail -n 200 /var/log/upgrade.log

# 跟踪时过滤关键字（结合 grep）
tail -f /var/log/upgrade.log | grep "ERROR"

我记得有一次线上升级，服务启动后一直报连接超时。我直接 tail -f 盯着日志，发现每隔 3 秒就出现一次 Connection refused。嗯，这明显是后端服务还没就绪。后来加了启动等待脚本，问题解决。

小技巧： 用 tail -F（大写 F）可以跟踪按日期滚动的日志文件。比如 tail -F /var/log/app-$(date +%Y%m%d).log，文件被重命名后会自动重新打开。

3.2 grep：精准定位与模式匹配

grep 是日志分析的“筛子”。升级失败时，日志文件动辄几百 MB，你不可能一行一行看。用 grep 把包含 ERROR、FATAL、Exception 的行筛出来，效率翻倍。

# 查找所有 ERROR 行
grep "ERROR" /var/log/upgrade.log

# 忽略大小写，适合匹配 error/Error/ERROR
grep -i "error" /var/log/upgrade.log

# 显示匹配行的前后 5 行上下文
grep -C 5 "Connection refused" /var/log/upgrade.log

# 递归搜索整个目录
grep -r "升级失败" /var/log/

我曾经遇到一个诡异的问题：日志里明明有 ERROR，但 grep 就是搜不到。后来发现是日志文件编码是 UTF-16，而 grep 默认按 UTF-8 解析。用 grep -a 把二进制文件当文本处理，才找到问题。

避坑指南： 我曾经在排查时用了 grep -v（反向匹配）来排除 INFO 行，结果把关键的错误信息也排掉了。建议先用 grep -c 统计行数，确认过滤条件没问题再深入分析。

3.3 awk：结构化提取与统计

awk 是文本处理的瑞士军刀。日志文件通常有固定格式，比如时间戳、日志级别、模块名、消息内容。用 awk 可以按列提取，甚至做简单的统计。

# 提取第 1 列（时间戳）和第 5 列（消息）
awk '{print $1, $5}' /var/log/upgrade.log

# 按逗号分隔（CSV 格式日志）
awk -F',' '{print $2, $4}' /var/log/upgrade.csv

# 统计每个模块的错误次数
awk '/ERROR/ {print $3}' /var/log/upgrade.log | sort | uniq -c | sort -rn

我习惯用 awk 做“日志摘要”。比如升级过程中，想知道每个阶段花了多少时间，可以用 awk 提取时间戳，然后计算差值。有一次数据库迁移超时，我就是用 awk 算出了每个表的迁移耗时，发现某个大表花了 80% 的时间。

常用模式： awk '/模式/ {动作}' 文件。模式可以是正则，动作可以是打印、计数、计算。配合 BEGIN 和 END 块，可以做更复杂的处理。

3.4 sed：流式编辑与格式化

sed 是文本的“手术刀”。日志分析中，我主要用它做三件事：替换敏感信息、删除无关行、格式化输出。

# 替换 IP 地址为 ***（脱敏）
sed 's/[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}/***/g' log.txt

# 删除所有 DEBUG 行
sed '/DEBUG/d' /var/log/upgrade.log

# 在每行开头添加行号
sed '=' /var/log/upgrade.log | sed 'N;s/\n/ /'

有一次给客户发日志分析报告，日志里包含内网 IP 和数据库密码。我用 sed 写了个脱敏脚本，一行命令就把敏感信息全替换了。嗯，这个习惯后来成了团队的标准流程。

小技巧： sed -i 可以直接修改原文件，但建议先不加 -i 测试一下。我习惯用 sed 's/old/new/g' file > newfile，确认无误后再覆盖。

3.5 四工具协同：一个完整的排查案例

光说单个命令没意思，我给你看一个真实的排查流程。假设升级后服务启动失败，日志文件 /var/log/app.log 有 500MB。

  1. 实时跟踪： tail -f /var/log/app.log | grep -i "error" —— 先看最新的错误。
  2. 定位时间窗口： 发现错误集中在 10:00-10:05，用 sed -n '/10:00/,/10:05/p' 截取这个时间段。
  3. 提取关键字段： 用 awk '{print $1, $3, $NF}' 提取时间、模块、最后一段错误码。
  4. 统计错误分布： awk '/ERROR/ {print $3}' | sort | uniq -c | sort -rn 看哪个模块报错最多。
  5. 脱敏输出： 用 sed 's/密码=[^ ]*/密码=***/g' 清理敏感信息，生成报告。

整个过程，一条管道链搞定：

tail -n 10000 /var/log/app.log | grep -i "error" | awk '{print $1, $3, $NF}' | sort | uniq -c | sort -rn | sed 's/密码=[^ ]*/密码=***/g'
核心原则： 管道链的每一步只做一件事。tail 负责取数，grep 负责过滤，awk 负责提取，sort/uniq 负责统计，sed 负责格式化。这样既清晰又容易调试。

3.6 知识结构图：四工具的关系与分工

下面这张图帮你理清四个工具在日志分析中的定位。我画的时候特意把“输入-处理-输出”的流程标出来了。

日志分析四工具关系图 日志分析四工具关系图 日志文件 tail：实时跟踪 grep：模式匹配 awk：字段提取 sed：格式化输出 分析结果 / 报告 说明： 1. 四个工具可以独立使用，也可以串联成管道链。 2. 典型流程：tail → grep → awk → sed → 输出。 3. 实际排查中，根据需求灵活组合，不必全用。

3.7 工具对比：什么时候用哪个？

工具 核心能力 典型场景 常用参数
tail 实时跟踪、尾部查看 监控升级过程、查看最新日志 -f -n -F
grep 模式匹配、过滤行 搜索错误关键字、统计匹配行数 -i -C -r -v
awk 字段提取、统计计算 提取时间戳、统计模块错误数 -F '{print}' sort uniq
sed 流式编辑、替换删除 脱敏敏感信息、删除 DEBUG 行 s/// /d -i
避坑指南： 我曾经在 grep 和 awk 之间纠结了很久，后来总结了一个原则：按行过滤用 grep，按列提取用 awk，按规则替换用 sed。别混用，否则管道链会变得难以维护。

好了，这四个工具的基础用法就讲到这里。你想想看，升级失败时，日志文件就在那里，用对工具，问题往往半小时内就能定位。下次遇到类似场景，不妨先试试这套组合拳。

← 上一章 📖 返回目录 下一章 →