日志翻半天找不到关键行：用 grep、sed 和 awk 把文本处理讲清楚

服务出了问题，第一件事往往是去翻日志。可日志动不动几十万行，用编辑器打开慢慢翻，翻到天黑也未必找得到关键的那一行。文本处理的三件套 grep、sed、awk 就是为这件事准备的：grep 负责把相关的行挑出来，sed 负责按规则改写，awk 负责按列拆开算数。分工弄清楚了，几十万行的日志也能在几秒钟内筛出答案。

第一步是先用 grep 把相关的行挑出来。最常用的是 grep "ERROR" app.log，只看包含 ERROR 的行；加上 -n 能同时看到行号，方便回头定位；加上 -C 3 会把匹配行前后各三行一起打印出来，很多报错的上下文就藏在这几行里。如果只想知道有没有、出现过几次，grep -c 直接数个数，比肉眼数快得多。还有一个容易被忽略的点：grep 默认是区分大小写的，error 和 ERROR 是两回事，排查时加上 -i 忽略大小写，能避免漏掉一半的线索。

挑出来之后，行数可能还是太多，这时要学会组合筛选。grep "ERROR" app.log | grep "timeout" 是把两个条件叠加，只保留同时满足的行；反过来，grep -v "healthcheck" 能把健康检查这种刷屏的噪音先去掉。管道的思路很简单：每一步都把范围再缩小一点，最后剩下的就是真正值得看的行。先去噪、再定位，这个顺序能省掉大量无效阅读。

第二步是 sed，按规则批量改写文本。最常见的用法是替换：sed 's/旧地址/新地址/g' config.txt，把配置文件里的旧地址一次性换掉。改之前先不加 -i、先打印出来看一眼，确认替换结果符合预期再加 -i 写回文件——直接原地修改一旦写错，恢复起来很麻烦。sed 还能按行号删行、按模式取行，比如 sed -n '100,200p' app.log 只打印第 100 到 200 行，配合 grep 先定位、再用 sed 取出附近的行，是排查时很顺手的一招。

第三步是 awk，按列拆开处理。日志里很多信息是按空格或逗号分列的，比如访问日志里的 IP、时间、状态码、耗时。awk '{print $1}' access.log 能把第一列单独抽出来，再接 sort | uniq -c | sort -nr，立刻就能看到哪个 IP 请求最多。更进一步，awk 还能做简单的统计：awk '$9 >= 500 {count++} END {print count}' access.log 可以数出状态码大于等于 500 的请求有多少条。把“按列取值”和“按条件计数”结合起来，日志就从一堆文字变成了一张可以算数的表。

最后提醒两个常见误区。一是不要把所有活都交给 grep：grep 只能按行筛选，涉及按列统计、求和、分组时，awk 才是正确的工具，硬用 grep 拼正则只会越写越乱。二是处理生产日志之前，先确认有没有备份、是不是在原文件上操作，sed 的 -i 和重定向 > 都会直接改写文件，操作前复制一份，永远比事后找恢复办法便宜。

一句话总结：先 grep 把相关的行挑出来、把噪音去掉，再用 sed 按规则批量改写，最后用 awk 按列拆开做统计。三件套各管一段，日志再大也不怕，关键行几秒钟就能找到。